12:57 p.m.
I'm trying to deploy the seam-booking example in WebSphere v8 beta without succes now
One of the problem is that the class "org.jboss.logging.JBossLogManagerLogger"
(In seam-solder.jar) needs org.jboss.logmanager.Logger
I can not find this class in the CR2 distribution
Has this class been forgotten or is it a hard dependency on some JBoss-AS lib?
Thanks
2:38 p.m.
On Sat, Mar 19, 2011 at 13:57, Denis Forveille <denis.forveille(a)gmail.com>wrote:
I'm trying to deploy the seam-booking example in WebSphere v8
beta without
succes now
One of the problem is that the class
"org.jboss.logging.JBossLogManagerLogger" (In seam-solder.jar) needs
org.jboss.logmanager.Logger
I can not find this class in the CR2 distribution
Has this class been forgotten or is it a hard dependency on some JBoss-AS
lib?
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.
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.
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).
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.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<scope>runtime</scope>
<version>1.5.10</version>
</dependency>
<dependency>
<groupId>org.jboss.logmanager</groupId>
<artifactId>jboss-logmanager</artifactId>
<version>1.2.0.CR4</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
<scope>runtime</scope>
</dependency>
-Dan
--
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
1:26 p.m.
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(a)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
2:43 p.m.
On Sat, Mar 19, 2011 at 13:57, Denis Forveille <denis.forveille(a)gmail.com>wrote:
I'm trying to deploy the seam-booking example in WebSphere v8
beta without
succes now
Btw, would you be interested in writing an Arquillian [1] adapter for
WebSphere? We could *really* use that. Plus, it would practically guarantee
that you don't end up in the endless cycle of having to debug Seam problems
on WebSphere after the fact, like you've had to do *all through* Seam 2
development :)
Now that Arquillian 1.0.0.Alpha5 is out, it's a good time to work on a
container adapter. You can see examples in the containers folder of the
source code [2]. If you have questions, either join #jbosstesting IRC on
freenode (very active) or post on the forums [3] (also very active).
-Dan
[1] http://arquillian.org
[2] https://github.com/arquillian/arquillian/tree/master/containers
[3] http://community.jboss.org/en/arquillian
--
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
1:47 p.m.
On Sun, Mar 20, 2011 at 12:18, Denis Forveille <denis.forveille(a)gmail.com>wrote:
Dan,
I will give a look at Arquilian and find what is needed
Turns out that we have a Websphere 7 container already working to some
degree. See: http://community.jboss.org/message/559002
We are also in the process of splitting out the containers into their own
repositories to make them simpler to build.
, and yes I would like to see Seam3 run as smooth as possible on WAS
v8.0.
The intersting thing is that WAS v8 has a different implementation stack of
implementation of standards than the traditional ones used by Seam 3
(OpenJPA, CDI impl based on OpenWebBean, JSF 2.0 based on MyFaces etc.).
I'll try as much as possible to have the
That shouldn't matter. The whole idea of Seam 3 is that it's portable (as I
describe here: http://in.relation.to/Bloggers/IsSeam3GoingToBePortableOrWhat).
Of course, we will leverage vendor extensions as extra features, but that
doesn't get in the way of using a module. In fact, in the JCR module, we
have developers from two vendors working on it, which is an ideal case to
me.
Before being comfortable with Seam3, the new things I have to master (like
many other Seam 2 users I guess) include DI, CDI, JEE 6, Seam 3 etc in
addition to maven and git. The step is quite high (or should I say the
stair..lol) for an "old school" user and contributor to Seam 2, familiar
with svn and ant. It can take a long time to assimilate all of that before
being comfortable using and contributing to Seam 3 and play with Arquilian.
IMHO this may be an obstacle for Seam 3 adoption (but not the fault of Seam
3 but of the new way to develop JEE apps )
It's exactly the revolutionary approach Seam 2 took by boldly embracing Java
5, EE 5 and the many integrated technologies. We take these large leaps
forward so that we can embrace the inevitable change.
But we can also leverage a lot of the existing knowledge because the
programming model retains the same contextual, state-oriented philosophy.
The forthcoming migration guide will make that pretty clear.
But that's not to say we are bound to that philosophy either. Several of the
Seam modules are exploring completely new approaches, and that's great.
My first priority is to have the seam-booking app starting and running on
WebSphere v8.0 beta and educate my self on the technology.
Great. We'd definitely like to have seam-booking validated on WebSphere.
Then we can feel even more confident in our portability.
And if I can express some opinion on the rush to Seam3 final.I think that
many people that will look at Seam 3 will look first at the documentation,.
then will try the booking sample app and finally will check the wiki and he
forums
There will be only one Seam 3 Final release in the life os Seam 3.. Many
people are working very hard to reach this goal and we can not miss this
opportunity to show how Seam is a great framework to the world. It is better
IMHO to have the more shiny Seam v3.0 distribution as possible than to rush
it and let people wait for a v3.1 even if it is obviously not possible to
get everything perfect for v3.0.
For this, IMHO it is very very important for people to easelyt understand
Seam 3 and that the booking sample app just build and run "as-is" without
any tweaks and that the code is very "clean" and demonstrate the power of
Seam 3 (and CDI JSF 2 etc). Even if it is stated that the booking app is
target to GF 3+ and JBoss App 6+, it should be "as neutral" as possible for
people using other ASS (Oracle, WebSphere) to be able to taste it too...
About the WiKi, IMHO it is due for a minimal "cleaning" before Seam v3.0
It should be clear of what is related to Seam 2 and what is related to Seam
3. Seam 2 is still there for a long time as many people will not be able to
quickly switch to a JEE6 App server in production. I suggest to start from
bottom to top with the link on the left bar of the WiKI and check page per
page. Also on the left bar I would group the pages differently :
- Seam 3
- Documentation (Include a brief description of the role each module
here. Add the missing ones)
- Download
- Tooling
- Development
- Contribute
- Report bugs (new page, maybe a list here with all the links to the
JIRA for each modules, and a link to the SEAM3 JIRA for "global" bugs and
maybe a way to have on 1 screen all the bugs relative to a release of Seam 3
whatever the module. I don't know if it is possible with JIRA)
- <anything related to dev,. maybe architecture/design or so docs>
- Module Handbboks
- Seam 3 Modules
- Solder
- Catch Module
- <other modules>
Also the left menu "Community/contribute and JIRA" should be merge under
the Seam 2 and under the Seam 3 sections with the pertinent information for
each version
I hope the release of Seam 3 will be a great success. The goal of this mail
was to give my opinion and to contribute to this goal. I hope nobody will
take it as an offence to they great and hard work on Seam 3.
Denis, you've given us many things to think about, focus on and consider. I
applaud community members that come forward with ideas to make Seam a better
stack. We are listening.
With that said, we've decided that releasing Seam 3.0.0.Final now is
critical for it to continue to succeed. As I mentioned in my blog entry,
it's not an end, it's a beginning. This is a way to say that Seam 3 is a
real project, that we've demonstrated that the modular strategy can be
pulled together into a stack and that developers can begin prototyping
applications with it. Obviously, there is plenty of room for enhancements,
polishing and new features. We'll listen to the community and from that
feedback, determine how best to proceed with releases (whether to focus on
3.0.x releases or quickly advance to 3.1).
Hope to see ya in #seam-dev.
-Dan
--
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
4782
days inactive
4784
days old
6 comments
2 participants
participants (2)
-
Dan Allen -
Denis Forveille