That isn't completely true either. You could bridge JCL, JUL and Log4j 1.x to SLF4J using the SLF4J components and then route SLF4J to Log4j 2. That said, I probably wouldn't do it that way.
The point is, I think the real problem is on the web site, not the name of the jars. If one of us can create the documentation for this I believe the problem will solve itself. Ralph On Jul 18, 2013, at 3:18 PM, Nick Williams wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
