[
http://issues.apache.org/jira/browse/XALANJ-2252?page=comments#action_12361658
]
Antonio Arena commented on XALANJ-2252:
---------------------------------------
Henry, thank you for your response. I already used something similar to your
workaround for my application. BTW, I also added an ErrorHandler to XERCES. I
think it's correct that an application knows what's happening and to write
errors to its own logs.
I'm a bit confused though on the specs:
1) the newTemplates method should *never* return a null Templates object
2) TransformerFactory.setErrorListner states: Set the error event listener for
the TransformerFactory, which is used for the processing of transformation
instructions, and not for the transformation itself.
What does this mean? That XALAN shouldn't log the error and just throw a
TransformerConfigurationException?
3) Some excerpts from ErrorListener class javadoc:
a) To provide customized error handling, implement this interface and use
the setErrorListener method to register an instance of the implmentation with
the
Transformer [...]
b) [...] Note however that the Transformer is not required to continue with
the transformation after a call to fatalError(TransformerException exception).
So does this mean that XALAN could just quit by throwing some kind of
RuntimeException?
What should I expect from this? Should I have a Transformer object even in case
of fatal error? Something like a NullTransformer that does nothing?
Or should XALAN just throw a plain old TransformerConfigurationException in
these cases?
BTW, I also saw that at line 928 in TransformerFactoryImpl a SAXException is
caught, logged, and then builder.getTemplates is returned. Why are there two
different policies in the same piece of code?
> TransformerFactoryImpl.newTemplates is broken according to JAXP 1.3 specs
> -------------------------------------------------------------------------
>
> Key: XALANJ-2252
> URL: http://issues.apache.org/jira/browse/XALANJ-2252
> Project: XalanJ2
> Type: Bug
> Components: transformation
> Versions: 2.7
> Environment: JDK 1.3 and/or 1.4 (use Xalan with endorsed mechanism)
> Reporter: Antonio Arena
> Priority: Critical
>
> According to the JAXP 1.3 specs:
> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/transform/TransformerFactory.html#newTemplates(javax.xml.transform.Source)
> or according to the JAXP 1.2 specs:
> http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/TransformerFactory.html#newTemplates(javax.xml.transform.Source)
> the newTemplates method *never* returns a null Templates object.
> I created an XSL file that used a variable that wasn't declared. This causes
> the org.apache.xpath.operations.Variable class to throw a
> WrappedRuntimeException that looks like this when written to System.err:
> 2005-12-30 11:12:19 StandardContext[/enginframe]:
> file:/opt/bruno/412b/enginframe/plugins/filemanager/WEBAPP/layout.xsl; Line
> #22; Column #62; org.apache.xml.utils.WrappedRuntimeException: Could not find
> variable with the name of img_path
> My code, since I've been using Xalan 2, does the following:
> ...
> Templates templates = fetchTemplates(source);
> if(templates == null) {
> templates = transformerFactory.newTemplates(source);
> // store templates object and use it
> // now I get a NPE !!!
> ...
> }
> ...
> I couldn't understand why using Xalan 2.6.0 the newTemplates method would
> throw a TransformerConfigurationException while using Xalan 2.7.0 I get a
> NPE. So I investigated the code and I found out that the DefaultErrorHandler
> class changed exception handling policy. In Xalan 2.6.0 it would just rethrow
> the TransformerException, while in Xalan 2.7.0 it prints it to System.err.
> Now (Xalan 2.7.0) at line 951 in TransformerFactoryImpl, after logging the
> fatal error that isn't rethrown, a null Templates object is returned. This
> breaks the specs. In Xalan 2.6.0 this didn't happen because the fatal error
> is rethrown (so line 821 in TransformerFactoryImpl of Xalan 2.6.0 is never
> executed!)
> I assigned critical to this bug because I've had crash and loss of data. No
> priority level exists for breaking specs ;)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
