<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<font face="Liberation Sans">OK.<br>
Thanks Dan and Jason for the answer.<br>
</font><font face="Liberation Sans"><br>
Q and remarks about logging in Seam 3 and about your answer:<br>
</font><font face="Liberation Sans">- 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<br>
<br>
- 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<br>
<br>
- 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)<br>
<br>
- 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.) . </font>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..<br>
<br>
<font face="Liberation Sans">I included </font>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).<br>
<br>
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<br>
<br>
And now I'm stuck wit the following exception at startup also
related to logging:<br>
Caused by: java.lang.IllegalArgumentException: Invalid bundle
interface org.jboss.seam.servlet.messages.ServletMessages
(implementation not found)<br>
at
org.jboss.seam.solder.logging.Messages.getBundle(Messages.java:92)<br>
at
org.jboss.seam.solder.logging.Messages.getBundle(Messages.java:54)<br>
at
org.jboss.seam.servlet.ServletExtension.<init>(ServletExtension.java:70)<br>
<br>
<font face="Liberation Sans"><br>
Denis<br>
</font><br>
On 03/19/2011 03:38 PM, Dan Allen wrote:
<blockquote
cite="mid:AANLkTi=PY2ggObOjQvg75mWa9CVMBrzz1jULNAxfpJ2M@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Sat, Mar 19, 2011 at 13:57, Denis
Forveille <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:denis.forveille@gmail.com">denis.forveille@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
I'm trying to deploy the seam-booking example in WebSphere v8
beta without succes now<br>
<br>
One of the problem is that the class
"org.jboss.logging.JBossLogManagerLogger" (In
seam-solder.jar) needs org.jboss.logmanager.Logger<br>
I can not find this class in the CR2 distribution<br>
Has this class been forgotten or is it a hard dependency on
some JBoss-AS lib?<br>
<br>
</blockquote>
<div><br>
</div>
<div>You should not need this class. My guess is an overeager
scanner that's trying to look for classes that are optional :)
We've seen this in earlier versions of JBoss AS and GlassFish,
but since have been resolved.</div>
<div><br>
</div>
<div>Real quick background. Seam Solder bundles JBoss Logging 3.
JBoss Logging 3 is an abstraction layer over the main logging
backends, one of which is the JBoss LogManager (others are
slf4j, log4j and jdk14). JBoss Logging 3 will select which one
to use based on what is on the classpath.</div>
<div><br>
</div>
<div>Having said that, the *way* JBoss Logging 3 searches for a
logging provider is not pretty. We are in the process of
making that more robust and configurable (to force a
provider).</div>
<div><br>
</div>
<div>
If, in fact, you are seeing this error because of an overeager
scanner, the only way around it is to include all the logging
APIs on the classpath. But that is not the long term solution.</div>
<div><br>
</div>
<div>
<div> <dependency></div>
<div> <groupId>org.slf4j</groupId></div>
<div> <artifactId>slf4j-api</artifactId></div>
<div> <scope>runtime</scope></div>
<div> <version>1.5.10</version></div>
<div> </dependency></div>
<div><br>
</div>
<div> <dependency></div>
<div>
<groupId>org.jboss.logmanager</groupId></div>
<div>
<artifactId>jboss-logmanager</artifactId></div>
<div> <version>1.2.0.CR4</version></div>
<div> <scope>runtime</scope></div>
<div> </dependency></div>
<div><br>
</div>
<div> <dependency></div>
<div> <groupId>log4j</groupId></div>
<div> <artifactId>log4j</artifactId></div>
<div> <version>1.2.14</version></div>
<div> <scope>runtime</scope></div>
<div> </dependency></div>
</div>
<div>
<br>
</div>
<div>-Dan</div>
<div> </div>
</div>
-- <br>
<div>Dan Allen</div>
Principal Software Engineer, Red Hat | Author of Seam in Action<br>
Registered Linux User #231597<br>
<br>
<div><a moz-do-not-send="true"
href="http://www.google.com/profiles/dan.j.allen#about"
target="_blank">http://www.google.com/profiles/dan.j.allen#about</a><br>
<a moz-do-not-send="true" href="http://mojavelinux.com"
target="_blank">http://mojavelinux.com</a><br>
<a moz-do-not-send="true"
href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br>
</div>
<br>
</blockquote>
</body>
</html>