newInstance or newFactory, both have the same problem.

You mean something like XMLInputFactory.newFactory("javax.xml.stream.XMLInputFactory", XmlParserHelper.class.getClassLoader())

Yes, but we should use newInstance(), as newFactory() was introduced with JDK 1.6.18 only.

I like the idea, but it needs more testing than just making the instance non static.

True.

how much benefit do we get by "caching" the XMLInputFactory.

Yes, that's the question. The method seems to make use of the service loader, so its calls are surely not for free, but as this would only affect the usage during bootstrapping it might be acceptable.

Hmm, XMLInputFactory.newFactory("javax.xml.stream.XMLInputFactory", XmlParserHelper.class.getClassLoader()) does not work out of the box.

You mean something like XMLInputFactory.newFactory("javax.xml.stream.XMLInputFactory", XmlParserHelper.class.getClassLoader()). That might be a solution. It depends on the nature of the underlying JAXB issue. I like the idea, but it needs more testing than just making the instance non static.

Making the instance non static clearly solved the problem, whereas fiddling with class loaders might cause other problems. The question is really, how much benefit do we get by "caching" the XMLInputFactory.

Couldn't we just use the newInstance() method which takes a class loader and pass the loader of XmlParserHelper? Then the variable could remain static as we shouldn't leak the deployment's loader anymore?