The PARENT_LAST setting did the trick, thanks! --Erik -----Original Message----- From: Ostermueller, Erik Sent: Friday, January 19, 2007 2:37 PM To: 'Log4J Users List' Subject: RE: Missing loggers from getCurrentLoggers() under WAS 5.x
Jake, thanks for your lengthy reply. >> One way to solve the multiple classloader issue is to make sure >> child-first classloading is disabled for any individual app The pdf I referenced suggested the PARENT_LAST setting -- PARENT_FIRST is the default. Looking back at my settings, for some reason when I set it to PARENT_LAST, it didn't 'take'. I'll try that again today. >>(or, at least, make sure log4j.jar is not deployed in WEB-INF/lib) Since both our war and mdb use log4j, we keep log4j.jar in the ear. >> and put a copy of log4j.jar in the server's classpath so that all apps see it. >> Now you have a single default logger repository to query and JMX should find all the loggers. If the PARENT_LAST thing doesn't work, I'll try this. Thanks again, --Erik -----Original Message----- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Friday, January 19, 2007 11:07 AM To: Log4J Users List Subject: Re: Missing loggers from getCurrentLoggers() under WAS 5.x Does Jonas use something similar to the JBoss Unified Classloader? I don't fully understand the Unified Classloader, but from what I've gathered, it seems as if libraries, no matter where they are loaded from, are all part of one uber-classloader. If this is true, and Jonas uses something like this, then only one Log4j library would be loaded across the entire server. Even if individual app deploy Log4j in their WEB-INF/lib, each would continue to use the Log4j library first loaded by the Unified Classloader. Because there is only one instance of Log4j to use, there is only one LoggerRepository (unless someone has installed a custom repository selector). So, it would be a one-stop-shop for JMX under Jonas (or JBoss). Again, this is all premised on my presumption of Jonas using a Unified Classloader and my further presumption of the behavior of a Unified Classloader. Now, if all the above holds true and Websphere uses multiple classloaders, it may have multiple instances of the Log4j library being used by different applications. Even if no repository selector was set, there would be separate logger repositories; each being the default logger repository of each instance of Log4j in distinct classloaders that can't see each other. One way to solve the multiple classloader issue is to make sure child-first classloading is disabled for any individual app (or, at least, make sure log4j.jar is not deployed in WEB-INF/lib) and put a copy of log4j.jar in the server's classpath so that all apps see it. Now you have a single default logger repository to query and JMX should find all the loggers. Of course the problem with the latter solution is that all apps have to use the same logger repository and, thus, the same configuration. This can be remedied by using a custom repository selector based on something like JNDI or classloaders (be *****very******* careful about using the latter. It can result in all sorts of classloading issues). Of course then your JMX tool will need to know how to get a handle to all logger repositories managed by the custom repository selector in order to centrally configure loggers for all apps instead of just libraries using the default logger repository. Anyway, just throwing that out there for contemplation. I've used neither Websphere nor Jonas (though I would like to try out the latter sometime), so take all I've said with a grain of salt. Jake For the JMX stuff to work, wouldn't Log4j have to be in the server's Quoting "Ostermueller, Erik" <[EMAIL PROTECTED]>: > > > Hello, > > I'm writing some code that will turn log4j(1.2.8) logging on and off > at runtime. I'll probably expose this via jmx. > I've seen solutions out there to re-read a configuration file and this > is not what I want to do. > > Instead, I want the code to discover all the loggers in use by my EAR > (deployed under WAS 5.x ) and enable the JMX user to: > > -view the list of all loggers > -set the logging levels on any one of the loggers. > > Under jonas, this works like a dream. > Invoking myLogger.getLoggerRepository().getCurrentLoggers() unleashes > a gusher of loggers of every variety. > hibernate, struts, betwixt, etc... > I can pick over the results and invoke setLevel() on the ones I care > about. > Logging levels are jumping up and down and the world is a happy place. > Enter WebSphere Application Server 5.x [thunder, lightning, dark > clouds]. > > With WAS, the getCurrentLoggers() returns just a small subset of all > the loggers in use. > The ones I mentioned above, for instance, are ones that show up in > jonas but not websphere. > The ones in my own package space are there in both jonas and websphere. > So why did some disappear and not others? Where did they all go? -- > we use struts and the others equally in both jonas and was. > > Using the following WAS add-on (a classloader viewer), I'm probably > going to find my missing loggers. > > http://ecommunity.groupintelligence.com/websphere/forums/showthread.php? > p=2353#post2353 > > My question is, what should I do next if I do find them? > I suppose I'll try to find an api to traverse the classloaders, but > that sounds plain nasty. > Surely someone has done this before..... > > I've posted this question on a WebSphere forum and I didn't get as > much as a peep out of them. > http://ecommunity.groupintelligence.com/websphere/forums/showthread.php? > p=2353#post2353 > > The people who wrote the following doc seem to know what they're > talking > about: > http://mattfleming.com/files/active/0/ibm.pdf > > I tried their "JCL option 3 + EAR" and unfortunately, the hibernate > and other loggers were still missing. > > If anyone thinks it will help, I could post the lists of loggers that > did/didn't show up. > > Thanks all, > > > --Erik Ostermueller > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
