If a plugin creates a custom classloader inheriting from the tccl you can get issues with slf4j (because of their singleton) Le 9 sept. 2012 22:20, "Mark Struberg" <strub...@yahoo.de> a écrit :
> nope, no problem with just slf4j api and logback. > But that wont give us much benefit over just using plexus.Logger. > At least I do not see it yet > > It would make sense if plugins could add a logging bridge which is used by > 'their' framework. But otoh we have already kind of a bridge by grabbing > the stdout and redirecting that to the plexus logger. > > LieGrue, > strub > > > > > > > > ----- Original Message ----- > > From: Benson Margulies <bimargul...@gmail.com> > > To: Maven Developers List <dev@maven.apache.org>; Mark Struberg < > strub...@yahoo.de> > > Cc: > > Sent: Sunday, September 9, 2012 9:44 PM > > Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in > /maven/maven-3/trunk: ./ apache-maven/ > maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ > maven-embedder/src/main/java/org/apache/maven/cli/] > > > > On Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg <strub...@yahoo.de> wrote: > >> > >>> No client code changes unless the client wants to change it to take > > advantage of > >>> SLF4J. > >> > >> It's not the classes which change but the classpath does. It might then > > contain clashing classes. That is what I'm afraid of to be honest. > Because > > we do not have the 'other side' (random plugins and projects) under our > > own control. > > > > So, to be clear, we are not talking about the bridges *at all*. > > > > Thus, I claim that Mark's concern boils down to the following: Let's > > say that we add slf4j-api, slf4j-logback, and logback-whatever to the > > classpath. If I am following, you are worried that some plugin author > > somewhere is already using logback with a different version and might > > get an unpleasant surprise when the version we pick shows up. > > > > I find this scenario hard to credit. However, if it really worried us, > > we could shade the back end, and then the only possible means for > > trouble would be a plugin that wanted to use an incompatible version. > > > > If that's not what's worrying you, please humor me with a complete, > > concrete, example. If it is, can you cite an example of an existing > > plugin that would bust? > > > > > > > >> > >> > >> LieGrue, > >> strub > >> > >> > >> > >> ----- Original Message ----- > >>> From: Jason van Zyl <ja...@tesla.io> > >>> To: Maven Developers List <dev@maven.apache.org> > >>> Cc: > >>> Sent: Sunday, September 9, 2012 8:43 PM > >>> Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in > > /maven/maven-3/trunk: ./ apache-maven/ > > maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ > > maven-embedder/src/main/java/org/apache/maven/cli/] > >>> > >>> > >>> On Sep 9, 2012, at 2:24 PM, Benson Margulies wrote: > >>> > >>>> Again, let's deal with this one thing at a time: > >>>> > >>>> 1. Use slf4j-api as our primary facade/api for loggin in Maven. > > I'm in > >>>> favor, because it's much more common and popular than plexus. > >>>> > >>>> 2. Picking an slf4j-X to deliver logging to somewhere. I'm > > somewhat in > >>>> favor of java.util.logging for this, because of the baroque > > classpath > >>>> interactions of log4j initialization. But if others prefer log4j > > or > >>>> even something else, OK. > >>>> > >>> > >>> Yah, it's SLF4J so pick an implementation. > >>> > >>>> 3. Tossing one or more X-slf4j bridges into the default plugin > >>>> classpath. If Mark's concerns about surprises have any > > foundations in > >>>> technical reality, this is where they would turn up. I'm > > doubtful, but > >>>> on the other hand, what if we just didn't do this, and left it > > to > >>>> individual plugin authors to do this if, in fact, they wanted > > mapping > >>>> from some other logging API? > >>> > >>> I'm not suggesting this. I've routed the Mojo.getLog() through > > SLF4J so > >>> it just does what it does now except the backing implementation is the > > SLF4J > >>> implementation. If the user wants to use SLF4J and/or @Inject loggers > > than they > >>> have to specify the dependency. > >>> > >>> No client code changes unless the client wants to change it to take > > advantage of > >>> SLF4J. > >>> > >>>> > >>>> It would be good for some others to join this discussion. > >>>> > >>>> > >>>> > >>>> On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl > > <ja...@tesla.io> wrote: > >>>>> I think you're trying to preemptively solve for an issue > > that we > >>> may not have. I believe that if the right JARs are in the classpath > > first we > >>> will easily be able to tell running the integration tests for Maven > and > > the > >>> integration tests for all the plugins if there's going to be an > > issue. I > >>> believe the Ceki has probably run into every integration scenario > > imaginable > >>> over the last 10 years and he'll help us if required. > >>>>> > >>>>> I have runt into nasty problems where the classpath and > > classloaders > >>> cannot be controlled directly from the host system, but this is > > obviously within > >>> our purview to control. > >>>>> > >>>>> On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote: > >>>>> > >>>>>> > >>>>>>> Generally I use jul-to-slf4j and jcl-over-slf4j and > > then I > >>> don't care what > >>>>>>> components use what logging framework. > >>>>>> Yes, only that this sometimes causes really unfriendly > > classcast > >>> exceptions :/ > >>>>>> > >>>>>> How can we deal with those? Is there a retry possible? Imo > > not > >>> easily. > >>>>>> Could we scan the plugin classpath upfront? > >>>>>> Can a different class lookup strategy in our ClassRealms > > help? > >>>>>> Don't we care at all and people must exclude log4j et > > all > >>> manually if they like to use a new maven version? > >>>>>> > >>>>>> > >>>>>> LieGrue > >>>>>> strub > >>>>>> > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: Jason van Zyl <ja...@tesla.io> > >>>>>>> To: Maven Developers List <dev@maven.apache.org> > >>>>>>> Cc: > >>>>>>> Sent: Sunday, September 9, 2012 7:08 PM > >>>>>>> Subject: Re: SLF4J implementation [was Re: svn commit: > > r1380105 > >>> - in /maven/maven-3/trunk: ./ apache-maven/ > >>> maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ > >>> maven-embedder/src/main/java/org/apache/maven/cli/] > >>>>>>> > >>>>>>> Boils down to 1) pick a logging facade and 2) pick a > > default > >>> implementation. > >>>>>>> > >>>>>>> SLF4J is really the de facto standard, used everywhere > >>> including 15 projects > >>>>>>> here at Apache. > >>>>>>> > >>>>>>> It's unlikely to be surprising to anyone with the > > changes > >>> I've made as > >>>>>>> it will appear just like it does now. A bunch of log > > statement > >>> to the console. > >>>>>>> It's unlikely any plugin author is going to care > > about > >>> changing the > >>>>>>> implementation as its running inside Maven. > > Integrators may > >>> want to change the > >>>>>>> implementation to control how components and plugins > > log but > >>> the authors of > >>>>>>> plugins should not have to care. > >>>>>>> > >>>>>>> SLF4J accompanying utilities also help to sequester > > log output > >>> from commons > >>>>>>> logging and JUL into the same funnel. So even if > > plugin authors > >>> are pulling in > >>>>>>> component we could add the adapters and bridges to > > make this > >>> all work nicely. So > >>>>>>> even if something is using commons-logging or JUL > > under the > >>> covers it will all > >>>>>>> come out, ultimately, through SLF4J. > >>>>>>> > >>>>>>> Generally I use jul-to-slf4j and jcl-over-slf4j and > > then I > >>> don't care what > >>>>>>> components use what logging framework. > >>>>>>> > >>>>>>> On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote: > >>>>>>> > >>>>>>>> On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg > >>> <strub...@yahoo.de> > >>>>>>> wrote: > >>>>>>>>> sorry, didn't catch this reply earlier. > >>>>>>>>> > >>>>>>>>> I see, but then we are back to my original > > problem. > >>> Once you add e.g. > >>>>>>> log4j-slf4j binding then you will get nasty class cast > >>> exceptions because they > >>>>>>> are not fully binary compatible. If there is a > > log4j.jar in the > >>> classpath of the > >>>>>>> plugin already then it might even crash with a weird > > Exception. > >>>>>>>> > >>>>>>>> Folks, I'm sorry, but I'm not following > > this > >>> argument. I apologize > >>>>>>> for > >>>>>>>> being slow, but I really wish that someone would > > sort this > >>> into a > >>>>>>>> small number of questions and explain the pros and > > cons of > >>> them. > >>>>>>>> > >>>>>>>> I'm fine with declaring SLF4J to be the > > primary logging > >>> API inside > >>>>>>>> Maven, and leaving it to individual plugin authors > > to toss > >>> in X-slf4j > >>>>>>>> if they want to. I can see why putting X-slf4j > > into the > >>> plugin > >>>>>>>> classpath by default could have surprising and > > unpleasant > >>> results, but > >>>>>>>> there might be a persuasive reason to do it > > anyway. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I've seen such problems in the wild. > >>>>>>>>> This is nothing which slf4j does wrong - > > it's just > >>> not really > >>>>>>> possible to do it 100% right. > >>>>>>>>> > >>>>>>>>> We imo only have the option to choose between > > different > >>> kinds of > >>>>>>> 'broken'. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> LieGrue, > >>>>>>>>> strub > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ----- Original Message ----- > >>>>>>>>>> From: Jason van Zyl <ja...@tesla.io> > >>>>>>>>>> To: Maven Developers List > >>> <dev@maven.apache.org>; Mark > >>>>>>> Struberg <strub...@yahoo.de> > >>>>>>>>>> Cc: > >>>>>>>>>> Sent: Sunday, September 9, 2012 4:22 PM > >>>>>>>>>> Subject: Re: SLF4J implementation [was Re: > > svn > >>> commit: r1380105 - > >>>>>>> in /maven/maven-3/trunk: ./ apache-maven/ > >>>>>>> maven-core/src/main/java/org/apache/maven/classrealm/ > >>> maven-embedder/ > >>>>>>> maven-embedder/src/main/java/org/apache/maven/cli/] > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Sep 9, 2012, at 4:17 AM, Mark Struberg > > wrote: > >>>>>>>>>> > >>>>>>>>>>> Can you again please explain me what > > the > >>> benefit of the SLF4J > >>>>>>> abstraction > >>>>>>>>>> over the already used plexus.Logger is? > > Both are > >>> just logging > >>>>>>> facades. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> But really I think the biggest benefit is > > that, as > >>> far as I know, > >>>>>>> SLF4J > >>>>>>>>>> integrates with every known logging > > framework right > >>> now. In that it > >>>>>>> can coerce > >>>>>>>>>> JUL, and CL logging into a unified > > framework which > >>> I don't > >>>>>>> believe any of > >>>>>>>>>> the other frameworks do, or do as well. > > Maven is > >>> about integration > >>>>>>> and for > >>>>>>>>>> logging I believe it's the best > > solution that > >>> exists for the > >>>>>>> least effort. > >>>>>>>>>> > >>>>>>>>>> I think it's been adopted at Apache by > > so many > >>> projects > >>>>>>> specifically for > >>>>>>>>>> those reasons. Ceki is also a committer, > > and will > >>> help us fix > >>>>>>> anything when > >>>>>>>>>> necessary so that, again, we can focus on > > Maven and > >>> not logging. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> Jason > >>>>>>>>>> > >>>>>>>>>> > >>> ---------------------------------------------------------- > >>>>>>>>>> Jason van Zyl > >>>>>>>>>> Founder & CTO, Sonatype > >>>>>>>>>> Founder, Apache Maven > >>>>>>>>>> http://twitter.com/jvanzyl > >>>>>>>>>> > >>> --------------------------------------------------------- > >>>>>>>>>> > >>>>>>>>>> Selfish deeds are the shortest path to > > self > >>> destruction. > >>>>>>>>>> > >>>>>>>>>> -- The Seven Samuari, Akira Kurosawa > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>> --------------------------------------------------------------------- > >>>>>>>>> To unsubscribe, e-mail: > >>> dev-unsubscr...@maven.apache.org > >>>>>>>>> For additional commands, e-mail: > >>> dev-h...@maven.apache.org > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>> --------------------------------------------------------------------- > >>>>>>>> To unsubscribe, e-mail: > > dev-unsubscr...@maven.apache.org > >>>>>>>> For additional commands, e-mail: > > dev-h...@maven.apache.org > >>>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Jason > >>>>>>> > >>>>>>> > > ---------------------------------------------------------- > >>>>>>> Jason van Zyl > >>>>>>> Founder & CTO, Sonatype > >>>>>>> Founder, Apache Maven > >>>>>>> http://twitter.com/jvanzyl > >>>>>>> > > --------------------------------------------------------- > >>>>>>> > >>>>>>> believe nothing, no matter where you read it, > >>>>>>> or who has said it, > >>>>>>> not even if i have said it, > >>>>>>> unless it agrees with your own reason > >>>>>>> and your own common sense. > >>>>>>> > >>>>>>> -- Buddha > >>>>>>> > >>>>>> > >>>>>> > >>> --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Jason > >>>>> > >>>>> ---------------------------------------------------------- > >>>>> Jason van Zyl > >>>>> Founder & CTO, Sonatype > >>>>> Founder, Apache Maven > >>>>> http://twitter.com/jvanzyl > >>>>> --------------------------------------------------------- > >>>>> > >>>>> A man enjoys his work when he understands the whole and when > > he > >>>>> is responsible for the quality of the whole > >>>>> > >>>>> -- Christopher Alexander, A Pattern Language > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > > --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>> > >>> Thanks, > >>> > >>> Jason > >>> > >>> ---------------------------------------------------------- > >>> Jason van Zyl > >>> Founder & CTO, Sonatype > >>> Founder, Apache Maven > >>> http://twitter.com/jvanzyl > >>> --------------------------------------------------------- > >>> > >>> I never make the mistake of arguing with people for whose opinions I > > have no > >>> respect. > >>> > >>> -- Edward Gibbon > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
