I'll try to whip something up this weekend. Sent from my iPhone
On 2013/07/19, at 7:38, Ralph Goers <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
