[seam-dev] Seam-booking in Seam 3 CR2: where is org.jboss.logmanager.Logger?

[Dan Allen]

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 at 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

[1] http://sourceforge.net/projects/jboss/files/Seam/3/3.0.0.CR3/
[2] http://docs.jboss.org/seam/3/solder/latest/reference/en-US/html/
[3] http://in.relation.to/Bloggers/IsSeam3GoingToBePortableOrWhat

-- 
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110321/4096888f/attachment.html