> Absolutely. In light of commit r1380105, the next step is for you > (Maven folks) to formulate a policy for swapping out logging > back-ends.
Well that is what this is all about. And we have this solution available in Maven since 2004. There is already a logging facade which is widely used: org.codehaus.plexus.Logger This is used in whole Maven including all plugins which exist. All Maven messages get routed through it. I just see no reason for swapping out A1 for A2. At least not if A1 is working for years and all the Maven APIs are using it. I'm talking about >100 API signatures we would need to change in an incompatible way sooner or later! I'm perfectly fine to back the plexus.Logger facade with SLF4J as default impl, but please let's not get this into our API or export it to users! LieGrue, strub PS: there is a _huge_ difference whether you like to use a logging framework in a container or in an end-user application. In a container you just don't know what the user will throw into your container. And we did tried SLF4J for containers a few times and did hit those fundamental problems pretty early on. I'm pretty sure you know exactly what I mean. Others can grab the MyFaces, tomcat, OpenWebBeans, OpenJPA, ... lists for more info. Most time we either ended up doing our own logging facade or used JUL (yea it sucks big times, but at least it doesn't create classpath conflicts). ----- Original Message ----- > From: ceki <c...@qos.ch> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Monday, September 10, 2012 12:39 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 8:08:34 pm, Ralh Goers wrote: > >> First, I also would recommend moving from plexus logging to SLF4J. > > Cool. > >> Mark's concerns with incompatibilities only come about with the log4j >> bridge if you are trying to use APis that the SLF4J bridge hasn't >> implemented. Something being used in a plugin really shouldn't be >> using those. > > Exactly. > >> Although Ceki is generally careful not to break compatibility, it has >> happened. For example, you cannot mix applications that use SLF4J >> 1.6.x with code that uses SLF4J 1.5.x. Likewise, Logback is very much >> tied to the SLF4J version. See http://www.slf4j.org/news.html. If >> core is using SLF4J and an incompatible change is made again it >> probably won't be that big of a deal. Typically, when compatibility >> has been broken it really hasn't impacted code that uses the SLF4J >> API. > > SLF4J's user facing API, that is classes or interfaces located in the > org.slf4j package such as Logger, Marker, MDC and LoggerFactory have > been there and remain unchanged since day one (2005). Thus, a user > never has to worry about with which version of slf4j-api a dependency > was compiled with. A user can pick any version of slf4j-api-api.jar > and as long as the version of the binding of her choice matches, slf4j > will function correctly. See also [1,2]. > > The internal interfaces, those in the org.slf4j.spi or > org.slf4j.helpers packages, may change incompatibly. One of the most > notable occasions was in the 1.6.0 release when the > LocationAwareLogger interface was changed. It was done so in response > to a bug report [3] filed by... Ralph. The reader will appreciate the > irony. > > More objectively though, Ralph filed a valid bug report and the only > way to fix it was by making an incompatible change in an *internal* > interface. Unfortunately, given the ubiquity of SLF4J, such > incompatible changes somehow manage to leak into user-space and annoy > the hell out of many developers. SLF4J is designed so that the > problems occurring when deploying SLF4J are obvious with obvious > solutions -- SLF4J is stupid by design. (Feel free to quote.) > >> Mark mentioned shading as a way to "fix" any problems with SLF4J >> conflicts. I am not sure if shading will work with SLF4J. >> Implementations must provide a class named >> org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder >> and org.slf4j.impl.StaticMDCBinder. >> >> Jason made a comment in a previous reply that said "Ceki is also a >> committer, and will help us fix anything when necessary so that, >> again, we can focus on Maven and not logging." >> http://people.apache.org/committer-index.html doesn't list him as a >> committer on Maven and Ceki has said publicly and privately that he is >> unlikely to contribute to ASF projects. However, while the statement >> is incorrect I don't understand why what Ceki would or wouldn't do >> would have any bearing on whether Maven adopts SLF4J. > > If need be, I'll happily answer questions and guide you through the > process of migrating to SLF4J. However, I agree with Ralph, my person > should have no bearing to whether Maven adopts SLF4J or not. > >> Finally, I've been working on Log4j 2 for over 3 years now. The reason >> I started working on it was due to deficiencies in Logback that occur >> in large scale web applications and probably don't matter in something >> like Maven. But it would be nice to allow the end user the ability to >> swap out the logging implementation if they want. > > Absolutely. In light of commit r1380105, the next step is for you > (Maven folks) to formulate a policy for swapping out logging > back-ends. In my not so humble opinion, all other questions are moot > if you don't have a working policy for swapping-in/swapping-out > logging frameworks. Lacking the necessary knowledge about how Maven > bootstraps itself or how it manages its classloaders, I am not in a > position to formulate such policy. On the other hand, there is more > than enough expert knowledge here to address this problem. I intend to > follow your future discussions with interest. > > [1] http://www.slf4j.org/manual.html#compatibility > [2] http://www.slf4j.org/codes.html#version_mismatch > [3] http://bugzilla.slf4j.org/show_bug.cgi?id=127 > > -- Ceki > http://tinyurl.com/proLogback > > --------------------------------------------------------------------- > 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
