Thanks. 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... sebb-2-2 wrote: > > On 2 May 2012 21:41, Guillaume Bilodeau <guillaume.bilod...@gmail.com> > wrote: >> >> 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? > > Looks to me like you are using the version of Xalan bundled with Java. > You'll need to raise the issue with Oracle. > > The ASF version uses package names starting with org.apache. > > -- View this message in context: http://old.nabble.com/Xalan-DTMManager.newInstance-performance-issue-tp33763395p34007770.html Sent from the Xalan - J - Users mailing list archive at Nabble.com.
