Oh I missed one more constellation a plugin could have slf4j-1.5.x + a logging backend we do not know of.
I hope such things dont often exist, but in theory it could happen. For all of those cases we need isolation. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <strub...@yahoo.de> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Thursday, October 11, 2012 10:52 AM > Subject: Re: SLF4J integration > > A the end of the day we could have both actually! > > Most plugins will add both as dependency. Otherwise they would not be able to > log via slf4j. > > But there are also libraries like OpenJPA (via openjpa-maven-plugin) which do > auto detection. They look up what impls are available and decide what to use. > In > OpenJPA you can even force the one you like to use via a property in > persistence.xml. So in the real world it's even more complicated. > > I'm not sure how to translate "Das Leben ist kein > Kindergeburtstag" - literally it would be "live is no children > birthday" ;) > > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Anders Hammar <and...@hammar.net> >> To: Maven Developers List <dev@maven.apache.org> >> Cc: >> Sent: Thursday, October 11, 2012 10:24 AM >> Subject: Re: SLF4J integration >> >> Just to get this clear in my head: >> When you're talking about "slf4j dependency" in a plugin, are > you >> talking about dependency to slf4j-api or an slf4j impl? >> >> /Anders >> >> On Thu, Oct 11, 2012 at 10:16 AM, ceki <c...@qos.ch> wrote: >>> On 11.10.2012 08:37, Mark Struberg wrote: >>> >>> Hi Mark, >>> >>>> Hi Ceki, thanks for the reply! >>> >>> >>>>> The method signatures of classes in the org.slf4j package such > as? >>>>> Logger, LoggerFactory, Marker, MDC, etc. are the same since > 2005.? >>>> >>>> No they are not. I did a diff between 1.2 and the latest and it >>>> seems a few trace() methods got added. This is only a minor > problem >>>> but still. This change is perfectly backward compatible, but > it's >> not >>>> forward compatible. If there is any new signature added/changed in > a >>>> newer version which we will not yet use, then we would just crash > if a >>>> plugin uses the newer version. Now this is highly unlikely. But >> I've >>>> seen this with commons logging and I've seen this with the >>>> LocationAwareLoger as you already mentioned below. This is btw > exactly >>>> the reason why we shade in all commons-* stuff to private > packages... >>> >>> Correct. The trace method was added in SLF4J version 1.4 released on >>> May 16th 2007. Interestingly enough, I can't remember a single >>> complaint about missing trace method. About 1% of slf4j-users use >>> versions earlier than 1.4. Among that 1%, even fewer have a dependency >>> requiring the trace method. As an end result, and as far as I can >>> tell, no one complains about the missing trace method in earlier slf4j >>> versions. >>> >>> My point is that there are some imaginary problems that never occur in >>> practice. In practice, the slf4j version some software is compiled >>> with is never a problem assuming it only imports from the org.slf4j >>> package. >>> >>>>> this means that the minor version of the SLF4J binding >>>>> must match that of the slf4j-api. The "maintenance" >>>>> number is unimportant. >>>> >>> >>>> That's perfectly fine that way! Please understand that this is >>>> nothing against slf4j! I just like to avoid that we introduce > build >>>> problems to existing projects. As highlighted in my previous post >>>> there ARE ways to do that (by shielding via ClassWorlds), but this > is >>>> not in place in trunk yet. Also there are zero integration tests > for >>>> it atm! >>> >>> OK. >>> >>>> Maven uses a child-first classloading strategy (with exceptions) - > a >>>> plugin would only see exactly 1 version. Currently (again: there > is >>>> atm no shielding in place yet) if a plugin would would provide > it's >>>> own slf4j-api-1.4.2 then the plugin would get this version of the >>>> Class. And if the plugin would invoke >>>> LoggerFactory.getLogger(this.class()) then what would happen? Most >>>> probably a classcast exception, right? There is a minor chance > that we >>>> do not blow up as there is a complex ClassLoading environment in >>>> place. But we only know after we have some IT in place which do > not >>>> exist yet. All the change got committed without a single IT, thus > my >>>> -1 in the first place. >>> >>> >>> While I agree with the gist of your argument, I still maintain that >>> "slf4j versions" is not the crux of the matter here. > However, as >> you >>> point out, class isolation should be implemented and tested. >>> >>>> >>>>>> 2.) if you use slf4j, then ALL the funnels and logging > backends >> must >>>>>> have the very same version number than the slf4j-api. > Otherwise >> you >>>>>> are pretty much doomed. Ceki, is this correct as well? >>>>> >>>>> >>>>> I would not go as far as "doomed". For example, the >> following >>>>> combination will work fine: slf4j-api-1.7.2.jar, >>>>> sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar, >>>>> jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other >> words, >>>>> you can freely mix artifacts in the 1.6.x and 1.7.x families. >>> >>> >>>> But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No >>>> you cannot as far as I've seen. So we cannot make a general >> assumption >>>> on that! The only safe rule is to not mix slf4j parts with > diverging >>>> major or minor number. Is this correct? >>> >>> Yes, that is correct. >>> >>> >>>> >>>>> Sounds good. I would recommend isolation regardless of the > version >> of >>>>> the discovered slf4j dependency. The plugin author probably > wishes >>>>> logging isolation. Maven should let the plugin have its own >> separate >>>>> logging environment distinct from Maven's own logging. >>> >>> >>>> But that would actually be a big step backwards imo. >>> >>> No, separating maven logging and plugin logging (for the plugins that >>> explicitly set their own slf4j logging environment) is not a step >>> backwards. On the contrary, it preserves existing behavior. >>> >>> In my earlier message, I apparently did not insist enough on the the >>> point that isolation was only required for the minority of plugins >>> which set up their own slf4j-based logging environment. The vast >>> majority of plugins which do not declare an slf4j dependency, would >>> get their slf4j loggers either via injection or via getLogger(). >>> >>>> Currently any plugin is forced to 'funnel' the output into > the >>>> logger it obtains via getLogger() itself. This is an instance of >>>> org.apache.maven.plugin.logging.Log and we have it perfectly under > our >>>> own control. It's not a perfectly convenient logging api but > it >> works >>>> and shields us from all implementation details! >>> >>> This has been discussed earlier so I won't respond. >>> >>>> If we would isolate away all the logging of a plugin (because it >>>> contains a diverging slf4j version) then we would loose all this > logs, >>>> right? >>> >>> Of course not. The logs would be available in the logging environment >>> proper to the plugin (declaring its own logging environment), > that's >>> the beauty of this approach. >>> >>>> It is perfectly valid for any plugin to use slf4j right now. >>> >>> >>> Absolutely. >>> >>>> All it needs to do is to funnel it into our own maven logging >>>> api. We could e.g. provide a slf4j-maven-logging backend so users >>>> could use it even more easily. >>> >>> >>> I think that's an understandable mistake but a mistake > nonetheless. We >>> don't want to funnel plugin logging (for a plugin declaring its > own >>> slf4j dependencies) into Maven logging. For one, that's not the >>> *current* behavior as Maven logging and plugin logging (depending on >>> slf4j) are obviously independent. For two, attempts at such > integration >>> quickly become insurmountably complex. Logging integration between >>> Maven and a pluging declaring its own slf4j dependencies is not needed >>> and certainly not worth the effort. >>> >>> If unconvinced, I suggest we study concrete examples. >>> >>> -- >>> Ceki >>> 65% of statistics are made up on the spot >>> >>> --------------------------------------------------------------------- >>> 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 >> > > --------------------------------------------------------------------- > 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
