JBossDeveloper

Thanks, this is so close... but not quite.

I used 4.0.1sp1 (newer than 4.0.1rc2, and if I understand correctly it is a production release rather than beta or release candidate).

1) The release notes in the docs section have a minor error (I noticed it by comparing the config files of 4.0.0 and 4.0.1sp1). The instructions at http://docs.jboss.org/jbossas/whatsnew40/html_single/ say to set tomcat50.sar/META-INF/jboss-service.xml Java2ClassLoadingCompliance to "false". I believe the correct value is "true",as it was in 4.0.0, but I don't claim to understand what it does. With the false value you get a pile of exceptions. With true, it "mostly works".

2) Once setup as above, it no longer throws exceptions and the application's log4j.xml takes over logging as expected. Problem is, it also takes all of the server logging messages! Could it be that the fix that you mentioned was done in 4.0.1RC2 was perhaps done in 4.0.2RC1?

2B) Of course, I might have made a mistake in my log4j initialization (I don't think so, but you never know), so here is my log4j.xml file, loaded from the file system with DOMConfigurator.configure(log4jCfgFile):

< ?xml version="1.0" encoding="UTF-8" ?>
< !DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
< log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
< appender name="rollfile" class="org.apache.log4j.RollingFileAppender">
< param name="Threshold" value="DEBUG"/>
< param name="File" value="/jboss-4.0.1sp1/server/default/log/co.log"/>
< param name="Append" value="true" />
< param name="MaxFileSize" value="500KB"/>
< param name="MaxBackupIndex" value="2"/>
< layout class="org.apache.log4j.PatternLayout">
< param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} %-5p [%C.%M,%L] %m%n"/>
< /layout>
< /appender>

< root>
< priority value ="debug"/>
< appender-ref ref="rollfile"/>
< /root>

< /log4j:configuration>

Just tried 4.0.2RC1... same exact behavior as 4.0.1sp1

If I understand correctly, you are saying that the problem is not supposed to exist in 4.0.2RC1. That was not "completely" my experience.

If you read my last 2 posts you should see that even 4.0.2RC1 still has logging crossover behavior left - now the application logs are being controlled by the application log4j.xml and have no apparent .jar problems, but are being polluted by server-originated messages.

Didn't finish that sentence... "being polluted by server-originated messages ... that should be going to the server logs".

Upon further testing, 4.0.2RC1 is far worse that its predecessors about leaking its jars to the applications encapsulated in EARs.

The latest leak problem I discovered is now with commons-collections. Logging-related leaks were bad, but commons-collections is used so widely that it has thorougly disabled all of our database access. The latest exception is "java.lang.NoClassDefFoundError: org/apache/commons/collections/SequencedHashMap", and it does not occur on ANY of the previous versions.

Seems like the same cause, different symptom. Can't class leakage from jBoss/Tomcat to the EARs be prevented once and for all?

I am really puzzled then. What else can cause a NoClassDefFoundError exception, for a class that is present inside the commons-collections.jar in WEB-INF/lib, and only happen in 4.0.2RC1 but not in all other versions?

I have added a new coA.ear (and supporting files) to the JBAS-1551 bug report that demonstrates both problems:

(1) Logging is still not properly isolated (even in 4.0.2RC1). In 4.0.x there are no longer any exceptions, and the app controls the logging, but the app log also incorrectly captures all messages that should be going to the server logs. The app should not have visibility to those messages.

(2) 4.0.2RC1 (only that version) has new problems with other JARs (commons-collections.jar for one, as mentioned in earlier posts).