RE: Missing loggers from getCurrentLoggers() under WAS 5.x
If you want to find the ClassLoader of a class, just do .class.getClassLoader(). Just be careful when using PARENT_LAST in WAS 5.x, because you sometimes get strange behavior, e.g. in my particular case, I got javax.sql.DataSource loaded by a descendant classloader of the actual WebSphere implementation (from the Oracle driver jar), causing the cast of a JNDI lookup of this DataSource to throw an exception. You may have to tweak your classpath a little bit to get around issues like this. Brennan Spies Sr. Programmer Analyst Shared Application Services -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Friday, January 19, 2007 9:40 PM To: Log4J Users List Subject: RE: Missing loggers from getCurrentLoggers() under WAS 5.x At 05:03 PM 1/19/2007, you wrote: > >The PARENT_LAST setting did the trick, thanks! > I'm glad it worked, but I have to admit something. Child-First is just another way of saying Parent-Last and it's what I recommend you *not* use to avoid multiple separate instances of Log4j. Now I'm a bit confused as to why it worked? But the important thing is that you got it to work the way you want. Actually, I'm not that familiar with JMX. What classloader does an MBean belong to? The same one as the loads the libraries of the EAR? So, if you wanted to write an MBean that managed logging for the whole server, can that even be done? How would it see the loggers of other apps in classloaders it can't see? The only way I can see it is if Log4j is in the server's classpath and apps are using Parent-First, making sure that the Log4j instance in the server's classpath is the only one in use. But I digress Jake >--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
RE: Missing loggers from getCurrentLoggers() under WAS 5.x
At 05:03 PM 1/19/2007, you wrote: > >The PARENT_LAST setting did the trick, thanks! > I'm glad it worked, but I have to admit something. Child-First is just another way of saying Parent-Last and it's what I recommend you *not* use to avoid multiple separate instances of Log4j. Now I'm a bit confused as to why it worked? But the important thing is that you got it to work the way you want. Actually, I'm not that familiar with JMX. What classloader does an MBean belong to? The same one as the loads the libraries of the EAR? So, if you wanted to write an MBean that managed logging for the whole server, can that even be done? How would it see the loggers of other apps in classloaders it can't see? The only way I can see it is if Log4j is in the server's classpath and apps are using Parent-First, making sure that the Log4j instance in the server's classpath is the only one in use. But I digress Jake >--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
RE: Missing loggers from getCurrentLoggers() under WAS 5.x
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
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 strut
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] > ---
Re: Missing loggers from getCurrentLoggers() under WAS 5.x
The difference can probably be explained as a difference in LoggerRepositories. There is a servlet (LogWeb?) that allows config changes so it migh have some clues to help you. On 1/19/07, Ostermueller, Erik <[EMAIL PROTECTED]> wrote: 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] -- James Staufferhttp://www.geocities.com/stauffer_james/ Are you good? Take the test at http://www.livingwaters.com/good/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Missing loggers from getCurrentLoggers() under WAS 5.x
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]
