XSD accessed via a jar file can be stepped into, not displayed

[scholarsmate]

The server will need to provide a way to serve files over to the VSCode debugger, as currently an XSD accessed via a jar file, can be stepped into, but is not displayed. Interesting that you can continue to step and watch the progress of the building of the infoset. You just can't see the source. However, when I put the ethernetIP/src/main/resources directory on the classpath, and the ethernetIP/target/classes directory on the classpath (in the launch.json), now I can step into the ethernet IP schema files just fine. The fact that this schema depends on a compiled scala class for a plugin caused no issues.

[arosien]

I'm tracing through the execution to see what the DAP system is doing here. DAP can supply non-filesystem sources, so it shouldn't be too difficult to make this work.

[arosien]

This is a duplicate of #76.

[mbeckerle]

Not entirely a duplicate. Unless the symptom has changed.

This ticket is about the odd behvaior that you could step into a jar-file XSD, and it would stop in there, and you could continue to step and see the infoset building step by step while single stepping inside the jar file XSD, but it didn't display the jar-file XSD file.

[arosien]

Not entirely a duplicate. Unless the symptom has changed.

This ticket is about the odd behvaior that you could step into a jar-file XSD, and it would stop in there, and you could continue to step and see the infoset building step by step while single stepping inside the jar file XSD, but it didn't display the jar-file XSD file.

Strange, I wouldn't think that's possible given there is no explicit step-in operation supported, only step-over. But it obviously happens so I'll try to reproduce it. Any examples out there I can reference? @mbeckerle @scholarsmate

[mbeckerle]

Hmmm. I had the PCAP/EthernetIP schema example setup two ways. PCAP was the 'project'. I had two launch configs, one with the src/main/resources directory of ethernetIP added to the daffodil class path in launch.json, the other I first packaged the ethernetIP schema into a jar file ('sbt publishLocal') then put that jar file onto the daffodil class path in the launch.json. When I set a breakpoint in the former launch debugging works as expected allowing you to hit a breakpoint in the ethernetIP schema files. If you then debug using the latter (jar) launch, I believe that breakpoint would still be hit in the latter launch, just without opening the editor to the actual file (which is inside the jar).

[arosien]

Off of main (f2e3b7a9), and adding dfdl-ethernetip-1.2.0.jar to the classpath of the Scala backend, I successfully see the schema file located in the jar. I have no idea how the file is being loaded; it isn't via DAP, so it must be my VS Code knowing how to load content from a jar file path??

I'm not using the exact same mechanism the extension uses to add the schema jar to the classpath, so I'll have to reproduce using those exact steps to see if I can reproduce the problem.

[arosien]

Repro steps:

• Download the main schema, PCAP to the local disk.
• Also check out the dependent schema, ethernetIP, to the local disk. You need to package it into a jar file via sbt package.
• We're going to set up a Daffodil schema run. The schema is pcap.dfdl.xsd, and set a breakpoint at line 168 to make the stepping easier:

      <xs:element name="Ethernet" type="eth:Ethernet" dfdl:choiceBranchKey="1"/>

• We need to ensure that the ethernetIP.dfdl.xsd schema, contained in the jar file (likely named dfdl-ethernetip-1.2.0.jar), is on the classpath for the Daffodil debugger. If you using the installed Daffodil VS Code extension you would add a daffodilDebugClasspath setting to the launch.json configuration, like "daffodilDebugClasspath": "/Users/arosien/nteligen/ethernetIP/target/dfdl-ethernetip-1.2.0.jar". If using a locally built Daffodil debugger backend, you would add the jar to the "unmanaged" directory server/core/lib, which will add that jar to the runtime classpath of the manually-launched backend.
• If running a locally-built Daffodil backend, launch it first. Otherwise proceed to the next step.
• If running a locally-built extension, launch it. Otherwise proceed to the next step.
• Launch the Daffodil config described above, that points to the PCAP schema which points to the ethernetIP schema contained in the classpath-available jar.
• Once the debugging session starts, press "Continue" to advance to the breakpoint we set earlier.
• Press "Step Over", which should advance into the ethernetIP schema, as per the screenshot above.

Check:

• Does the ethernetIP schema file open in VS Code?
• If you click on the top of the stack, does it open the ethernetIP schema in VS Code?

@mbeckerle @scholarsmate @michael-hoke can you repro and share your software versions and settings? (My installation opens the schema contained in the jar file without a problem.)

[mbeckerle]

I am able to reproduce this. [image: image.png]

On Fri, Dec 16, 2022 at 2:51 PM Adam Rosien @.***> wrote:

Repro steps:

• Download the main schema, PCAP https://github.com/DFDLSchemas/PCAP to the local disk.

• Also check out the dependent schema, ethernetIP https://github.com/DFDLSchemas/ethernetIP, to the local disk. You need to package it into a jar file via sbt package.

• We're going to set up a Daffodil schema run. The schema is pcap.dfdl.xsd, and set a breakpoint at line 168 to make the stepping easier:

  <xs:element name="Ethernet" type="eth:Ethernet" dfdl:choiceBranchKey="1"/>

• We need to ensure that the ethernetIP.dfdl.xsd schema, contained in the jar file (likely named dfdl-ethernetip-1.2.0.jar), is on the classpath for the Daffodil debugger. If you using the installed Daffodil VS Code extension you would add a daffodilDebugClasspath setting to the launch.json configuration, like "daffodilDebugClasspath": "/Users/arosien/nteligen/ethernetIP/target/dfdl-ethernetip-1.2.0.jar". If using a locally built Daffodil debugger backend, you would add the jar to the "unmanaged" directory server/core/lib, which will add that jar to the runtime classpath of the manually-launched backend.

• If running a locally-built Daffodil backend, launch it first. Otherwise proceed to the next step.

• If running a locally-built extension, launch it. Otherwise proceed to the next step.

• Launch the Daffodil config described above, that points to the PCAP schema which points to the ethernetIP schema contained in the classpath-available jar.

• Once the debugging session starts, press "Continue" to advance to the breakpoint we set earlier.

• Press "Step Over", which should advance into the ethernetIP schema, as per the screenshot above.

Check:

• Does the ethernetIP schema file open in VS Code?
• If you click on the top of the stack, does it open the ethernetIP schema in VS Code?

@mbeckerle https://github.com/mbeckerle @scholarsmate https://github.com/scholarsmate @michael-hoke https://github.com/michael-hoke can you repro and share your software versions and settings? (My installation opens the schema contained in the jar file without a problem.)

— Reply to this email directly, view it on GitHub https://github.com/apache/daffodil-vscode/issues/265#issuecomment-1355511395, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALUDA43TTOYZHTKXIDUS4TWNTB2PANCNFSM57HSD67Q . You are receiving this because you were mentioned.Message ID: @.***>

[mbeckerle]

My configuration:

Ubuntu 20.04 VS Code 1.74.0

I am running the Daffodil VSCode Extension 1.2.0 release.

PCAP githash fc3ae69c1c968f2e8b9437dff65dab4b9ae237f7 (current HEAD of master branch) plus one edit to change build.sbt to reference daffodil 3.4.0 (from 3.2.1)

EthernetIP githash 3a0de0c4d452a8c1c5d8f77c8e1580991cbc27b0 (tag is 1.2.0)

[mbeckerle]

The error I get is best viewed via the attached png file.

I have verified that this file exists. But looking at the screen shot, I'm not sure what is going on with the escaped hex chars in the URL.

[arosien]

@mbeckerle I have more info: one of my extensions in VSCode is providing the ability to render the xsd file. If I disable all extensions except Daffodil, I get the same message that you do.

I'll bisect my extensions to find out which is providing the help, and perhaps we can include it as a dependency of the installation bundle. Otherwise we can have a more built-in solution like #76 where our extension provides the jar contents via DAP (and we figure out how to mark it as XML-ish content type).

[arosien]

@mbeckerle if I can't find the helpful plugin that knows how to look into jar files, I could put in a workaround where the debugger would step over schema locations whose path matches jar paths. How does that sound?

[mbeckerle]

I think we need to find this plugin (preferable), or build our own flavor of it somehow.

Even relatively small examples illustrate an envelope+payload schema idiom where the envelope schema is in a jar file, and the dev/debug activity focuses on the payload schema.

Note that in this idiom, the start of debug (document element) will be on a schema file that is in a jar. You won't even start from a file in the current project dir. It's only some steps into things that you'll end up stepping into an element in the current project directory.

Real examples have this several tiers deep. E.g., NOC header followed by mil-std-2045 header followed by zip-plugin-schema, (those 3 all in jars) followed finally, by the payload VMF schema. So one is walking through numerous jars and quite a long ways into debugging where it's all jars, several of them, walking around multiple files in and across them, until finally you hit something in the current schema project.

[arosien]

I think we need to find this plugin (preferable), or build our own flavor of it somehow.

I found it: it's the Scala Metals extension which registers a content handler for jar URIs. It arrived in v1.13.0, and the current version is v1.21.0.