At one of my previous customer, we had an ALSB 2.5 installation which uses XMLBeans 2.2 internally for processing XML. There was a requirement to validate inbound XML messages against a 3rd party schema. The schema had some constructs which was recognized only from XMLBeans 2.4. XMLBeans 2.2 classes are there in WLS_HOME/lib folder and hence available in the System CLASSPATH. When we use the Validate action in OSB it always loaded the XMLBeans 2.2 classes from the CLASSPATH and the validate action always failed due to the non support for the new construct.
A solution was proposed to use a custom MDB to do the validation as a pre-requisite stage before passing the XML to ALSB. We followed the best practice of removing Validate action from production build as it is CPU intensive. All validation issues should be flushed out during testing and hence wouldn’t require to do the CPU intensive schema validation at runtime. So this tactical solution was accepted for testing.
We deployed the MDB with the XMLBeans 2.4 classes in the APP-INF/lib folder, but still we could see that 2.2 classes are used for validation.
The reason for this is that Weblogic Classloaders work in a delegation manner where in a query is made to the parent classloaders to search for a class when it is to be loaded. Due to this nature, even though if we put the XMLBeans 2.4 jar within the custom validator application EAR, the actual class that got loaded was the XMLBeans 2.2 one by the System Class loader.
Use Filtering ClassLoaders. Using this feature, we can control the delegation nature of Weblogic Classloaders. We build a MDB which does the XML schema validation in its onMessage() method. The XMLBeans 2.4 jars were put in the APP-INF/lib folder of the EAR. Then added the following construct to the weblogic-application.xml
<prefer-application-packages> <package-name>org.apache.xmlbeans.*</package-name> </prefer-application-packages>
This instructs the application classloader not to delegate to its parent Classloaders for Classes belonging to the package org.apache.xmlbeans and instead load the classes available in the application package.