Flacky XSLT Debugger

[sderrick]

I've been using Oxygen for about 5 years now, upgrading with every new release. Sometimes I regret ever upgrading. The debugger has become more and more unreliable with every upgrade. I continue to expect a better experience and continue to be disappointed.

Local variables may or may not be available in the variables view.
The xslt process restarts when stepping through pieces of code for no apparent reason? The script runs without errors on the command line or using a defined transform scenario in Oxygen?
Error messages about undefined variables that don't exist in my code?
These are a few of the varied problems I experience in the debugger. Sometimes I cringe when I know I will have to run it because it is so frustrating to have the tool I need(and paid for) crap out on me so consistently! I have rarely had this experience with the many C++, Java or other language debuggers I've used over the last 30 years...

Restarting Oxygen sometimes fixes things, sometimes not.

I have always used the Linux Stand Alone XML Editor. I've always used close to the Oracle's latest JDK, I'm on 1.8.0_25 now.

My scripts are somewhat large and complex as are some of the xml files I run against, but I can't believe that is the problem.

Do others have similar experiences? Any workarounds. I use the 'XWatch' view a lot to see local variables when the 'Variable" window says they are unavailable, but that is such a hassle. I put breakpoints past the line in the code where stepping through or over will cause the debugger to crash or report some odd error that makes no sense and does not occur if I "run" by it, this is also a major PITA. Once I "run" by the line I can then step fine until I come to some other line of code the debugger can't handle stepping over but runs over fine...

Scott

[sderrick]

Yet another new annoyance: Set a few breakpoints in a xsl script in the debugger.

Close Oxygen, reopen Oxygen, the breakpoints are in the breakpoint list, and the debugger will stop at them, but they don't show in the debugger's XSL view. The only way I can get them to show is to mouse click where the red dot should be, they then show and that click does not turn it off.

[adrian]

Hello Scott,

I'm sorry you feel that way.
With each new version of Oxygen we upgrade the bundled version of Saxon-EE (transformer) that is used for debugging XSLT 2.0 (or 3.0) and we validate it for transformation and debugging. Some aspects (and limitations) of the debugging are dictated by the transformer engine.
For example Saxon-EE 9.5 (introduced in Oxygen v15.0) made significant changes regarding the (late) initialization of variables. This made the Variables view less useful in some contexts.
However, if you can evaluate the variable in the XWatch view, but you can't see it in the Variables view, that could be a bug within the GUI.

We did not receive problem reports regarding these aspects. Please let us know of any problems you encountered and the context, so we can fix them. Without the means to reproduce the issues it's very difficult to identify and fix them. If possible, please send sample files to our support email address, support@oxygenxml.com, and describe the steps and context to reproduce the problem.

Regarding the Linux platform and Java, for v16.1 we are currently recommending using Java 7, either the Java SE 7 runtime bundled with Oxygen, or, if you experience any problems with that, you should use the OpenJDK 7 package available for your Linux distribution. We are currently testing Oxygen with Java 8 and we will update our recommendation if it passes.

About the annoyance with the breakpoints not appearing in the debugger's XSL view after restarting Oxygen, I can reproduce it and I've logged it to be fixed in the next release. A quick workaround I found for this is to close (Ctrl+W) and reopen (Ctrl+Alt+T) the XSL file.

Regards,
Adrian

[sderrick]

Adrian,

Thanks for the work around on the illusive breakpoint indicators. Thats a big help.

I will see if I can come up with an example xml/xsl pair for the most frustrating bugs. I don't have a lot of time to put into what my employers would consider wasted time. Also the problems don't happen on small simple xsl code snippets. Teh debugger handles "Hello World" scripts just fine, its the real world scripts it spazzes out on.

The late initialization of variables is a "MAJOR PITA"! Whats the use of a debugger if you can't evaluate the current contexts variables?

thanks again,

Scott

[ionela]

Hi,

Just to update the thread, the following problem has been resolved in the latest maintenance build of Oxygen 16.1, 2015040615 (released on April 8th):

XSLT Debugger: Breakpoints were not visible on the editor stripe bar after restarting the application.

You can download it from our web site:
http://www.oxygenxml.com/download.html

The list of bug-fixes can be found here:
http://www.oxygenxml.com/build_history.html#2015040615

You can follow the release/build RSS feed here:
http://www.oxygenxml.com/rssBuildID.xml

Regards,
Ionela

[sderrick]

Thats good news and appreciated.

When you force Saxon to provide a way to disable (late) initialization of variables, so your debugger has a functional variable view, instead of the crippled thing we have now, or figure out a way to work around that I will be a happy customer.

Is it possible to have Oxygen use a different xml engine? One that supports its users needs instead of telling us what we need?

Scott

[adrian]

Hello Scott,

When you force Saxon to provide a way to disable (late) initialization of variables, so your debugger has a functional variable view, instead of the crippled thing we have now, or figure out a way to work around that I will be a happy customer.

Unfortunately tinkering with the Saxon configuration for debugging can have significant side effects and alter the result of the transformation. We are constantly trying to expose as much as we can of the available context of the XSLT engine, but the speed optimizations that the engine (Saxon) performs are more often than not counterproductive for debugging.
As an example, another problem that was addressed in this maintenance build is:

XSLT Debugger: Stopping at a breakpoint could alter the result of the transformation.

This happened precisely because the Oxygen debugger performed a re-evaluation of the local variables (to present their values in the Variables view) when paused. This had the unfortunate side effect of altering the current context and thus the result.

Is it possible to have Oxygen use a different xml engine? One that supports its users needs instead of telling us what we need?

This was probably a rhetorical question, but I feel compelled to answer... For debugging only the built-in XSLT engines can be used (Saxon 6 and Xalan for XSLT 1.0 and Saxon 9.x for XSLT 2.0 and 3.0). As much as we would want to make the XSLT debugger more flexible and let the users pick between more engines (or different engine versions), currently it is heavily integrated with the Java-based engines that we have available. In most cases we need to create a patch for each new version of the engine to have access to some of its inner workings.

Regards,
Adrian

[sderrick]

thanks for the detailed reply. Its nice to know you folks are up on the problems and seeking solutions.

Its too bad you are so closely tied to a engine that has such poor debugger support. Saxon is making you guys look really bad.

[rberge]

Thank you for posting this. I just started trying out Saxon (Saxon-PE9.0.4.6) in Oxygen and can not understand why variables don't display
For example I have this:
<!-- 2 Convert a Timestamp in the form: 2007-12-27:08:12.159691 into an HL7 Timestamp with timezone as attribute-->
<xsl:template name="TS2HL7TSsec">
<xsl:param name="TS" select="string(.)"/>
<xsl:variable name="Today" select="current-dateTime()"></xsl:variable>
<xsl:variable name="CYMD" select="substring($TS, 1, 10)"></xsl:variable>
<xsl:variable name="HMS" select="substring($TS,12,8)"></xsl:variable>
<!-- CYMD looks like 2015-08-31-->
<!-- HMS looks like 08:12.159691-->
Note, I put "Today" in just to see what the XSLT date format looks like
When this template is run, after these variables are declared, only $Today and $CYMD display in the Variable view. This is also true in the Watch view.
$HMS- although it is created identically to the way CYMD is created- never displays.
I have <oXygen/> XML Editor 14.2, build 2013051016

Why doesn't this variable display? It sounds like you are saying it is because of the way Saxon works with variables. But then why do two of the variables always display?

[adrian]

Hi rberge,

Why doesn't this variable display? It sounds like you are saying it is because of the way Saxon works with variables. But then why do two of the variables always display?

The variables are evaluated depending on context and usage. Is this variable used in the XSL code?
Unused variables are removed at XSL compile time, so they are not even present at execution time.
You should at least include an xsl:message that refers that variable if you want it evaluated by the debugger.

Please note that officially v14.2 is EOL so it no longer maintained or supported.

Regards,
Adrian