So for ServiceMix 4.0, we can switch so slf4j. The thing is that I don't really care since I came across the pax-logging project (http://wiki.ops4j.org/confluence/display/ops4j/Pax+Logging). This project provides an OSGi logging service that implements JCL, j.u.l and SLF4J. Everything is redirected to the same service using Log4J underneath ! So we don't have to really care about which one we use, as long as we are consistent in ServiceMix of course.
On 8/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Thanks Chris ! > It seems like the experts have answered... > So i guess we will switch to slf4j :-) > > Cheers, > Guillaume Nodet > > On 8/28/07, Chris Custine <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
