Re: [logging] history lessons revisited
robert burrell donkin [EMAIL PROTECTED] wrote on 01/30/2005 04:09:54 PM: On 28 Jan 2005, at 20:15, Richard Sitze wrote: [re-send.. I don't see this picked up... hmmm] Once, a long long time ago... someone wrote: The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( and it does ). - it creates an instance of the Logger adapter. This will be created using parent loader ( the one that loads commons-logging ). - the Logger instance makes references to Category or other classes that are used in it's implementation. End of story, since the class loader can't find the reference. This works fine for JAXP because the adapter for a parser is part of the parser jar. It doesn't work for c-l because the adapter is in the root loader ( with the API), not with the logging impl. That doesn't affect people who just use a single logger or can put the logger impl. in the same place with common-logging. It only affect containers like tomcat, when you want to let each webapp use it's own logger impl. of choice. I tried all kind of introspection games, it won't work. The only solution I see is to make sure the adapters are in the same place with the logger. Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. Alternatively, leave commons-logging.jar as it is and create a second commons-logging-api.jar. The -api will be included in the common loader. Each webapp will have to include commons-logging.jar ( or -impl ), and it's own logger. Or course, the best would be to have the adapter included in the logger impl. What do you think ? Craig, Remy can we make another c-l dot release with this change ? ( I'll do some more testing to see how it works ) i suspect that this solution may run into some issues with the way that JCL 1.0.x is factored into API and implementation. of course, i'd be glad for someone to prove me wrong ;) And now I ask... is it *ever* appropriate to use to the Thread Context Class Loader for our auto detect of impls? The correct class loader to use is *always* the classloader used to load the wrapper. No? yes: the test should always be performed with the classloader that used to load the wrapper. Ok, so this was my main focus/point on this topic. I know we use the context class loader for some situations [and it's appropriate to do so]. Beginning to recognize that we don't need to take a 'carte-blanc' toward this. Is this something you'd like to capture for the 1.0.5 release? It resolves point A in my summary of class loader issues. (i seem to recall a discussion about this on the commons logging list sometime in the last few months but i can't remember whether any subtle issues emerged...) it may be appropriate to use the thread context class loader if that's the one to be used to load the wrapper. i wonder whether it might make sense for logging implementations to be passed in the classloader which should be used to load whatever classes they required... - robert *** Richard A. Sitze IBM WebSphere WebServices Development
Re: [logging] history lessons revisited
On Tue, 2005-02-01 at 20:27, Richard Sitze wrote: robert burrell donkin [EMAIL PROTECTED] wrote on 01/30/2005 04:09:54 PM: On 28 Jan 2005, at 20:15, Richard Sitze wrote: [re-send.. I don't see this picked up... hmmm] Once, a long long time ago... someone wrote: The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( and it does ). - it creates an instance of the Logger adapter. This will be created using parent loader ( the one that loads commons-logging ). - the Logger instance makes references to Category or other classes that are used in it's implementation. End of story, since the class loader can't find the reference. This works fine for JAXP because the adapter for a parser is part of the parser jar. It doesn't work for c-l because the adapter is in the root loader ( with the API), not with the logging impl. That doesn't affect people who just use a single logger or can put the logger impl. in the same place with common-logging. It only affect containers like tomcat, when you want to let each webapp use it's own logger impl. of choice. I tried all kind of introspection games, it won't work. The only solution I see is to make sure the adapters are in the same place with the logger. Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. Alternatively, leave commons-logging.jar as it is and create a second commons-logging-api.jar. The -api will be included in the common loader. Each webapp will have to include commons-logging.jar ( or -impl ), and it's own logger. Or course, the best would be to have the adapter included in the logger impl. What do you think ? Craig, Remy can we make another c-l dot release with this change ? ( I'll do some more testing to see how it works ) i suspect that this solution may run into some issues with the way that JCL 1.0.x is factored into API and implementation. of course, i'd be glad for someone to prove me wrong ;) And now I ask... is it *ever* appropriate to use to the Thread Context Class Loader for our auto detect of impls? The correct class loader to use is *always* the classloader used to load the wrapper. No? yes: the test should always be performed with the classloader that used to load the wrapper. Ok, so this was my main focus/point on this topic. I know we use the context class loader for some situations [and it's appropriate to do so]. Beginning to recognize that we don't need to take a 'carte-blanc' toward this. Is this something you'd like to capture for the 1.0.5 release? It resolves point A in my summary of class loader issues. (my much loved cube blew up recently stalling my plans both for the 1.0.5 release and for comments one your discovery thread.) probably not for a couple of reasons: * 1.0.5 contains code that plugs memory leaks on many popular J2EE platforms. changes to the discovery are risky. * there are a few potential issues which i need to find time to think about more carefully. (i will prepare some responses to your classloading thread soon.) (thanks to brian) i hope to be able to take a release branch soon. any worthy changes to the discovery code can then to made on HEAD. i'd be happy to roll a 1.0.6 release if this seems appropriate. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] history lessons revisited
On 2005-01-28 20:15:13, Richard Sitze wrote: [re-send.. I don't see this picked up... hmmm] I intend to respond to your message in detail as soon as I get a chance. It's at the top of my to do list. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] history lessons revisited
On 28 Jan 2005, at 20:15, Richard Sitze wrote: [re-send.. I don't see this picked up... hmmm] Once, a long long time ago... someone wrote: The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( and it does ). - it creates an instance of the Logger adapter. This will be created using parent loader ( the one that loads commons-logging ). - the Logger instance makes references to Category or other classes that are used in it's implementation. End of story, since the class loader can't find the reference. This works fine for JAXP because the adapter for a parser is part of the parser jar. It doesn't work for c-l because the adapter is in the root loader ( with the API), not with the logging impl. That doesn't affect people who just use a single logger or can put the logger impl. in the same place with common-logging. It only affect containers like tomcat, when you want to let each webapp use it's own logger impl. of choice. I tried all kind of introspection games, it won't work. The only solution I see is to make sure the adapters are in the same place with the logger. Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. Alternatively, leave commons-logging.jar as it is and create a second commons-logging-api.jar. The -api will be included in the common loader. Each webapp will have to include commons-logging.jar ( or -impl ), and it's own logger. Or course, the best would be to have the adapter included in the logger impl. What do you think ? Craig, Remy can we make another c-l dot release with this change ? ( I'll do some more testing to see how it works ) i suspect that this solution may run into some issues with the way that JCL 1.0.x is factored into API and implementation. of course, i'd be glad for someone to prove me wrong ;) And now I ask... is it *ever* appropriate to use to the Thread Context Class Loader for our auto detect of impls? The correct class loader to use is *always* the classloader used to load the wrapper. No? yes: the test should always be performed with the classloader that used to load the wrapper. (i seem to recall a discussion about this on the commons logging list sometime in the last few months but i can't remember whether any subtle issues emerged...) it may be appropriate to use the thread context class loader if that's the one to be used to load the wrapper. i wonder whether it might make sense for logging implementations to be passed in the classloader which should be used to load whatever classes they required... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] history lessons revisited
Once, a long long time ago... someone wrote: The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( and it does ). - it creates an instance of the Logger adapter. This will be created using parent loader ( the one that loads commons-logging ). - the Logger instance makes references to Category or other classes that are used in it's implementation. End of story, since the class loader can't find the reference. This works fine for JAXP because the adapter for a parser is part of the parser jar. It doesn't work for c-l because the adapter is in the root loader ( with the API), not with the logging impl. That doesn't affect people who just use a single logger or can put the logger impl. in the same place with common-logging. It only affect containers like tomcat, when you want to let each webapp use it's own logger impl. of choice. I tried all kind of introspection games, it won't work. The only solution I see is to make sure the adapters are in the same place with the logger. Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. Alternatively, leave commons-logging.jar as it is and create a second commons-logging-api.jar. The -api will be included in the common loader. Each webapp will have to include commons-logging.jar ( or -impl ), and it's own logger. Or course, the best would be to have the adapter included in the logger impl. What do you think ? Craig, Remy can we make another c-l dot release with this change ? ( I'll do some more testing to see how it works ) And now I ask... is it *ever* appropriate to use to the Thread Context Class Loader for our auto detect of impls? The correct class loader to use is *always* the classloader used to load the wrapper. No? *** Richard A. Sitze IBM WebSphere WebServices Development
