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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
