Jason Royals wrote:
The reason is that the ./deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml defines two packages that should never be loaded by the webapp class loader - javax.servlet (no surprises there) and org.apache.commons.logging. That surprised me because I can think of no good reason for JBoss to do that. When I remove the filter for commons-logging, everything works and we see our logs.
Before I go ahead and remove this class loader filter for commons logging, I'd like to understand the resoning in having it there in the first place. Am I likely to break anything by doing this?
I don't exactly remember why. But I think it was just due to some older version of JBoss AS adding it in there. Later versions of JBoss AS (like AS6) do not have it there. You can remove it.
Thanks Jaikiran, will remove it and see how we go.
Removing commons-logging from the filteredPackages is risky. It was added to the filteredPackages list because of an issue with (bad design of) commons-logging itself. It scans the entire classloader hierarchy, and throws an exception if there is more than one copy of the jar found. For example, the JBoss packaged one, and one packaged in your application WAR.
Please see this issue discussed in the Commons Logging FAQ, http://wiki.apache.org/commons/Logging/FrequentlyAskedQuestions.