[slf4j-user] Per-web-app logging with jars on the server's classpath

[Jacob Kjome]

Quoting Mark Stralka <mstralka at gmail.com>:

> Jacob Kjome <hoju <at> visi.com> writes:
>
> >
> >
> > What are you doing to install the repository selector?  Are you doing it
> > programatically or via the System property?  For instance, here's the
> System
> > property to set in Weblogic's startup script...
> >
> > -Dlog4j.repositorySelector=JNDI
> > OR
> > -Dlog4j.repositorySelector=com.mycompany.MyCustomSelector
>
> I am doing it programatically in each webapp's StartupListener:
> public void contextInitialized(ServletContextEvent event) {
> ...
>   LogManager.setRepositorySelector(new ContextJNDISelector(), null);
> ...
> }
>
> I will also try using -Dlog4j.repositorySelector=JNDI
>

You should use the System property if you can.  If you have to use the
programmatic call, you'll need to change it slightly.  Your "guard" object is
null.  If you are doing this in every webapp, it is possible that you are
simply re-setting the logger repository selector for every single call to
setRepositorySelector().  The theory is that, because the "guard" object is
null, a null value on successive calls matches the existing guard and allows
the repository selector to be reset, which is what the "guard" was meant to
prevent.  I suggest you pass in something like "new Object()".  This will act
as a guard that no successive call will be able to replicate and, therefore,
the repository selector will be set once with no chance of being re-set later,
which is what you want.

> >
> > Oh, and I presume your "log4j_webapp.properties" is sitting in the default
> > package in the classpath of the webapp, such as in the "WEB-INF/classes"
> > directory, right?  Or, you can also have it on the System classpath if you
> want
> > all apps to use the same config file.  It uses the context class loader, so
> it
> > should attempt to look it up first in the classloader from which the thread
> was
> > initiated and fall back to the system classloader via standard classloader
> > delegation.
>
> Each web app looks like this:
> WEB-INF/classes/log4j_webapp.properties
>

Good, that's the location I was expecting.  The contents of the file are
irrelevant to this issue.

> Each log4j_webapp.properties file looks like this (and
> com.myframework.xxx is from myframework.jar, which is on
> weblogic classpath)
>

<SNIP>

>
> >
> > BTW, there's also a utility for removing logger repository for an app
> when it
> > shuts down, though I'm not sure it's yet included in the latest 1.3alpha
> jar
> > available for download, but is in the SVN source [1].  We really need to
> create
> > another alpha release to pick up changes over the last, well..., a little
> over a
> > year.  For this reason, I actually suggest that you build Log4j-1.3 from
> source
> > instead of using the existing downloadable binary.
> >
> > [1]
> >
> http://svn.apache.org/viewvc/logging/log4j/trunk/src/java/org/apache/log4j/
> selector/servlet/ContextDetachingSCL.java
> >
> > Jake
> >
>
> I am using 1.3alpha8 from source - what is the utility for removing logger
> repository during shutdown?
>

Good.  It's good that you built from source.  Your question is not clear,
though.  Did you mean "what is the utility for" or "what is the utility *of*"? 
If the former, I pointed you to it in the link above.  If the latter, the
utility is the ability to clean up resources that are no longer needed.  If
your application gets undeployed, what's the point in keeping the logger
repository there?  It serves no purpose and can be thought of as a memory leak.
 If the app is deployed again, it will re-created.  If you are not concerned
about the cleanup, then you don't need to bother with this, but the utility is
there for your use if you care.

Jake

> Thanks again
>
>
> _______________________________________________
> user mailing list
> user at slf4j.org
> http://www.slf4j.org/mailman/listinfo/user
>