Hey Denis. These are definitely questions worth asking and I'll consider incorporating the answers I've included inline into the refdoc or an FAQ.
On Sun, Mar 20, 2011 at 11:32, Denis Forveille
<denis.forveille@gmail.com> wrote:
Q and remarks about logging in Seam 3 and about your answer:
- I tough that slf4j was a
"logging back-end". I thought it was only another abstraction
layer similar to commons-logging and JBoss-Logging. It seems over
complicated that JBoss-logging (abstract layer) delegates to
another abstract layer(slf4j) that delegates to a concrete
implementation (log4j, JBoss-LogManager or JDK). You surely
already discussed this before but it sounds strange for a newcomer
in the world of Seam 3
It depends on how you define logging backend. SLF4j is somewhat of a hybrid, as it offers it's own simpler logger, yet can also delegate to Log4j and JDK14. In a sense, it's like commons-logging.
When we say logging backend, we mean "the concrete logging framework to which JBoss logging delegates". JBoss Logging does not have it's own logger. Really, it's not a logging framework, but rather a tool that introduces new features to the logging ecosystem. Those features are:
- typed message bundles and loggers
- internationalization support
- pluggable formatting for messages
- message codes
- serializable loggers
- injectable loggers (as provided by solder)
Thus, I would describe it as a programming model for logging, rather than a logging framework. The logger you use is up to you. If you provide no logging library, it just uses JDK14 logging, which is the leanest approach.
We didn't just settle on slf4j because it provides none of the features in the list above (or not sufficient for our vision).
- The Seam 3 CR2 distributes one concrete log implementation
(log4j) and JDK logger is implicitly there too. Why distribute
log4j.jar and not JBoss LogManager.jar? It seems not consistent
here. IMHO, either distribute both (as optional libs) or none and
default to jdk, the "default common log backend" to all
application servers
That's a bug in the distribution then -> jira. We should not be bundling any concrete log implementation. It should default to JDK14 unless you provide one of your own.
(Btw, there is a known problem with the reflection code that JBoss Logging uses to select a provider, and that needs to be fixed: JBLOGGING-57).
- the way slf4j configure the logger backend is great and can not
be simpler. I hope JBoss-logging will be as simple as slf4j in the
future (just drop a jar that contains the binder and the backend
impl jar)
Yep, I agree it should be. It's nearly there, except for JBLOGGING-57. I'd also like there to be way to select the provider explicitly JBLOGGING-58. Certainly room for improvement.
(I'll mention again for clarity, don't confuse JBoss Logging 3 with JBoss Log Manager, though the confusion is mostly on us).
- I don't use maven yet and assemble the booking app in RSA v8.0
by hand in a tentative to better understand what is needed to
deploy. I try here to use as much as possible what is provided by
WAS (JPA, JSF, CDI etc.) and so not to include "alien
implementation" jars (hibernate, jsf-ri, weld, jboss-AS-loggers
etc.) . That not that easy considering that WAS v8.0 is
also a beta version.. Similar to what you had to live with JBoss-AS
v6..
You shouldn't have to include any such alien jars. In the case you do, there is a bug somewhere, either in Seam or in Websphere. Let's identify it and squash it when it happens.
I included jboss-logmanager.jar
in my app and was able to go a little further (slf4j complains about
"Class path contains multiple SLF4J bindings". i will sort this out
later).
Ignore SLF4J's lamenting. It whines too much.
I then had a problem with an illegal acces to the constructor of
org.jboss.seam.servlet.ServletExtension. Declaring it "public"
solved the problem. I didn't investigated to know if is is a bug of
seam-servlet or in WAS
That's fixed in the CR3 stack. We've decide to make extensions public now because it was causing problems otherwise.
And now I'm stuck wit the following exception at startup also
related to logging:
Caused by: java.lang.IllegalArgumentException: Invalid bundle
interface org.jboss.seam.servlet.messages.ServletMessages
(implementation not found)
at
org.jboss.seam.solder.logging.Messages.getBundle(Messages.java:92)
at
org.jboss.seam.solder.logging.Messages.getBundle(Messages.java:54)
at
org.jboss.seam.servlet.ServletExtension.<init>(ServletExtension.java:70)
You need the CR3 stack [1]. The version of Solder you have shipped without the typed logger implementation classes (see Solder documentation [2] or my blog entry [3] for details).
-Dan