Posts Tagged ‘JBoss Seam


JBoss Seam application blueprint

I am a JBoss Seam user since its v2.0 alpha something (back in 2007). I still remember the hard decision in picking up the alpha and later beta version instead of sticking with the stable but feature missing 1.2.
Seam is an incredible framework for web applications, it covers the majority of the requirements you have in such applications. But this tremendous power comes with a price, it is often hard to find the best combination in the first application you develop. Its variety of contexts combined with the possibilities of handling the page data through injection and outjection results in a challenge for the Seam newbie, not to mention the possibilities of handling the flow between pages…

That’s the reason I thought about developing a blueprint for Seam applications… I know that for now SeamGen generated applications are considered blueprints for Seam applications but I really feel like there are plenty of missing parts. SeamGen applications don’t use Conversation scopes (only to give an example cause the list of Seam features that are not explored by a SeamGen application are enormous). I am also sure that I won’t develop THE blueprint for a Seam application but at least I’ll try to document all the knowledge I’ve gathered from a few projects and a few POCs.

Managing page flow and conversation demarcation

Seam has a neat feature for specifying page flow: pages.xml and files. The first one is able to specify navigation rules for every view in the application and should be used for specifying global rules as when Exceptions are thrown or for actions that have the same result independent of the current view. This post presents good practices for defining page flows using Seam. There is even one thing covered in this post that I recommend: specifying conversation demarcation on files but there is one thing suggested on this post that I need to investigate carefully: the impact of joining conversations instead of spawning new ones. I agree with the post that not joining may spawn unwanted conversations and thus increase memory usage but I cant say beforehand which are the drawbacks of joining a conversation.
A good way of redirecting the user to a new view with total control over conversation propagation is by using the s:button tag. This tag has one property named view that specifies the target view-id and another one called propagation in which you can specify the conversation propagation. The following example redirects to a view named “newUser.xhtml” and suspending the current conversation scope:

<s:button value="New User" view="/newUSer.xhtml" propagation="none"/>

And if this view required a conversation scope this could be specified on with the <begin-conversation> tag.

Authentication and authorization

Everytime that you are developing an application targeting a deploy on a full fledged J2EE application server and if possible, prefer to delegate authentication and authorization to the Application Server JAAS. The following code when configured on Seam components.xml delegates to the specified JAAS domain:

<security:identity jaas-config-name="myJAASDomainName" remember-me="true"/>

This avoids the rather limited approach of specifying an authenticator method on an application Seam component since a JAAS authenticated user will be propagated all the way down the EJB container (in case you are using it).

That’s all for now I’ll try to update this post as soon as I format more knowledge around JBoss Seam.


Seam on JBoss 5.x without Seam Deployer

Recently I started a proof of concept for a new project that will run on JBoss 5.1. The reason for picking JBoss 5.1 instead of the mature 4.2 series was due to its full support for JavaEE 1.5 (4.2 supports only EJB3 spec, no servlet injection, etc) as well as its longer support (4.2 will start an EOL cycle soon).
As soon as I decided to use JBoss 5.x the classloading nightmare started. First of all, Seam uses a kinda strange hack for detecting its components (its scanner class makes use of which in turn does not work on newer VFS system released on JBoss 5.x).
Recommendation on Seam forums is to include no Seam file at you EAR/WAR and let Seam deployer do the trick but thiss comes with much obvious limitations:

  1. You’ll need a separate packaging for your application on JBoss (this is probably the worst limitation)
  2. Seam (and its dependencies) upgrades will involve patching Application Server files

But although recommended you can still deploy a regular Seam application without Seam Deployer. I’ll try to provide a step-by-step guide on how to circumvent this limitation:

First step: remove seam.deployer from $JBOSS_HOME/server/default/deployers (an alternative and less intrusive solution that I just found after writting this post is described over here)
Second step: add all Seam dependencies (jboss-seam-ui.jar, jboss-seam.jar, etc) inside EAR (I sincerely suggest under a lib folder).
Third step: place a jboss-app.xml with the following content on you EAR/META-INF folder

<?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE jboss-app
    PUBLIC "-//JBoss//DTD J2EE Application 4.2//EN"

Fourth step: place a jboss-classloading.xml also on EAR/META-INF folder with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"

Fifth step: place jboss-seam-int-jbossas.jar from seam.deployer/lib-int into your EAR/lib folder. (this jar contains org.jboss.seam.integration.jbossas.vfs.VFSScanner)
Sixth step: place another jboss-classloading.xml on WAR/WEB-INF folder with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"

Seventh step: Place a jboss-web.xml under WAR/WEB-INF with the following contents:

	<class-loading java2ClassLoadingCompliance="false">

Eighth step: place a anywhere in the classpath (anywhere but before seam jar) with the following contents:


Ninth step: Add all Seam dependencies on MANIFEST.MF file under WAR/META-INF and remember to include jboss-seam-int-jbossas.jar on the classpath.

That’s all you need to avoid having a separate packaging for a Seam enterprise application running on JBoss 5.x (sincerely I guess that you risk having to remove the only). This also makes it easier to replace the JSF implementation on your application.


Blog Stats

  • 375,197 hits since aug'08

%d bloggers like this: