Log4J 1.2.12

[damien]

Has anyone tried to use the newly released Log4J 1.2.12 with JBoss yet? I've tried simply dropping it in, as well as building JBoss with the new Log4J jar file. Neither of these approaches seem to work.

I can't seem to get past this problem: ERROR: invalid console appender config detected, console stream is looping.

This is an internal JBoss error which seems to be generated as a safeguard for invalid configuration. What it seems to be picking up is the fact that run.jar has log4j.properties files in it, and when the server-level log4j.xml gets loaded there are then multiple CONSOLE appenders defined. I'm not sure how they were getting around this fact with the old log4j library, and why it doesn't work with the new one.

If anyone has any insights, solutions, or suggestions, I'd love to hear them.

[louisaj_work]

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)

[louisaj_work]

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:
http://wiki.jboss.org/wiki/Wiki.jsp?page=Logging
See: Repository Selector

[louisaj_work]

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.