Hi!
Here are a few basic observations about slf4j.
slf4j really rocks for end user applications, but when it comes to deep
container core stuff you must take care about classloader clashes much more
than within an end-user project. We just don't know what a user defined in his
<plugin> sections…
If we like to use slf4j as maven logging api and export it in the core
classloader then we might probably face the following problematic spots
1.) slf4j-api <=1.5 and >=1.6 are not fully binary compatible afaik. Ceki, is
this correct? Afair there have been a few minor changes between those versions.
They do not always cause problems but I've seen those in the wild already.
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?
3.) if we would provide a sfl4j funnel (e.g. log4j-over-slf4j) and a plugin
brings his own log4j.jar then we will have class path clashes as well.
I'm happy if someone tells me the above observations are wrong and I just
failed to setup the stuff properly. If not, then we still can use slf4j for
maven BUT we need to isolate it really well via classworlds. And of course that
would mean that we miss maven logging for those 'isolated' plugins, right?
I'll first sum up the problems which will occur if the upper assumptions are
correct.
ad 1.) maven provides slf4j-api-1.6 but a plugin uses slf4j-api-1.5, 1.4, etc
This might cause class cast exceptions ("Cannot cast class Logger to class
Logger") by having different versions of the slf4j-api classes in different
ClassLoaders
ad 2.) we provide slf4j-simple-1.6 and user provides slf4j-xxx-1.4. This will
most probably end up in a big *boom*. And we do not know all slf4j-** as any
user might easily add his own backend.
ad 3.) We will face class path clashes since a few slf4j funnels are not fully
binary compatible with the original impls. So funneling is hard to do in maven.
If others think it is possible, then please point out a way to do this
properly, thanks!
Now for the workaround we could implement:
While discussing this topic with Stephen he had the idea to scan whether a
plugin uses slf4j by unzipping all plugin dependencies and do some checks. E.g.
check whether there is a org.slf4j.impl.StaticLoggerBinder.class
If we detect this or any slf4j with a version != the version used in
maven-core, then we must isolate away slf4j provided by the maven core via
ClassWorlds.
I'm happy about any feedback!
LieGrue,
strub
----- Original Message -----
> From: Jason van Zyl <ja...@tesla.io>
> To: Maven Developers List <dev@maven.apache.org>
> Cc:
> Sent: Saturday, October 6, 2012 9:31 PM
> Subject: SLF4J integration
>
>T he commit for review if anyone wants to take a look is here:
>
> https://github.com/tesla/maven-3/commit/4595e0860243854a7d80db8ebea97205aa4aca65
>
> Ceki added support for logging to a file without massive contortions so I
> have
> defaulted the implementation to slf4j-simple which is small and provides the
> equivalent functionality to the previous setup. It can also be controlled by
> a
> simple configuration file. Everything is working but I would like to try and
> make one small change as currently in debug mode (-X) all the binding
> information that Sisu knows about is pushed to the console which is very
> distracting. I think this is more trace level information. Once that is
> resolved
> and I write the documentation about how the new logging system works and how
> the implementations can be swapped I'll dcommit to Apache.
>
> Then I'll add the tests and documentation for the JSR330 work. After that
> I'll look at the Aether integration. Hope to have this done over the
> weekend.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> The modern conservative is engaged in one of man's oldest exercises in moral
> philosophy; that is,
> the search for a superior moral justification for selfishness.
>
> -- John Kenneth Galbraith
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
