Community
Participate
Working Groups
When I run an XSLT on an XHTML file, Eclipse fails when trying to retrieve the DTD from the remote W3C server. The DOCTYPE declaration is: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> I attempted to run the XSLT with the property "doctype-public" set to "-//W3C//DTD XHTML 1.0 Transitional//EN" with the same result (stack trace below). My understanding is that Eclipse is supposed to use the PUBLIC part of the DOCTYPE to retrieve the DTD from its Catalog (the DTD is present in the "XML Catalog" in Preferences/XML) with its own EntityResolver. Using the JRE's default XSLT processor or Eclipse's Xalan makes no difference. Steps to reproduce: 1) Create an XSL template. 2) Run the template with an XHTML input file that has the appropriate DOCTYPE declaration. -- Stack trace -- 21:21:22,546 INFO [main] Main - javax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl 21:21:22,546 INFO [main] Main - java.endorsed.dirs=D:\Fuente\Eclipse\.metadata\.plugins\org.eclipse.wst.xsl.jaxp.launching\endorsed 21:21:22,546 INFO [main] Main - launchFile: D:\Fuente\Eclipse\.metadata\.plugins\org.eclipse.wst.xsl.jaxp.launching\launch\launch.xml 21:21:22,718 INFO [main] JAXPSAXProcessorInvoker - Setting properties: doctype-public=-//W3C//DTD XHTML 1.0 Transitional//EN 21:21:22,734 INFO [main] JAXPSAXProcessorInvoker - Transforming... 21:21:23,234 FATAL [main] Main - Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd org.eclipse.wst.xsl.jaxp.debug.invoker.TransformationException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd at org.eclipse.wst.xsl.jaxp.debug.invoker.internal.JAXPSAXProcessorInvoker.transform(JAXPSAXProcessorInvoker.java:225) at org.eclipse.wst.xsl.jaxp.debug.invoker.internal.JAXPSAXProcessorInvoker.transform(JAXPSAXProcessorInvoker.java:186) at org.eclipse.wst.xsl.jaxp.debug.invoker.internal.Main.main(Main.java:73) Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.eclipse.wst.xsl.jaxp.debug.invoker.internal.JAXPSAXProcessorInvoker.transform(JAXPSAXProcessorInvoker.java:220) ... 2 more -- Configuration Details -- JRE: 1.6.0_13-b03 Operating System: Windows XP Professional, x64 Edition Product: Eclipse 1.2.0.20090618-0904 (org.eclipse.epp.package.jee.product) Installed Features: org.eclipse.wst.xml_ui.feature 3.1.0.v200905240756-7H6FMVDxtkM-5OgPGKK4xQocS5AL
A couple of questions: 1. What happens when you don't use the JRE Version of Xalan, but instead specifically tell it to use the apache version. You can do this by either setting your Default Transformation engine to Xalan 2.7.1 in the preferences or on the launch configuration. 2. Are you trying to resolve from an XML catalog? 3. Are you able to get this to work using Ant and the XSLT task in ant. http://ant.apache.org/manual/CoreTasks/style.html Currently the SAX reader that is used during the input the the XSLT processor being used does not use a URI Resolver. We would need to extend that during launch configuration.
Ignore the question on the Catalog...currently we dont't resolve against the WTP Catalog or an External Catalog. One thing we need to figure out is how to resolve against the WTP XML Catalog when the launch occurs, since that happens in an External process outside of eclipse. Since this is the case we may have to leverage the Xerces resolver classes so that the transformation can occur correctly. We would just need to point Xerces to where it can find the WTP catalogs to load when it is resolving during the Xalan XML parsing and transformation.
Using the apache version yields the same, that's what I meant with "Using the JRE's default XSLT processor or Eclipse's Xalan makes no difference". What perhaps was unclear in my initial report is that I got these results using the "Run as... XSLTransformation" menu option. I assumed that resolving by the XML Catalog was a natural feature there.
(In reply to comment #3) > Using the apache version yields the same, that's what I meant with "Using the > JRE's default XSLT processor or Eclipse's Xalan makes no difference". > > What perhaps was unclear in my initial report is that I got these results using > the "Run as... XSLTransformation" menu option. I assumed that resolving by the > XML Catalog was a natural feature there. > Yeah, it's something we need to add. I've targeted this for the 3.2 (XSL Tools 1.1) time fraeme. We'll need to create the appropriate resolver properties file and in there have it point to where the WTP catalogs can be found. One possible issue though is that WTP has many of their catalogs contributed by extension point and residing in custom jar files. Unfortunately, this is very Eclipse specific and requires access to some osgi as well as eclipse API methods. We may need to have a process that pre-exports the WTP catalog entries out to the file system and then resolves the entries. Otherwise we may have to limit the support to User Defined entries which should reside on the filesystem where the resolver can access them.
Assigning inbox items to triaged since these have all be triaged.
With recent changes to the XSL Launching and Transformation support to make use of the Apache resolver framework, can somebody do some testing on this to see if this now works if a XML Catalog is provided in the Java System properties. The code still will not read the existing WTP XML Catalog due to the fact that, that interface depends on eclipse code and the transformation runs outside of the current process so doesn't have access to these resources. Use the steps documented here for testing: http://xml.apache.org/commons/components/resolver/resolver-article.html
I'm thinking it would be best to silently assume that the Eclipse Catalog would be used, even if it doesn't support the full resolver -- following the principle of least surprise.
(In reply to comment #7) > I'm thinking it would be best to silently assume that the Eclipse Catalog would > be used, even if it doesn't support the full resolver -- following the > principle of least surprise. We should document how to use the WTP XML Catalog via the xml.catalog.files system property to point the location of the WTP XML Catalog so that it can be used during the transformation. The other option is to inject the property with the wtp xml catlog set already. Patches would be appreciated.
Using the Eclipse WTP catalog is unfortunately a quite a bit harder that it should be: - The user entries use the platform: URI schema extensively, so it's really hard to make this independent of the Eclipse environment - Also the URIResolver isn't set up for the transformation: org.eclipse.wst.xsl.jaxp.debug.invoker.TransformDefinition.setResolverClass(String) is called with the empty string since the launch UI doesn't fill this into the pipline config.
(In reply to comment #9) > Using the Eclipse WTP catalog is unfortunately a quite a bit harder that it > should be: > > - The user entries use the platform: URI schema extensively, so it's really > hard to make this independent of the Eclipse environment > - Also the URIResolver isn't set up for the transformation: > org.eclipse.wst.xsl.jaxp.debug.invoker.TransformDefinition.setResolverClass(String) > is called with the empty string since the launch UI doesn't fill this into the > pipline config. Latest code should be setting the resolver as the apache resolver. If a xml catalog isn't set for it, it'll create a message during the launching that it can't find a catalog. We really need to rework in many ways the way the launching and debugging is happening so that it is easier to add additional functionality. I hate going into that code, and only recently started adding unit tests to the entire launching/debugging code base. But yes you are right, that the way the WTP XML Catalog is setup, it takes a lot more work to try to make it useful outside of WTP.
