maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@tesla.io>
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/]
Date Sun, 09 Sep 2012 17:25:30 GMT

On Sep 9, 2012, at 12:57 PM, Mark Struberg wrote:

> +1
> 
> maybe we should first try to clarify what to use slf4j for.
> 
> slf4j has 2 'adaptors'
> 
> 1.) you can use the slf4j-api as logging facede to log to any logging backend you like.
Be it log4j, logback, etc. In that case you use the slf4j API in your project
> 
> 2.) you can use slf4j as 'bridge' to other logging frameworks. Your application e.g.
'talks' log4j, commons-logging or jul and slf4j provides an implementation for (most of, but
sadly not all) of the log4j, etc API and bridges it to slf4j. 
> 
> 
> Any others I missed?
> 
> 1.) is perfectly possible but we have a logging facade already in place: plexus.Logger.
This stuff exists since a long time and is used in all Maven APIs. It would be hard to replace
this with SLF4J and I personally see no technical reason to do so.
> 

I'm not suggesting we refactor any code. The modus operandi is the same as the change from
Plexus to Guice. No user visible changes and they can take advantage of the changes as they
see fit.

I have the Plexus logging mechanism delegating to SLF4J. Took me an afternoon and now the
Plexus Logger Manager delegates to the SLF4J ILoggerFactory. No client code needs to change
and it shouldn't have to. The Plexus interfaces can stay and be used forever. But if users
want to take advantage of a well documented, de facto standard they can.

> 2.) What happens if a plugin in your build already has a native log4j.jar, commons-logging.jar,
etc already in the classpath? In my experience it will cause weird class cast exceptions.
Which is not what we want. 
> 

I have not seen this when frameworks have used existing logging frameworks. Provided the appropriate
SLF4J JARs get in the classpath first. 

How are you going to avoid these integration issues using your own facade, writing your own
implementations and creating your own bridges and adapters. When the rubber meets the road
and you are truly trying to integrate the logging systems you're just going to blazing the
same trail SLF4J has already. Sure you can have a logging facade that actually doesn't integrate
with anything. Yes, integration is nasty but this is the work I simply do not want to do.
All we're doing right now is splitting text out on to the console, we don't actually integrate
with anything at all.

I'm sure Ceki would be happy to explain how it works if you're interested, I'm just a happy
user and I've had components with all the logging framework and I've not had issues.

> If someone explains me that/how 2. works without introducing possible compat issues,
then I'm +1 for SLF4j as well.
> 
> LieGrue,
> strub
> 
> 
> 
> ----- Original Message -----
>> From: Benson Margulies <bimargulies@gmail.com>
>> To: Maven Developers List <dev@maven.apache.org>
>> Cc: 
>> Sent: Sunday, September 9, 2012 6: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 Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg <struberg@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 <jason@tesla.io>
>>>> To: Maven Developers List <dev@maven.apache.org>; Mark Struberg 
>> <struberg@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Simplex sigillum veri. (Simplicity is the seal of truth.)






Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message