I presume what you are saying here is you need a dedicated logging for
yr application without interfrence of JBoss logging.
If thats the case then you need a dedicated appender say
<appender name="YR_FILE" class="org.jboss.logging.appender.RollingFileAppender"> -------Path of appender and other setting comes here -------- </appender>
So what you need is to get the logger you have used in yr application,
get that logger in log4j.xml config file.
<logger name="au.com.j2ee.MyLogger" appenditvity="false"> <appender-ref ref="YR_FILE" /> </logger>
Don't attach this appender to logger ...and as long as yr appender name is
unique in the sense that loggers of JBos are not using that appender, so be careful with the name of appender.
I hope this helps.
No, I am not just talking about separate logging via an appender.
I am talking about being able to have ALL logging jar and configuration in the WAR/EAR - with ZERO interaction or dependency on jBoss.
As a matter of fact, I am even talking about my application having its own jars for all of the apache commons libraries and NEVER see the logging, commons, dom, etc jars from jBoss. Log4j is just a symptom of a much bigger problem.
This is essential if you are going to build an application that is to be deployed in multiple servers. The EAR has to be built once, including all the jars that it relies on, and be deployed - untouched - to jBoss, Weblogic, Websphere, etc.
The solutions I have seen proposed all rely on the log4j.jar from jBoss. If the log4j.jar in the application is a different version than jBoss' then everything breaks. This is the jBoss configuration problem that I need to fix.
Did you get a solution to your problem?
I am trying to do the same thing with no luck, yet.
I don't want to have to change jBoss's log4j.xml file on every machine I install my application to. Also, it is much cleaner to maintain everythign related to your application in the application's dir only.
Please post your progress on this issue.
I made some progress, but not as much as I'd like. Here is what I found:
1) The WAR approach in the WIKI above separates the logging, but does not seem to produce truly separate classloaders... if I have a log4j.jar in my WAR and is of a different version, or if I have 2 WARs with a class of the same name but different content... then I still have problems.
2) The EAR approach, similar to (1) but using jboss-app.xml in the EAR instead of jboss-web.xml in the WAR works on jBoss 3.2.3 (mostly), but does not work on jBoss 3.2.6 or jBoss 4.0.1. I suspect that it might work on jBoss 4.0.0 because it is J2EE 1.4 compliant, but I have failed at all attempted downloads of that version.
3) I have submitted a bug report, but I have not heard even a peep of an acknowledgement that anyone even read it.
I hope this helps others, and that a proper solution will eventually appear.
This is the single biggest problem that jBoss has, and its solution is now mandated by the J2EE 1.4 standard that jBoss "claims" to meet (of course, you have to know the secret setup to accomplish it - because the instructions in the release notes for jBoss 4.0.1 do not work).
The unified classloader is a great concept - as long as it is not the "only way" and it is not used to lock people out of the "write once run anywhere" concept of java or is used to lock people into one application server. That may not be jBoss' intention, but it sure looks that way.
I'm using jBoss 4.0.1sp1. My log4j.jar is version 1.2.9.
I played around with the logging. I like to use log4j.properties. I have been able to seperate the logging between jboss and myapp.war (I'm fairly new to all this, so have no idea how an EAR works). I have updated the wiki:
However, I still have to change jboss-service.xml on every server. I am checking to see if the approach outlined in the link above will work without doing that. Will post what I find, soon.
The log4j.jar in server/default/lib is 1.2.8.
The log4j.jar in server/default/deploy/myapp.war/WEB-INF/lib is 1.2.9.
The log4j.properties system described in the wiki works even with different versions of jars being used by jBoss and my application. Does this mean something?
I tested it out. If I want to use log4j.properties in my application, I will HAVE to make the required change in jboss-service.xml, i.e. rename the resource file that jBoss uses to pick up its log4j settings (conf/log4j.xml -> conf/jboss-log4j.xml).
This is the precedence used by log4j so there is no way to preferentially load a log4j.properties file using the default search mechanism if there is a log4j.xml on the classpath search path. We should probably just rename our file to avoid the conflict.
That should solve this issue.
What difference, does it make, if I have different versions of log4j (as describe in the post above)i.e., a diff version in server/default/lib (call it version A)and a diff version in server/default/deploy/myapp.war/WEB-INF/lib (call this version B)?
Since jBoss has already loaded log4j before it begins to load my application, is version A running/loading my log4j.properties or is the one I have supplied, version B, loaded again, being used by my application?
karanmg, I used the approach you mention in some of my tests. It seemed to work for isolating log4j, but did nothing for keeping EARs separate from each other.
Redefining the problem one more time:
I need total isolation of the contents of the EAR (like J2EE 1.4), including the logging.
That way everything needed can be in the EAR, the EAR can be deployed to ANY version of the server, any server vendor, and logging is configured in the EAR and utterly independent.
jBoss "claims" to allow this and there are some instructions - like the one referenced - that solve part of the problem. But I have yet to find a single set of instructions that solves the problem "completely".
At our company we are getting very close to dumping jBoss and declaring it unsupported because of this issue. A sad situation, since our focus is on open source.
The existing log4j.war example from the wiki works fine for me under jboss-4.0.1. I have updated the snoop.jsp to display the log4j Logger codesource and the log4j.xml. Both are seen to come from the war:
Logger CodeSource: (file:/C:/cvs/Releases/jboss-4.0.1/server/log4j/deploy/log4j.war/WEB-INF/lib/log4j.jar <no certificates>)
log4j.xml resource: file:/C:/cvs/Releases/jboss-4.0.1/server/log4j/deploy/log4j.war/WEB-INF/classes/log4j.xml
I also do not see any bug report related to this in jira, so point out the issue url.
My apologies. I seem to be having trouble conveying the problem. This might be detailed and long, but let me try again:
A) The WAR approach you mention works fine to separate "just" the logging from jBoss. I have tested in 3.2.3, 3.2.6, 4.0.0 (finally succeeded in download) and 4.0.1.
B) The second part of the problem is to separate code (any code) between one WAR and another. This is necessary for "write once deploy anywhere". The following are the scenarios I followed:
B1) Although I expected a conflict, I created 2 WARs as per (A), both containing a servlet "TestServlet.java" that displayed "Hello 1" or "Hello 2" on the console when deployed, depending of which WAR. As expected both displayed the string from the WAR that was deployed first.
B2) Found some instructions in the jBoss site to accomplish (A) using EARs. The instructions were virtually identical, except for requiring META-INF/jboss-app.xml instead of jboss-web.xml and also needing META-INF/application.xml.
B3) Deployed it on 3.2.6 and got log4j exceptions. Stripped it down to the point that there isn't even log4j code in the EARs, just the presence of log4j.jar (of a different version than jBoss) in the WEB-INF/lib. It seems that jBoss commons-logging.jar is trying to call the WAR's log4j.jar.
B4) Tested on other jBoss versions. 3.2.3 works fine. 4.0.0 works fine. 4.0.1 does not work, even after following the release notes to make it compatible with J2EE 1.4 as 4.0.0 was.
B5) Reported problem as bug JBAS-1551. The two EARs and TestServlet.java are attached there.
Ultimately, the goal is to build EARs that are "build once, deploy anywhere" for any jBoss version (in its default "as downloaded" configuration) as well as servers from other vendors, and have no log4j problems nor conflicts with any classes in other EARs that might have the same package/class names.
I hope this long description helps understand the problem, and that a solution can be found.