Saxon

Probably this "net.sf.saxon.Configuration.reuseStyleParser(XMLReader)" is the cause for my problems and it is not something I can control by setting an option.

Also here:

net.sf.saxon.lib.DirectResourceResolver.resolve(ResourceRequest) the style parser is used:

ss = new SAXSource(config.getStyleParser(), is);

although the resolver may be called from a document() or doc-available function.

Also in this place: net.sf.saxon.Configuration.loadParser() Maybe it should ask the XML reader maker to create the XML reader if available.

For now I made two patches on our side, one in the DirectResourceResolver, to avoid using the style parser for xml nature calls :)

ss = new SAXSource(! ResourceRequest.XML_NATURE.equals(request.nature) ? config.getStyleParser() : null, is);

and two patches in the Configuration class to use the XML reader maker on the net.sf.saxon.Configuration.getSourceParser() call and to disable completely the sourceParserPool.

In general I think that maybe once the user sets an xml reader maker maybe the sourceParserPool could be disabled and the xml reader maker could be used instead.

The Javadoc could be much clearer about the exact circumstances in which the parse options set using setParseOptions() are used. Unfortunately it would be a very lengthy description! There are 33 direct references to the field defaultParseOptions, and 54 places that call getParseOptions(), so it's hard to know where to begin.

It does feel very wrong that DirectResourceResolver is invoking the StyleParser, this should only be used for stylesheets and schema documents.

Thanks for the update Michael. I do not know precisely the reason of the sourceParserPool, is it speed? Does creating xml readers instead of reusing them cause that much delay that it's worth adding a parser pool? Could there maybe be an option to control if the parsers are reused or not. In my opinion if the xml reader marker is set, it should be used more often instead of using the parser pool.