[ http://issues.apache.org/jira/browse/XALANJ-2252?page=comments#action_12361647 ]
Henry Zongaro commented on XALANJ-2252: --------------------------------------- This problem has previously been reported to the JAXP Expert Group as a usability problem in JAXP 1.3, but the Expert Group has not yet responded. JAXP 1.3 requires the implementation to defer to the installed ErrorHandler in deciding whether to throw an exception, and also requires the default ErrorHandler not to the throw any exceptions. As you've observed that means if TransformerFactory.newTemplates fails because of a fatal error, and the default ErrorHandler is installed, no exception is thrown, and the processor has to carry on and create a Templates object. But of what utility can such a Templates object be in the presence of a fatal error? So Xalan-J returns null. What I would really like is permission to throw an exception when a fatal error is detected, even if the installed error handler chose not to do so. A work-around would be to install your own ErrorHandler which throws a TransformerException or TransformerConfigurationException whenever either of its error or fatalError methods is invoked. > 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]
