DO NOT REPLY [Bug 7661] New: - XSLTC using trax.dom wrapper throws "Could not compile stylesheet"

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7661>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7661

XSLTC using trax.dom wrapper throws "Could not compile stylesheet"

           Summary: XSLTC using trax.dom wrapper throws "Could not compile
                    stylesheet"
           Product: XalanJ2
           Version: CurrentCVS
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: org.apache.xalan.xsltc
        AssignedTo: xalan-dev@xml.apache.org
        ReportedBy: curcuru@apache.org


cd test
build conf.xsltc -Dconf.xsltc.flavor=trax.dom

BUG: all tests (you might as well CTRL-BREAK now) will throw an exception.  Note 
that part of the information is *only* printed to the System console, which 
should really be included in the exception.

For each xsl file, the console shows:
   ERROR: The input document is not a stylesheet (the XSL namespace is not 
declared in the root element).

The stack trace is:
javax.xml.transform.TransformerConfigurationException: Could not compile 
stylesheet
	at 
org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFacto
ryImpl.java:515)
	at 
org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFac
toryImpl.java:357)
	at 
org.apache.qetest.xslwrapper.TraxDOMWrapper.transform(TraxDOMWrapper.java:233)
	at 
org.apache.qetest.xsl.StylesheetTestlet.testDatalet(StylesheetTestlet.java:246)

Relevant code showing a very straightforward way to use DOMs to process is in 
TraxDOMWrapper; note that the parser that created the DOM was namespace aware.

(Or: does XSLTC support plain DOMSource objects yet? Or is this a mistaken 
assumption somewhere in the wrapper's code?)