On 4/19/09 7:29 AM, Stuart McCulloch wrote:
2009/4/19 Filippo Diotalevi<[email protected]>
Hi,
reading this thread on the Spring DM forum [1] reminded me of the
"logging madness" (commons, log4j, slf4, slf4j bridges, ...) that
everybody starting with Felix and OSGi (and JaveEE, nowadays) will
eventually find.
In brief the problem is the base API of slf4j is a bundle, but
implementations like lf4j-log4j12 are bundle fragments with
import/export, therefore currently not supported by Felix.
These prevents newbies to run, f.i., Spring DM out of the box,
confusion, and maybe migrating to other osgi containers. Of course
there are many simple solutions to this problem, but I think it would
be nice to provide some FAQ/precooked solution for everybody.
So the question is: what do you use? What's the best option?
- in my case, I have osgi-fied slf4 with the log4j binding with the
maven osgi plugin. Maybe a candidate for felix commons?
- does such a bundle already exist anywhere, so we can point user to
that bundle?
- I actually noticed that if I remove the Fragment-Host property in
the lf4j-log4j12.jar everything seems to work. Such property was added
to make it work with Equinox (bug 73 [2]) due to a dependency cycle
between the api and the impl.
However, removing the fragmeng-host, Felix doesn't complain
ouch, making an implementation bundle a fragment of the API bundle just to
work around a bug in the Eclipse build process sounds like madness to me!
you'll notice that this isn't even a runtime issue, the only reason they
added
the fragment directive was to avoid a build-time bug - and this has caused
no
end of problems for probably many more people in the long run :(
there is a valid use-case for fragments, but this definitely is not one of
them!
I agree with Stuart, this is way beyond ugly if that is the real reason.
I also agree with Filippo that we should probably create an FAQ out of
this somehow.
-> richard
[1] http://forum.springsource.org/showthread.php?t=70639
[2] http://bugzilla.slf4j.org/show_bug.cgi?id=73
--
Filippo Diotalevi
