Quantcast

No caching of JAXBContext if MoxyXmlFeature is used - why?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

No caching of JAXBContext if MoxyXmlFeature is used - why?

Joachim Kanbach
Hi all,

I use MOXy as JAXB implementation (on Payara) and I need to pass properties to the JAXBContext created by Jersey in order to disable MOXy's Bean Validation introduced in EclipseLink 2.6. For JSON, that's easy (implement a Feature and pass the properties to the FeatureContext).

As for XML, I realized that the designated way for passing properties to the JAXBContexts created for XML (un)marshalling seems to be to use the MoxyXmlFeature and pass the properties to its constructor. This works as expected, but through debugging some Jersey classes, I noticed that there's apparently no more caching of JAXBContexts if MoxyXmlFeature is enabled. As far as a I know, creating a JAXBContext is relatively expensive, the unofficial guide recommends to cache them: https://jaxb.java.net/guide/Performance_and_thread_safety.html

Without MoxyXmlFeature, AbstractJaxbProvider cannot find a ContextResolver<JAXBContext> so it creates the JAXBContexts itself and then caches them (in order to be able to still use MOXy for XML, one of course has to provide a jaxb.properties file that points to MOXy's JAXBContextFactory).

But if MoxyXmlFeature is activated and AbstractJaxbProvider delegates to MoxyContextResolver for getting the JAXBContext, the result is cached nowhere.

My question: is there a particular reason for this or is it merely an oversight? It looks like the implementation of getJAXBContext() in AbstractJaxbProvider wants to make sure that it's possible for a ContextResolver<JAXBContext> to always return a new instance of JAXBContext. Is that necessary in other contexts? So maybe one could extend MoxyContextResolver with caching instead?


Best regards,
Joachim Kanbach
Loading...