This page describes limitations that you may encounter when debugging
XSLT and suggested methods for working around those limitations. Please also
see the product readme, which may contain additional limitations for this
debugger.
General
- XSLT Context and XSL Transformation
Output views might not display automatically when debug session
is launched outside of the Debug perspective: Launching an XSL transformation
debug session when not in the Debug perspective can cause the XSLT Context
view and the XSL Transformation Output view not to be
displayed. The views can be opened manually by choosing Window
> Show View > Other from the workbench menu bar. In the Show
View dialog box, expand the Debug node and
select the view that you want to open. Alternatively, you can correct this
problem by terminating all debug launches and relaunching your application
while in the Debug perspective. To prevent this problem from happening again,
ensure that you are in the Debug perspective when launching a debug session.
- Conflict with Visual Basic Script debugger: XSLT breakpoints cannot
be put in files with a .vbs extension as there is a conflict
with the Microsoft® Visual Basic Script debugger.
- Watch expressions might show incorrect results on Linux®: To
avoid this problem, keep watch expressions to a minimum and disable them when
stepping. To see the latest value, re-enable watch expressions after stepping
is complete. Alternatively, use inspect expressions instead of watch expressions
if you only need to evaluate the expression once.
- Node highlighting: If node stepping is on, the XSL source file
in the editor view and the XSL source loaded by the transformer must be byte-by-byte
identical, or node highlighting will not work properly.
- Source location attribution must be set to true: This provides
a SourceLocator so that the source location of nodes in the
input (XML) document can be determined (source location is always enabled
for an XSL document). Source location attribution is on by default. For more
information, go to http://xml.apache.org/xalan-j/features.html#source_location.
- Alternate XSLT processors or XML parsers cannot be specified in your Java™ application: The
debugger has a dependency on Xerces and Xalan. You cannot explicitly set the
processor to be Xalan (by overriding the TransformerFactory system property)
- doing this causes debugging to be turned off.
- You cannot serialize/deserialize/clone Xalan components: Debugging
state and references might not be properly resolved at de-serialization. Fields
might not be properly initialized when cloning occurs. Additionally, there
are existing Xalan bugs with serialize/de-serialization/cloning.
- Using custom trace listeners: Using a custom trace listener with
the debugger can cause unexpected results.
- Breakpoints: Breakpoints in the XSLT stylesheet are supported inside
template rules only. For example, breakpoints on global variables are not
supported.
- Generated file length: Generated files greater than 2147483647
bytes are not supported.
- Browser view links and images: Links and images in the browser
view of the Transform Output view will only work if you specify an output
file, and the path of that output file is such that the links and images can
be found. An output file can be specified in the launch configuration.
- XML output in the browser: XML output will not display properly
in the browser until there is a respective closing tag for all tags in the
document. This is a browser limitation.
- Setting breakpoints in input XML documents: If you set a breakpoint
in the input XML document to an XSL transform, the debugger will stop when
that node is the current context node, but only if the breakpoint is set on
the line containing the closing ">" of either the opening tag of the element,
or of the closing tag of the element.
- XSLT Context View: If the node list is sorted, the XSLT
Context view will show the node list in document order instead
of the sorted order.
Multi-language limitations
The following limitations
only apply when you step into a stylesheet from a Java application:
- Drop to frame and Hot code replace: Do not use the drop to frame
and hot code replace features while debugging XSLT called from Java.
- Incremental feature must be off: The incremental feature must be
turned off. When on, the DTM (the internal representation of the input) can
be built incrementally instead of waiting for the entire input to be parsed.
This feature is off by default. For more information, go to http://xml.apache.org/xalan-j/features.html#incremental.
- Limited support for user-supplied URIResolvers in generated source: When
using a custom URI-resolver to resolve imports, includes, and document calls,
the source of the document might not be viewable in the debugger. The transform
will, however, continue.
- External entity references in generated source is not supported: If
the source XML document contains an in-line DOCTYPE with an external entity
declaration in a generated source (SAX or DOM) scenario, subsequent use of
the external entity can cause incorrect results.
- Debugging transforms that use JAXP with DOMSource source objects: When
debugging an XSL transform that uses JAXP with a source object that is a DOMSource,
the SystemId must be set on the DOMSource.
General mixed language debug limitations might also apply when debugging Java that
calls a stylesheet or stylesheets that call Java. These limitations can be found in
the Java and
mixed language debug documentation.