You shouldn't need to add webbeans-logging.jar to your classpath, it's included as part of webbeans-servlet.jar.

Web Beans isn't doing anything to adjust log4j configuration, but it would be worth checking that you are indeed using log4j - by default Tomcat will use JUL.

And so Web Beans will use JUL - so try adding log4j.jar to WEB-INF/lib.

I hope one of the extensions on Seam 3.0 is an easy way to invoke the SFL4J bridge so that anyone that wishes to do so (and bet that pretty much everybody) can avoid using JUL. (IMO JUL is the worst piece of c... every included in the JDK)

In fact... I wonder... why don't use SFL4J directy? any one crazy enough to like JUL will be able to do it using the slf4j-jdk14-*.jar, that would have the extra advantage that you would avoid the pain of using JUL inside the WebBeans RI.

We don't use JUL inside Web Beans, but an adapter layer like slf4j that outputs to log4j if present, otherwise JUL.

If you want support for slf4j output, please open a WBRI JIRA and provide a patch for the webbeans-logging module. As for using it directly, not particularly interested given that it adds another dependency, and does something which can be trivially achieved with about 3 classes.

Pete Muir wrote on Jun 30, 2009 01:09:


We don't use JUL inside Web Beans, but an adapter layer like slf4j that outputs to log4j if present, otherwise JUL.

That is the best news I have read ever!

If you want support for slf4j output, please open a WBRI JIRA and provide a patch for the webbeans-logging module.

There is really no need, because slf4j can trick WBRI and make it believe it is log4j... (it can do that for JUL too, but only by initializing an special bridge because because under the java.* namespace cannot be replaced. But if you guys support log4j that means I do not need to use the special bridge, and I am really happy to read that. )

As for using it directly, not particularly interested given that it adds another dependency, and does something which can be trivially achieved with about 3 classes.

Maybe so, but if you delegated this job to Sfl4j you wouldn't have to maintain those 3 classes (and you would leave to Slf4j the integration to any logging provider). Also integration with Slf4 would have the advantage of getting parameterized logging (something AFAIK JUL and log4j do not have)

Francisco Peredo wrote on Jun 30, 2009 21:18:

Pete Muir wrote on Jun 30, 2009 01:09:


We don't use JUL inside Web Beans, but an adapter layer like slf4j that outputs to log4j if present, otherwise JUL.

That is the best news I have read ever!

Right, this is the same as Seam :-)

As for using it directly, not particularly interested given that it adds another dependency, and does something which can be trivially achieved with about 3 classes.

Maybe so, but if you delegated this job to Sfl4j you wouldn't have to maintain those 3 classes (and you would leave to Slf4j the integration to any logging provider).

Well then we are down to the argument about whether it's better to maintain 3 classes, or add a dependency. For a application I would add the dependency, for a framework, I wouldn't.

Also integration with Slf4 would have the advantage of getting parameterized logging (something AFAIK JUL and log4j do not have)

Yes, our logging classes add support for this idea to.

Pete Muir wrote on Jul 01, 2009 00:16:

Francisco Peredo wrote on Jun 30, 2009 21:18:

Pete Muir wrote on Jun 30, 2009 01:09:


We don't use JUL inside Web Beans, but an adapter layer like slf4j that outputs to log4j if present, otherwise JUL.

That is the best news I have read ever!

Right, this is the same as Seam :-)

You guys should convince the guys at Mojarra to do the same, i hate being forced to use the bridge when trying to do logging for JSF ;-).