I have had some limited success with it. I have managed to use log4j 1.2.12 in a deployed web app, it was by including the jar in WEB-INF/lib and declaring the following in the applications jboss-service.xml (again in WEB-INF):
<jboss-web> <class-loading java2ClassLoadingCompliance="false"> <loader-repository> application.some.com:loader=application.war <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> </class-loading> </jboss-web>
This does something to prevent jboss from classloading in a particular fashion and forces the application to use the classes included in it's lib before jboss's available classes. This means that if you include log4j in your web-inf/lib and included a log4j.xml in web-inf/classes, that will get loaded for your web-app. I originally did this since I wanted to use the xml format for my log4j config files in my web-applications. (Jboss 3.2.3 doesn't seem to correctly allow an application to configure log4j using the xml file otherwise).
While this does work, it doesn't exactly play nicely with jbosses consoles (you end up getting something like this in your logs:
2005-10-12 04:30:13,093 INFO [STDOUT] 2005-10-12 04:30:13,093 INFO [com.domain.package.class] Logged statement 2005-10-12 04:30:13,253 INFO [STDOUT] 2005-10-12 04:30:13,253 DEBUG [com.domain.package.class] Another logged statement
This seems to stem from the way that JBoss captures stdout and shunts it through its own log4j appenders.
I worked around this by creating appenders in my jboss log4j.xml file that acts like a plain stdout (ie: has no pattern layout):
<appender name="STDOUT" class="org.apache.log4j.ConsoleAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="Target" value="System.out"/> <param name="Threshold" value="DEBUG"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%m%n"/> </layout> </appender>
I also declared one as a stdout log file appender to capture everything that comes out of the server without formatting it. (The downside to this is that any actual system.out/err.print statements don't get timestamped)
Then I point the root logger at the stdout appenders and the org.jboss and org.apache loggers to use the default jboss appenders. This leaves any log4j statements from web-applications to dump using their own declared format to the stdout console/file and/or to their own appenders. (avoiding the extra log4j INFO [STDOUT] prefix)
JBoss seems to document another technique, I don't know if it will force your application to call on an included log4j.jar or not but here's the URL:
See: Repository Selector
Hmm.. while the RepositorySelector does allow you to specify your own log4j configuration, it does not use the log4j file supplied in WEB-INF/lib. To force your application to do that you would have to use the Class Loader Scoping option mentioned higher up on the same page.