Hi Dave,
> Can you describe in more detail what you're doing, and > what parts of the current mechanism work for you, and what could be > improved (aside from obvious requirement of consistent behavior)? Sure, in my application, which is multi-threaded, I have a framework for reporting error/debug messages that occur. I want to be able trap all error messages from xalan and reroute them through my framework. At first I was just using getLastError but this did not provide the details (such as source file, line, and column) that I wanted. I have several xsl files and without a source file name there is no easy way to locate the problem file. I came across the setProblemListener() in the XalanTransformer api and that seemed like what I wanted (though I was confused for awhile with the setWarningStream() method, what does it do anyway?). I then realized that I should also have an ErrorHandler for parsing related errors. I understand why this is because I also use xerces in another part of my application and that's how they handle errors and such. The parsing errors weren't going to the ProblemListener so I thought everything was cool. I took out the calls to getLastError() because I had thought that was covered and of course this was not the case. So now I have all three and most of the time I get two error messages reported, which is sort of anonying, but gets the job done. I like the detail that is provided with the ProblemListener and being able to redirect messages that xalan normal sends to cerr/cout. Thanks, -Corey
