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 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. 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 Quoting Mark Stralka <[EMAIL PROTECTED]>: > Jacob Kjome <hoju <at> visi.com> writes: > > > > > > > Your repository selector is based on classloader, right? Doesn't > > JBoss use a "Unified Classloader" strategy? That is, every app > > running on the server uses the same classloader? That is, unless it > > is configured otherwise. If this is truly the case, then you > > repository selector will not separate logger repositories under > > JBoss. And I strongly recommend you avoid Classloader-based > > repository selectors. You'd be better off using a JNDI-based > > repository selector. If you use Log4j 1.3, one is already available > > [1]. If not, you can grab the one from the sandbox [2]. Note that a > > Classloader-based version exists there, but you should ignore that > > and look at the ContextJNDISelector. Can you try this out and see if > > it works for you? > > > > [1] > > > http://logging.apache.org/log4j/docs/api-1.3/org/apache/log4j/selector/ContextJNDISelector.html > > [2] > > > http://svn.apache.org/viewvc/logging/sandbox/log4j/log4j_sandbox/tags/LOG4J_SANDBOX_ALPHA3/src/java/org/apache/log4j/selector/ > > > > Jake > > > > Hi Jake, > I upgraded to 1.3alpha8 and implemented the ContextJNDISelector as you > suggested > but I'm still having problems. To clarify, we're using Weblogic 8.1 SP4, not > JBoss - I only named the file JbossAppRepositorySelector because that was the > name of the file I got from their wiki. > > I think the challenge with the way we're implementing logging is that most of > our JAR files are loaded on Weblogic's classpath, and we need each web app to > be > able to write log entries for classes in those JARs to its own log file. > > The LogManager.repositorySelector is a static variable, which I think is only > loaded once by Weblogic since it's on the server's classpath > > Weblogic classpath: > myframework.jar (our custom code) > --Includes: > ----com.myframework.web.StartupListener (extends Spring's > ContextLoaderListener) > ----com.myframework.web.UserFormController (and other various classes) > ----com.myframework.service.XyzManager (business layer) > ----com.myframework.dao.XyzDao (data layer) > spring.jar > log4j.jar (now v1.3alpha8) > slf4j*.jar > jcl104-over-slf4j-1.3.0.jar > other JARs > > Each Web App (appA, appB, etc - we have dozens of WAR files): > Uses Spring to configure the classes from myframework.jar (which is NOT in > WEB-INF/lib) > Uses com.myframework.web.UserFormController and needs to write log entries to > its own file (appA.log, appB.log, etc) > Each WAR has its own "log4j_webapp.properties" in WEB-INF/classes > > web.xml: > <listener> > <listener-class> > com.myframework.web.StartupListener > </listener-class> > </listener> > ... > <env-entry> > <description>Logging Setup</description> > <env-entry-name>log4j/context-name</env-entry-name> > <env-entry-value>appA (or appB, appC, etc)</env-entry-value> > <env-entry-type>java.lang.String</env-entry-type> > </env-entry> > <env-entry> > <description>Logging Setup</description> > <env-entry-name>log4j/configuration-resource</env-entry-name> > <env-entry-value>log4j_webapp.properties</env-entry-value> > <env-entry-type>java.lang.String</env-entry-type> > </env-entry> > > When I start Weblogic with several WARs deployed, all the log entries for the > common classes from myframework.jar (which is most of them) only get written > to > the log file for the WAR that was loaded first alphabetically (appA.log > usually). appB.log, appC.log, etc get created but they're always empty. > > I guess an alternative to separate log files would be to somehow inject the > webapp's name into any logging message that is written to one common log file > - > I'm not sure how to do that given that most of the classes are in > myframework.jar and would have to somehow lookup the webapp that is currently > using it. > Thanks again for any suggestions or insight > > _______________________________________________ > user mailing list > [email protected] > http://www.slf4j.org/mailman/listinfo/user > _______________________________________________ user mailing list [email protected] http://www.slf4j.org/mailman/listinfo/user
