On 10 October 2012 14:42, Mark Struberg <strub...@yahoo.de> wrote:
> 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
>
only unzipping metaphorically, more scan the zip index for
/org/slf4j/impl/StaticLoggerBinder.class
If we see that index in the zip then we know there is an impl => it needs a
fully isolated classloader.
Anyone using funnels in existing plugins will have to be providing an impl
=> the presence of funnels can be inferred by the presence of an impl
That should handle, in as performant a way as I can think of, the issue of
existing plugins which already have slf4j dependencies of a different
version from the one Maven uses.
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.
>
What I also suggested is that we add a field to the plugin metadata as a
flag that this plugin needs an isolated slf4j rather than the shared one.
maven-plugin-plugin could add the flag *if not specified* by analyzing the
plugin's bytecode for any use of the slf4j-api method signatures. The flag
would also remove the need to scan the plugin's classpath for slf4j (unless
the user has added/overrided the plugin classpath with <dependency>
overrides... in which case the scanning is back on if we don't know an
isolated classloader is required)
That should allow us to build future backwards compatibility with plugins
being developed in the near future running against Maven 5.0 which uses
slf4j version 3.0 [Note: version numbers are invented, this is not a
commitment to deliver specific versions of dependencies in specific future
versions of Maven]
> 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
>
>
