logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject RE: single log file with multiple JVMs vs. multiple class loaders
Date Thu, 03 Mar 2005 17:47:38 GMT
Quoting John.E.Gregg@wellsfargo.com:

> We're doing manual config in the sense that we're calling
> PropertyConfigurator.configureAndWatch().  That might change.  However,
> log4j isn't on the server's classpath, though it is in common/lib.  I know
> this because I removed the log4j.jar file from my ear but left the manifest
> classpath refs in place and got NoClassDefFound errors all over the place.
>

Ok, that makes more sense.  I always get Webphere and Weblogic mixed up in my
head.  You are using Websphere which, apparently, doesn't use Log4j for
logging, since it doesn't put log4j in the server classpath (based on what
you've said). In that case, depending on how Websphere does its classloading,
you may get distinct logger repositories by default.  That is, if two separate
ears can't see each others classloaders, then they would each have their own
logger repository.  As such, as repository selector is not required as long as
each ear configures log4j once for the ear and not for individual webapps,
which is what I think you are saying is the case.

I'm still not sure about your original quesion of whether two separate logger
repositories (2 default logger repositories hosted by 2 application-separated
log4j.jar's) having configured appenders pointing to the same file on disk
would end up clashing.  Because they are running in the same JVM, there is a
possibility that there would be no problem.  I'm just can't say for sure one
way or the other.

> I'll look more carefully at how the repositories work.  I'm not familiar
> with them but if they help solve the problem of multiple log4j configs used
> by different parts of the app (incl. 3rd party jars), I'll be happy.
>

Well, they won't help you with different libraries in the same classloader or
JNDI tree.  What a repository selector does is provide for using a single
log4j.jar at the server level and having each application running under it be
able to have its own configuration within that.  By default, there is only one
logger repository where all your configuration information is stored.  If you
used, for instance, and JNDI-based repository selector, you could have a
separate logger repository for separate JNDI trees, of which each app would
have a separate JNDI tree.  So, configurations/re-configuration in one app
would not affect another app even if all apps are using the same globally
available log4j.jar.

See (some of this is a little dated since Log4j-1.3 improved repository selector
functionality, but this should still provide some good general info)....
http://www.qos.ch/logging/sc.jsp


Jake

> Thanks
>
>
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Wednesday, March 02, 2005 8:28 PM
> To: Log4J Users List
> Subject: RE: single log file with multiple JVMs vs. multiple class loaders
>
>
> At 04:24 PM 3/2/2005 -0600, you wrote:
>  >Each ear is a separate app in the server's eyes.  I believe weblogic is
> >using the equivalent of "multiple" in websphere.  That's ok.  I'm just
> >wondering whether log4j in multiple classloaders in 1 jvm will have the
> same  >log interleaving problem that multilpe jvms has.
>
> Ok, so let me make sure I understand.  You are seeing a static block in
> your log4j wrapper class which exists in a jar of each ear and doesn't
> exist in any classloader above both ears.  Well, that makes sense.  The
> wrapper class would have to get loaded once per visible classloader.  BTW,
> are you doing manual configuration upon application load or are you
> counting on autoconfiguration?  I say this because Weblogic comes with
> log4j in the classpath and since it is configured already, your apps won't
> perform autoconfiguration (even if you have log4j.jar in each ear, they
> will be ignored in favor of the server's).  And if you do manual
> configuration, how do avoid stepping all over Weblogic's configured logger
> repository?  Are you using a repository selector?  I'm really curious how
> your setup works without simply using Weblogic's log4j configuration for
> the server+apps.
>
> Anyway, more specifically to your question, I'm not sure if two separate
> logger repositories writing to one file would cause an issue?  The VM
> manages the file handle, so I'm guessing that it won't be an issue since it
> is all running in the same VM, but someone else will have to speak to that
> more authoritatively.
>
>
> Jake
>
>  >
>  >thanks
>  >
>  >-----Original Message-----
>  >From: Korver, Aaron [mailto:Aaron.Korver@Fiserv.com]
>  >Sent: Wednesday, March 02, 2005 4:17 PM
>  >To: 'Log4J Users List'
>  >Subject: RE: single log file with multiple JVMs vs. multiple class loaders
> >  >  >Is each EAR deployed to it's own appserver?  Or do both EAR's belong
> to the  >same appserver, but fall under different applications?  I know that
> in  >Websphere there is a setting which says "Application Classloader
> Policy".  >The two options are MULTIPLE and SINGLE.  If MULTIPLE is choosen,
> then it  >will use a seperate classloader per application.  Perhaps there is
> a similar  >thing for Weblogic?  >  >> -----Original Message-----  >>
From:
> John.E.Gregg@wellsfargo.com [mailto:John.E.Gregg@wellsfargo.com]
>  >> Sent: Wednesday, March 02, 2005 4:13 PM
>  >> To: log4j-user@logging.apache.org
>  >> Subject: RE: single log file with multiple JVMs vs. multiple class  >>
> loaders  >>  >>  >> Log4j.jar appears once in each ear file, but not
in the
> war  >> file at all.  >> The config file is in a common jar file that is
> included at  >> the root of each  >> ear.  Our war file does not contain
its
> own copy of log4j.jar,  >> log4j.xml/properties, or the common jar.  I
> haven't changed  >> the default  >> class loading of weblogic, so I assume
> the webapp is  >> inheriting from the app  >> when it can't find the jar
or
> config files in its own space.  >> The reason I  >> think log4j is still
> getting initialized twice is that I can see a  >> breakpoint hit in a static
> block for our log4j wrapper.  I  >> believe it's  >> happening once in app
> 1's classloader and once in app 2's classloader.  >>  >> thanks  >>
 >>
> -----Original Message-----  >> From: Jacob Kjome [mailto:hoju@visi.com]  >>
> Sent: Wednesday, March 02, 2005 4:07 PM  >> To: Log4J Users List  >>
> Subject: Re: single log file with multiple JVMs vs. multiple  >> class
> loaders  >>  >>  >>  >> Where do you have log4j.jar?  Where is
the config
> file you  >> think is being  >> used?  >> Do you have the optional
> child-first classloading behavior enabled for  >> webapps or not?  >>  >>
> >> Jake  >>  >> Quoting John.E.Gregg@wellsfargo.com:  >>  >>
> Hi all,  >> >
> >> > I'm aware of the problems with more than 1 jvm trying to write to 1  >>
> > file, but what about multiple class loaders?  In my j2ee  >> app we have 2
> >> > ears, one of which contains a war.  They all use the same log4j  >>
>
> config.  They're deployed to WebLogic 8.1.  There appears  >> to be only 1
> >> > java.exe on my machine (XP Pro), which I believe is for WebLogic,  >>
>
> regardless of whether I deploy both ears or just 1.  (Might  >> that vary
> >> > by OS or java implementation?) That makes me think there's just 1  >>
>
> process writing to the file.  However, I think log4j is being  >> >
> configured more than once because I see our wrapper class  >> get loaded  >>
> > more than once.  Would this cause the same kind of interleaving  >> >
> problems that multiple processes will?  I haven't seen any  >> yet, but we
> >> > haven't started testing heavily yet, either.  >> >  >> >
thanks  >> >
> >> >  >> > John Gregg  >> > Application Systems Engineer 
>> > Wells Fargo
> Private Client Services Technology  >> >  >> >  >>  >>
 >>  >>  >>
> ---------------------------------------------------------------------
>  >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>  >> For additional commands, e-mail: log4j-user-help@logging.apache.org
>  >>
>  >> ---------------------------------------------------------------------
>  >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>  >> For additional commands, e-mail: log4j-user-help@logging.apache.org
>  >>
>  >
>  >---------------------------------------------------------------------
>  >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>  >For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>




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


Mime
View raw message