Question

We have inherited an application (Java-based, running on WebLogic 10.3.5) that makes extensive use of JSTL XML tags, and particularly of XPath selectors. Quickly we have run into some performance problems due to the implementation of these tags and how the DTMManager class is first resolved then instantiated by the DTMManager.newInstance method.

The DTMManager class name lookup issue has been previously documented and was solved by setting the com.sun.org.apache.xml.dtm.DTMManager system property.

However, once the class name has been found, the com.sun.org.apache.xml.internal.dtm.ObjectFactory.findProviderClass method asks the (not null) class loader to load the class definition and it never caches the result! In a WebLogic environment, this operation is very expensive and eats a significant portion of our response times.

Is there a reason why the class definition is never cached? And is there a way to avoid the class definition to be loaded every time?

Thanks a bunch.

Update Similar behaviour can be observed for the com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory class – the ClassLoader reloads the class definition on every call to DTDDVFactory.newInstance.

Answer 1

It seems not much can be done about that other than avoiding extensive use of these tags. We have refactored this code section:

• XML parsing is now performed by a custom tag that uses JAXB to populate an object graph generated from a XSD, and
• JSPs now use standard notation to consult the object graph

Just shows that doing XML parsing in a JSP isn’t a particularly good idea…