Weblogic application classloading
We wanted to use our own stax parser implementation in a web application deployed on Weblogic 9.2. The user guides and BEA forums suggested two approaches.
1. Using weblogic.xml web application deployment descriptor with <prefer-web-inf-classes> element. Setting this to true allows a Web application to use our own version of a third-party class
2. Using filtering classloader
Here we are allowed to explicitly specify packages which are required to be loaded from the application. These packages can be listed in weblogic-application.xml
I tried both approaches separately in order to use wstx-asl-3.2.1.jar shipped with our application instead of loading weblogic stax parser.
Unfortunately, both class loading mechanisms failed to pick up our stax parser :(
We even tried to hack weblogic.jar by editing property files which tightly map the parser interface to the impl*. We extracted weblogic.jar and edited the stax impl class entries (i.e:- com.ctc.wstx.sax.WstxSAXParserFactory) of the following 4 files included in META-INF/services directory.
javax.xml.parsers.SAXParserFactory
javax.xml.stream.XMLEventFactory
javax.xml.stream.XMLInputFactory
javax.xml.stream.XMLOutputFactory
However, weblogic reported version conflicting issue when restarting server with the edited weblogic.jar.
I did not encounter these class loading problems with JBoss or tomcat. I'm uncertain about why it is such a pain in configuring a commercial product like Weblogic to use application specific packages.
1. Using weblogic.xml web application deployment descriptor with <prefer-web-inf-classes> element. Setting this to true allows a Web application to use our own version of a third-party class
2. Using filtering classloader
Here we are allowed to explicitly specify packages which are required to be loaded from the application. These packages can be listed in weblogic-application.xml
I tried both approaches separately in order to use wstx-asl-3.2.1.jar shipped with our application instead of loading weblogic stax parser.
Unfortunately, both class loading mechanisms failed to pick up our stax parser :(
We even tried to hack weblogic.jar by editing property files which tightly map the parser interface to the impl*. We extracted weblogic.jar and edited the stax impl class entries (i.e:- com.ctc.wstx.sax.WstxSAXParserFactory) of the following 4 files included in META-INF/services directory.
javax.xml.parsers.SAXParserFactory
javax.xml.stream.XMLEventFactory
javax.xml.stream.XMLInputFactory
javax.xml.stream.XMLOutputFactory
However, weblogic reported version conflicting issue when restarting server with the edited weblogic.jar.
I did not encounter these class loading problems with JBoss or tomcat. I'm uncertain about why it is such a pain in configuring a commercial product like Weblogic to use application specific packages.
Comments