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=6625>.
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=6625

No Locator available to ContentHandler (SAXResult)

           Summary: No Locator available to ContentHandler (SAXResult)
           Product: XalanJ2
           Version: 2.3
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: org.apache.xalan.transformer
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]
                CC: [EMAIL PROTECTED]


I am sending the output from Xalan to a ContentHandler, registered as a 
SAXResult with the processor.

In processing the sax events, I'd like to know the line number in the XSL file 
where the processor is.

The comment on ContentHandler.setDocumentLocator() says:

****
SAX parsers are strongly encouraged (though not absolutely required) to supply 
a locator: if it does so, it must supply the locator to the application by 
invoking this method before invoking any of the other methods in the 
ContentHandler interface.

The locator allows the application to determine the end position of any 
document-related event, even if the parser is not reporting an error. 
Typically, the application will use this information for reporting its own 
errors (such as character content that does not match an application's 
business rules). The information returned by the locator is probably not 
sufficient for use with a search engine.
***

This looks very useful, but unfortunately, Xalan falls into the category of 
parsers (SAX event sources) that don't support this.

So I tried to get arround this, by calling on TransformerImpl.getCurrentElement
(), which gives me line numbers.  But because of the buffering done by the 
ResultTreeHandler, by the time startElement() is called from flushElem(), the 
context in the transformer object is wrong.

Is there any way around this?  The best may be update the caching in 
ResultTreeHandler (like m_name, m_localName, m_url, and m_attributes) to 
somehow keep a Locator object up to date with the pending element and pass 
that object to setDocumentLocator() before processing.

Reply via email to