You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/10/05 09:17:28 UTC

Re: ServiceMix 4.0

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 <gn...@gmail.com> 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 <cc...@apache.org> 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 <gn...@gmail.com> 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/