|Why do I get a "java.lang.IllegalAccessError" or the message
"Could not load the property file 'output_xml.properties'" when I try
to transform using XSLTC or Xalan-Java Interpretive?|
These errors may occur if you use JDK 1.4 or later releases.
JRE 1.4 and later releases contain copies of Xalan-Java. In some
cases, the JRE includes only Xalan-Java Interpretive, while in other cases it also
includes XSLTC. Typically, the copy of the processor packaged
with the JRE will be loaded in preference to any copy of Xalan-Java on
your class path.
Beginning with Xalan-Java 2.5, Xalan-Java Interpretive and XSLTC are both
packaged in xalan.jar, and share some of the same classes. If you
are using a version of the JRE that contains Xalan-Java Interpretive, but not
XSLTC, and you try to use XSLTC on your class path,
classes from that version of XSLTC may be loaded along with
classes from the version of Xalan-Java packaged with your JRE.
Because the classes may be from different versions of Xalan-Java, the
results may be unpredictable. In particular, a
java.lang.IllegalAccessError may be thrown, or an
"Could not load the property file
'output_xml.properties' for output method 'xml' (check
CLASSPATH)" may be thrown.
To work around those problems, please read the FAQ entitled
Issues running Xalan-Java on JDK 1.4.
|How do I get line numbers for errors in the XML or XSL input when I am performing a
Use or mimic the command-line processor (org.apache.xalan.xslt.Process).
TransformerException generally wraps another exception, often a SAXParseException. The command-line processor uses the static
org.apache.xml.utils.DefaultErrorHandler printLocation() method to chase down the exception cause and get a
SourceLocator that can usually report line and column number.
Suppose you wanted to modify the ValidateXMLInput sample in the samples/Validate
subdirectory to include line and column numbers . All you need to do is call
DefaultErrorHandler.printLocation() in the the Handler internal class error() and warning()
methods. For example, replace
public void error (SAXParseException spe)
System.out.println("SAXParseException error: " + spe.getMessage());
public void error (SAXParseException spe)
PrintWriter pw = new PrintWriter(System.out, true);
pw.println("SAXParseException error: " + spe.getMessage());
You can also replicate code from the printLocation() method to obtain a SourceLocator, and
then use the SourceLocator getLineNumber() and getColumnNumber() methods. The
getRootSourceLocator() method below returns a SourceLocator.
public static SourceLocator getRootSourceLocator(Throwable exception)
SourceLocator locator = null;
Throwable cause = exception;
// Try to find the locator closest to the cause.
if(cause instanceof SAXParseException)
locator = new SAXSourceLocator((SAXParseException)cause);
else if (cause instanceof TransformerException)
SourceLocator causeLocator =
if(null != causeLocator)
locator = causeLocator;
if(cause instanceof TransformerException)
cause = ((TransformerException)cause).getCause();
else if(cause instanceof WrappedRuntimeException)
cause = ((WrappedRuntimeException)cause).getException();
else if(cause instanceof SAXException)
cause = ((SAXException)cause).getException();
cause = null;
while(null != cause);
Xalan-Java exception handling: The exception architecture
in Xalan-Java and with transforms in general is tricky because of
multiple layers of exception handling, involving movement back and forth between SAX and
Transformer exceptions and across pipes. Xalan-Java often uses a
WrappedRuntimeException to throw over many layers of checked exceptions, in order not to
have every possible checked exception be declared for every function in the stack, which
means it has to catch this exception at the upper levels and unwrap the exception to pass
it on as a TransformerException.
A JAXP 1.3 TransformerException often wraps another exception. Two of the
TransformerException structures that are frequently used to construct contained exceptions
in JAXP 1.3 do not set the locator. The locator is not set because we don't know the type
of exception that the Throwable argument represents. The solution is to chase up the
contained exceptions to find the root cause, which will usually have a location set for
you. This can be somewhat tricky, as not all the exceptions may be TransformerExceptions.
A good sample is in the DefaultHandler static printLocation() method, which the
Xalan-Java command-line processor uses to report errors. You can also
roll your own functions along the lines of the getRootSourceLocator() example above.