You are correct about OSGi having more control over classloaders, but in the case of JCL things are a little different. Below is a link to the mailing list thread where we went through all of this pain on the Spring-OSGi project and decided to replace JCL with the slf4j facade in order to eliminate the side effects caused by Spring using JCL. I think Spring-OSGi uses slf4j natively now because of this and I believe it has been a consideration for Spring itself to move to it, but I am not sure of the final outcome of that discussion.
http://tinyurl.com/3axajc I think the thread was cross posted to Equinox as well and a discussion occured there... Just google "commons logging madness" :-) As you said about OSGi being flexible, one nice thing about using slf4j in OSGi is that you can have all implementation bundles (slf4j-log4j, slf4j-jdk14, etc.) available in the container, and it is up to each bundle to specify which one it imports, thereby adding it to the classloader wiring. I can't remember if that is built in functionality of slf4j or if it is something that I made work, but it is all done with manifest headers so it is easy to do if its not shipped like that. Good luck! Chris On 8/27/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > > I would say the opposite. The OSGi classloaders are much more > powerful and you can more easily control the visibility of classes. > In addition, if JCL is required by a given bundle A, it does not > mean that it will be visible by a bundle using bundle A. > > Obviously, this means to be tested (or maybe OSGi experts could > help there...) > > Cheers, > Guillaume Nodet > > On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote: > > > Also, moving toward an architecture based on OSGi almost guarantees > > that we will run into classloader issues with JCL. > > > > Bruce > >
