I really think you need to put a wiki page with all your (I am going to say this but for a specific reason) “imagined” problems. That way we can knock down the ones that are imagined and leave them dead and focus instead on the real ones.
For example the case below is solved with the "is there a /org/slf4j/impl/StaticLoggerBinder.class entry on the classpath". Now I agree that the check is not implemented *yet* but what we really need to do is identify all the issues and then design the solution that fixes all of them in one simple go. So yes it is a valid issue, but not one we need to keep dragging back up as we have already addressed the issue and the solution for that issue. Please Mark, create a wiki so we can track the valid issues you have and the solutions as we find them before you vere into appearing like a refusenik ranter. You are identifying valid issues, but I feel email is ill suited to getting those issues identified and resolved. -Stephen On 11 October 2012 10:18, Mark Struberg <strub...@yahoo.de> wrote: > 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 > >
