Here's the scenario:
I've got a logging package that is a wrapper around log4j. This package has its own configurator which talks to a centralized server to retrieve logging configuration information for the server instance.
I never ran into a problem when running in Weblogic (they don't use log4j internally), but I've had some issues while porting to JBoss 4.0.
The Wiki page on classloader configuration (http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration) seemed to offer the perfect solution, but I haven't been able to make it work completely.
My test application is an EJB with a web service endpoint. The EJB jar is packaged inside an EAR, and the log4j jar is also packaged inside that EAR. Here's my jboss-app.xml:
<jboss-app>
<loader-repository>
sipstorm.com:loader=webserviceTest.ear
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
</jboss-app>
Logging is lazily instantiated upon the first application logging call. In debug mode, the first thing the logging package does is retrieve the log4j LoggerRepository and iterate through all loggers in the repository, printing out information about the loggers and what appenders are configured.
When I run in Weblogic, the repository is empty on the first call, as expected. When running in JBoss (without isolating the classloader), all of the loggers configured by JBoss show up, which is also as expected.
If I've done the classloader isolation correctly, my EAR should be using its own instance of the log4j classes, and therefore I should see a completely empty LoggerRepository. Unfortunately, I see all the same loggers already configured in the repository.
Is there something I'm missing? Did I configure the classloader behavior incorrectly?
