On Jul 18, 2013, at 5:11 PM, Remko Popma wrote:

> I wasn't thinking of this from the point of view of the user; they will have 
> an app that is coded using one of these logging apis, not all three.

Definitely not true! I have both SLF4J and JCL bridges in my applications. My 
application itself uses the Log4j 2 API, but Spring uses Commons so I need the 
JCL bridge, and other libraries I consume use SLF4J so I need the SLF4J bridge.

If I were retrofitting an old application that had the same libraries but used 
the Log4j 1.2 API, I would need all three of these JARs.

Nick

> 
> 
> From: Ralph Goers <[email protected]>
> To: Log4J Developers List <[email protected]> 
> Sent: Friday, July 19, 2013 4:06 AM
> Subject: Re: Bridge to other logging APIs
> 
> First,  these all started out being called adapters and even had their own 
> Maven groupId. We changed that a few releases ago.  Second, although I have 
> no problem using the terminology on the web site I just hate having jar names 
> that long.  I don't think it provides any value to them.  And I am tired of 
> renaming things for the sake of renaming things.
> 
> Ralph
> 
> On Jul 18, 2013, at 11:40 AM, Nick Williams wrote:
> 
> > So, again we are at an impasse it would seem. Paul, Gary, Nick, Remko all 
> > want to rename these, Ralph opposes.
> > 
> > I /kind of/ see where Ralph's coming from here:
> > 
> > - log4j-slf4j-impl, called "SLF4J Binding," is an actual SLF4J 
> > implementation. The SLF4J team calls them "bindings." This, the name "SLF4J 
> > Binding" does make some sense. However, I would thus submit that the 
> > artifact name log4j-slf4j-binding makes more sense that log4j-slf4j-impl. 
> > However, I still think "Bridge" makes sense here. It's a bridge between the 
> > SLF4J API and the Log4j implementation. Think about it this way: 
> > log4j-slf4j-impl isn't actually an implementation/binding of SLF4J because 
> > it doesn't actually write anything; it's a bridge between the SLF4J API and 
> > the Log4j implementation and takes the place of an SLF4J implementation.
> > 
> > - log4j-jcl, already called a bridge, Ralph agrees is a bridge. I fail to 
> > see a real difference between bridging the Commons API to Log4j and 
> > bridging the SLF4J API to Log4j. If the Commons Logging team decided to 
> > create an implementation, this bridge component wouldn't actually change. 
> > Thus, I submit, it would still be a bridge. Either way, Ralph agrees it's a 
> > bridge but opposes renaming the artifact as such.
> > 
> > - Ralph's argument for log4j-1.2-api makes the most sense to me. Unlike the 
> > other two components, which require the SLF4J API JAR and Commons Logging 
> > API JAR, respectively, log4j-1.2-api /replaces/ the Log4j 1.2 JAR. Users DO 
> > NOT and SHOULD NOT include the Log4j 1.2 artifacts on their class path when 
> > using this component. Thus, this really is the Log4j 1.2 API and not a 
> > bridge between that and Log4j 2.
> > 
> > So then, admittedly later than I should have, I looked up the Bridge 
> > Pattern and the Adapter Pattern. (The Wikipedia articles on these are 
> > useful.) Gamm, Helm, Johnson and Vlissides's  "Design Patterns" (1995, 
> > Addison-Wesley) says the Bridge Pattern is meant to "decouple an 
> > abstraction from its implementation so that the two can vary 
> > independently." Well, that's not exactly what's going on in all of these 
> > cases. In fact, that really just describes the relationship between the 
> > Log4j 2 API and the Log4j 2 Core. The Adapter Pattern, on the other hand, 
> > translates one interface for a class into a compatible interface (Freeman, 
> > Frooman, Kathy, and Bates. "Head First Design Patterns." O'Reilly. 2013.). 
> > That's not exactly what's going on in all of these cases, either.
> > 
> > Based on all this info, if I had to describe these three components to 
> > someone I would do it thusly:
> > 
> > - SLF4J API Bridge
> > - Commons Logging API Bridge
> > - Log4j 1.2 API Adapter
> > 
> > Based on the "official" definition of these patterns, I think these terms 
> > are accurate. I also think that using the same term for the Log4j 1.2 
> > component could be a problem, because it may lead users to think they need 
> > the old Log4j JARs just like they need the SLF4J and Commons Logging JARs. 
> > However, I DO think that using a different term for the SLF4J and JCL 
> > components could be just as confusing for users. Therefore, I propose:
> > 
> > - "log4j-1.2-api" becomes "log4j-1.2-api-adapter" and is named "Log4j 1.2 
> > API Adapter" (leaving API in named to stress that it replaced Log4j 1 JAR)
> > - "log4j-jcl" becomes "log4j-jcl-bridge" and is named "Commons Logging API 
> > Bridge"
> > - "log4j-slf4j-impl" becomes "log4j-slf4j-bridge" and is named "SLF4J API 
> > Bridge"
> > 
> > That's my $0.02. We're still left with Ralph's opposition, and I'll leave 
> > it up to the big wigs to decide this one.
> > 
> > Nick
> > 
> > 
> > On Jul 18, 2013, at 12:13 AM, Ralph Goers wrote:
> > 
> >> Also, "binding" is the term SLF4J uses for implementations of its API, so 
> >> that should make sense to SLF4J users looking for implementations.  Log4j 
> >> 1.2 is an implementation of that API - the "real" log4j 1.x jars should 
> >> not be used.  The JCL bridge is exactly that, a bridge between the Commons 
> >> Logging jar and Log4j 2 (the commons logging jar is required).
> > 
> > On Jul 18, 2013, at 12:07 AM, Ralph Goers wrote:
> > 
> >> We have already renamed these at least twice.  Just leave them be.
> >> 
> >> Sent from my iPad
> > 
> > On Jul 17, 2013, at 10:16 PM, Paul Benedict wrote:
> > 
> >> So much better. 
> >> 
> >> 
> >> On Wed, Jul 17, 2013 at 10:12 PM, Gary Gregory <[email protected]> 
> >> wrote:
> >> 
> >> On Jul 17, 2013, at 22:40, Nick Williams <[email protected]> 
> >> wrote:
> >> 
> >>> Yea I think we all go that. Important part is:
> >>> 
> >>> - "log4j-1.2-api" becomes "log4j-1.2-bridge" and is named "Log4j 1.2 
> >>> Bridge"
> >>> - "log4j-jcl" becomes "log4j-jcl-bridge" and is named "Commons Logging 
> >>> Bridge"
> >>> - "log4j-slf4j-impl" becomes "log4j-slf4j-bridge" and is named "SLF4J 
> >>> Bridge"
> >>> 
> >>> Consistency is a good thing, and it helps users out by not confusing them.
> >> 
> >> Yes! Preach on brother :) +1
> >> 
> >> Gary
> >>> 
> >>> Nick
> >>> 
> >>> On Jul 17, 2013, at 9:35 PM, Remko Popma wrote:
> >>> 
> >>>> Small correction: I'd like to rename the log4j-1.2-api jar to 
> >>>> log4j-1.2-bridge-2.0.jar (without api in the name).
> >>>> 
> >>>> 
> >>>> Sent from my iPhone
> >>>> 
> >>>> On 2013/07/18, at 11:07, Remko Popma <[email protected]> wrote:
> >>>> 
> >>>>> Currently we have three different names for things that provide a 
> >>>>> bridge/adapter from other logging APIs to the Log4j2 implementation:
> >>>>> (Commons Logging) Bridge, (Log4j 1.2) API, and (SLF4J) Binding.
> >>>>> 
> >>>>> Would it be a good idea to call them all "Bridge"?
> >>>>> 
> >>>>> On the web site, components would then become:
> >>>>> Commons Logging Bridge, Log4j 1.2 Bridge, and SLF4J Bridge.
> >>>>> 
> >>>>> The jar files would become:
> >>>>> log4j-jcl-bridge-2.0.jar
> >>>>> log4j-1.2-api-bridge-2.0.jar
> >>>>> log4j-slf4j-bridge-2.0.jar
> >>>>> 
> >>>>> I would especially like to rename log4j-1.2-api-2.0.jar so we only have 
> >>>>> one jar with "api" in the name.
> >>>>> 
> >>>>> Thoughts?
> >>> 
> >> 
> >> 
> >> 
> >> -- 
> >> Cheers,
> >> Paul
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to