struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chappell, Simon P" <Simon.Chapp...@landsend.com>
Subject RE: [OT] RE: log4j integration
Date Wed, 28 Jan 2004 19:18:54 GMT
We do specify the log filenames in each properties file, so we don't have any possibility of
overlap there.

We did have a problem with JRun 4 before we switched to WAS, because it came with an old version
of log4j in it's internal library. This caused us no end of problems and we did have to put
log4j in the server classpath to overcome the issue. This has not been a problem under WAS
4.x

Simon

>-----Original Message-----
>From: Hookom, Jacob [mailto:Jacob.Hookom@redline.mckhboc.com]
>Sent: Wednesday, January 28, 2004 11:33 AM
>To: Struts Users Mailing List
>Subject: RE: [OT] RE: log4j integration
>
>
>Thanks, we are having problems though with multiple 
>applications (basically
>I used commons-logging/log4j on a new project, then it was 
>decided to modify
>another application to also use log4j).
>
>But it seems to create a race condition in the apps as to which
>log4j.properties file actually gets used, one application logs 
>and the other
>doesn't.
>
>The reason I believe they are conflicting is because there was a period
>where both of our applications were outputting to the same log 
>file, despite
>the fact that our log4j jars were in per application scope.  
>It's probably
>another issue with Weblogic that we're going to have to work around :-(
>
>Thanks,
>Jacob
>
>-----Original Message-----
>From: Chappell, Simon P [mailto:Simon.Chappell@landsend.com] 
>Sent: Wednesday, January 28, 2004 11:31 AM
>To: Struts Users Mailing List
>Subject: RE: [OT] RE: log4j integration
>
>Jacob,
>
>We use log4j 1.2.8 and we include the jar file right in out WEB-INF/lib
>directory of our application. The log4j.properties file then 
>lives inside
>the WEB-INF/classes directory. This works well for us on IBM's WAS 4.x.
>
>I've never seen anyone recommend having log4j at the container 
>level, so go
>with it at the application level and forget about conventional 
>wisdom! :-)
>
>Hope this helps.
>
>Simon
>
>-----------------------------------------------------------------
>Simon P. Chappell                     simon.chappell@landsend.com
>Java Programming Specialist                      www.landsend.com
>Lands' End, Inc.                                   (608) 935-4526
>
>"Wisdom is not the prerogative of the academics." - Peter Chappell
>
>>-----Original Message-----
>>From: Hookom, Jacob [mailto:Jacob.Hookom@redline.mckhboc.com]
>>Sent: Wednesday, January 28, 2004 11:08 AM
>>To: Struts Users Mailing List
>>Subject: [OT] RE: log4j integration
>>
>>
>>I'm wondering if anyone has gotten log4j to be deployed 
>within separate
>>apps?  We are having issues with log4j jars and their 
>>properties files being
>>deployed on each application under Weblogic.  Most of what I've read
>>recommends putting log4j at the container level along with a single
>>properties file, but that isn't as flexible as what we want it to be.
>>
>>-Thanks
>>
>>-----Original Message-----
>>From: shirishchandra.sakhare@ubs.com 
>>[mailto:shirishchandra.sakhare@ubs.com]
>>
>>Sent: Wednesday, January 28, 2004 10:20 AM
>>To: struts-user@jakarta.apache.org
>>Subject: RE: log4j integration
>>
>>Hi,
>>Also there is something called 
>>ReloadingPropertyConfigurator..May be this in
>>combination with HierarchyEventListener will do the trick for you.
>>
>>I mean the log4j API is so feature rich, you should not be 
>>required to write
>>something for such a common task.
>>
>>regards,
>>Shirish.
>>
>>-----Original Message-----
>>From: Geeta Ramani [mailto:geeta.ramani@cmpco.com]
>>Sent: Wednesday, January 28, 2004 4:02 PM
>>To: Struts Users Mailing List
>>Subject: Re: log4j integration
>>
>>
>>*Yes*!!  The LogManager is the ticket - I didn't know about 
>>this class, so
>>tried it
>>out.  Works like a charm.. :) Thanks, Shirish (I think?  I 
>>inadvertently
>>erased the
>>response to this question so am not sure of its author..)
>>
>>Geeta
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message