Weld logging dependencies

[pejovica]

Hi. I’m trying out weld logger example. I’m deploying to latest promoted build of glassfish v3.0.1
(it is bundled with weld 1.0.1-sp1) and I’m including dependency to weld-extensions-1.0.0.Alpha1.

The problem is that I can’t get it to work without including dependencies to slf4j-api and slf4j-jdk14.
And I thought that there was no need to include these, because I’m using weld. So, did I misunderstand
documentation?

[dan.j.allen]

Aleksandar Pejovic wrote on Mar 30, 2010 22:28:


Hi. I’m trying out weld logger example. I’m deploying to latest promoted build of glassfish v3.0.1
(it is bundled with weld 1.0.1-sp1) and I’m including dependency to weld-extensions-1.0.0.Alpha1.

The problem is that I can’t get it to work without including dependencies to slf4j-api and slf4j-jdk14.
And I thought that there was no need to include these, because I’m using weld. So, did I misunderstand
documentation?

Lincoln and I ran into the exact same problem the first time we tried to deploy the Seam Faces module. Here's the story.

First, yes, there is a catch with using the Weld Extensions Logger. It relies on the SLF4J API and implementation. So you have to include them in your application. Or do you?

GlassFish happens to have a very safe classpath thanks to OSGi. Yes, Weld bundles SLF4J, but it's bundled in an OSGi bundle and not exported. That means, no other application in GlassFish can see those SLF4J classes. So to use the Weld Extensions Logger, you need to bring both an API and implementation.

What about JBoss AS? In contrast, JBoss AS has an arguably unsafe classpath (or at least the Weld deployer is not setup to protect its dependencies). So the SLF4J API is leaking into the applications...meaning the applications can see those classes. In this case, you do not need to bring any SLF4J JARs. If you do, you cannot bring the API alone, or else it will conflict with the one in Weld. So you have to bring either nothing (non-portable), just the implementation (non-portable) or both the API and the implementation again.

Long story short, bring the API and impl in both cases, but for different reasons :)

And yes, we need to think this through a bit better.

[pejovica]

This definitely explains everything. :)

Dan Allen wrote on Mar 31, 2010 00:27:

GlassFish happens to have a very safe classpath thanks to OSGi. Yes, Weld bundles SLF4J, but it's bundled in an OSGi bundle and not exported. That means, no other application in GlassFish can see those SLF4J classes. So to use the Weld Extensions Logger, you need to bring both an API and implementation.

Part of my confusion was the fact that both netbeans and eclipse add slf4j classes to the project classpath. Guess that I overlooked that they treat weld-osgi-bundle as a regular jar. :)