JBossCache version: 1.4.1SP3/1.4.1SP4.

I have a web application, packaged as a .war, that is targeted towards multiple-versions/multiple-vendors of J2EE. JBossCache is used as the second-level cache for Hibernate, and usually works quite well.

In jboss-web.xml, I keep

java2ClassLoadingCompliance=false

, to avoid conflicts with JBoss's system copies of libraries (this mainly for complete isolation of logging).

In web-inf/lib, I have copies of jboss-common.jar, jboss-system.jar, and jboss-jmx.jar (minus the javax.jmx api classes), along with jboss-cache.jar

The first three jars (system, common, jmx) MUST reside in web-inf/lib for JBossCache to work on non-JBoss appservers.

On appserver 4.0.5GA, this works great.

THE PROBLEM:
It doesn't work on JBoss versions other than 4.0.5. I've tried 4.0.4GA, 4.0.4GA-Patch1, and 4.2.0GA. On these JBoss versions, a vanilla JNDI lookup of a vanilla Datasource object in a servlet's init() method fails in a strange way. The datasource JNDI name is resolved without NamingException, but the object bound to the name is a null.

What seems to be occurring is that because java2ClassLoadingCompliance is set to false, the webapp is getting its own, half-corrupted JNDI tree, originating in the 3 jboss jars in web-inf/lib, instead of the usual system JNDI tree containing the datasource.

I need to be able to instruct the JBossCache of these peculiarities. Such that, when its running in JBoss Appserver, it should obtain its dependencies from the appserver, regardless of java2ClassLoadingCompliance setting.

How can I strip down the JBossCache dependencies to the bare minimum? I don't need to deploy it as a standalone JBoss service, nor monitor its stats via JMX.

If I remove the 3 jboss jars from web-inf/lib prior to deployment, the JNDI lookup works OK on 4.0.4/4.2.0. This is the solution of last resort, since it forces customization of the .war file for specific platforms beyond deployment descriptors, multiplying testing and management efforts.

Any thoughts?