Guillaume, No problem... I think you will be happy with this choice.
Also to clarify something important, I really encourage you to replace commons-logging-1.x.jar with jcl14-over-slf4j which implements the commons-logging interfaces and maps them to slf4j static binding. This will solve the problem with other projects like Spring that still use commons-logging and provide consistency for your projects. Cheers... Chris 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/ >
