Saxon

One of the problems with the ErrorListener interface in the JAXP TransformerFactory is that it's very hard to write an ErrorListener that's thread-safe and that works meaningfully if multiple XSLT compilations are carried out in parallel. We didn't want to perpetuate that problem, which is why we only made the ErrorReporter settable at the XsltCompiler level. (That still gives a potential thread-safety issue, but you can avoid it easily by creating a new XsltCompiler for each compilation.)

I guess we could tackle this by allowing something like

transformerFactory.setAttribute(Feature.XSLT_COMPILER_ERROR_REPORTER_FACTORY, source -> new MyErrorReporter(source))

Currently a number of callback APIs can be controlled with configuration properties whose value is a classname, where we instantiate the class on demand. That approach has the benefit that the property can be expressed as a string, for example in a configuration file or in an environment such as Ant. But it's not ideal, because an error reporter for a particular stylesheet compilation really wants to know what stylesheet it's compiling at the time...

Sorry, idle ramblings here about how we might improve the situation. In the meantime I think you're right: to take advantage of the ErrorReporter interface for XSLT compilation errors, you need to wean yourself off JAXP onto s9api.

Thanks for your reply. At least I know now, that I can stop searching for a solution that works with JAXP. (And in fact your "idle ramblings" were quite interesting, too.)