Seam And JBoss

Seam integrates with Spring as an option. Seam provides different contexts (somewhat like scopes in Spring) for components (like JSF managed beans), namely, Stateless, Event, Page, Conversation, Session, Business Process and Application context that provide many more options than the traditional scopes in JSF.

Seam provides many enhancements to the JSF programming model for validation, JSF components, RESTful URLs, Ajax remoting, providing security support, and a lot more.

Seam integrates with Quartz, GWT, Hibernate Search, iText PDF, JBossCache, jBPM, RichFaces, IceFaces, Groovy, JEE, JMS, WebServices, Java mail (with markup to generate mail, sending and receiving mail), and much more.

Seam seems to be well documented and there are several books published on Seam.

Seam 1.0 beta was released on 9/19/2005. The first versions seemed to be an alternative to Spring with a strong emphasis on JEE, JSF and EJB3. Later versions seemed to support more application servers and integration with Spring.

Seam integration: Spring and Seam running through the meadow, holding hands

It appears that Seam integrates well with Spring. You can inject Seam components into Spring beans, inject Spring beans into Seam components, and use a a Spring bean as a Seam component. In addition Seam provides Spring scopes for all of the Seam contexts, you can use Spring transaction support, and much more.

IBM developerWorks has an excellent series of articles introducing Seam features, namely, An application framework tailor-made for JSF, http://www-128.ibm.com/developerworks/java/library/j-seam1 Conversations with Seam, http://www-128.ibm.com/developerworks/java/library/j-seam2 and Ajax for JSF. http://www-128.ibm.com/developerworks/java/library/j-seam3

documented on: 2008/02/01, by Rick Hightower

Matthew Schmidt replied on Fri, 2008/02/01 - 7:51am

Nice overview. We looked at Seam about 6 months ago and it seemed pretty nice, but in the end it was hard to swallow almost the entire JBoss package. At times, we're not super thrilled with how Hibernate generates its queries, so we figured Seam was going to do the same. Of course, if you go down the Spring road, you usually end up better off if you swallow their pill too :) I think its great that they can integrate together to help fill each others weak points.

Daniele Gariboldi replied on Fri, 2008/02/01 - 9:39am

I use seam (`JSF 1.2 ` facelets ` richfaces) ` hibernate ` tomcat ` spring.

I started with jsf 1.1 and had to add a lot of 3rd party libs to solve common problems with JSF and web development.

Spring was a must from the start, and now it's well integrated in seam.

Seam let me consolidate and use fewer libs to manage for example onload page actions, or problems with redirects.

I think if you develop with JSF seam is a must, but think twice before using JSF: it has a deep learning curve and it's not flexible. Often you have to change your decisions and web design decision because of JSF and its components.

I would say seam is good despite JSF.

Rick Hightower replied on Fri, 2008/02/01 - 12:55pm in response to: garidan

I work with people who think that. I also work with folks who think JSF is quite natural. We do fairly complex, feature rich webapplicatoins and its hard to imagine doing these apps without JSF.

I teach JSF classes, Spring MVC classes and in the past taught Struts classes (I also write courseware which is painful to do). I find that the students pick up JSF the fastest. JSF works best when you are building an application with rich features. If your webapplication is more like a website and less like an application than you are better off using something else. Plust JSF forces some behavior on your apps, if you are not happy with that behavior or can't abide by it, then JSF is not a good fit (When that happens, I use Spring MVC). However, I think there is a vast market for JSF based applications.

I recently wrote a series highlighting JSF development and how easy it is: JSF Tutorial Part 1, JSF Tutorial Part 2. http://www.ibm.com/developerworks/edu/j-dw-java-jsf1-i.html http://www.ibm.com/developerworks/edu/j-dw-java-jsf2-i.html

Dan Allen replied on Fri, 2008/02/01 - 2:19pm

These days, it's hard to advocate a web-oriented framework without sounding fanatical or biased. It's also getting more and more dificult to raise the volume of your voice so it can be heard over the croud. If you can turn your ear in my direction, then hear this:

Seam is great software that is user focused. We get caught up in this word "framework" and sort of forget the real reason we are writing the software, to serve the needs of our users or our client's users. That sounds like a pretty lofty goal, so let me quickly get to the substance.

While entertaining for us developers, users really don't want to spend their days paginating through endless result sets. What they want is consolidation. They want advanced, real-time searches, reports in the form of PDF or Excel, charts, emails, file uploads, dynamic graphics, page flow wizards, workspaces, etc. Basically, they want all that stuff that is really hard to develop, or at least harder than dropping the database into a CRUD generation tool. With Seam, you get both the CRUD generation tool and then all of that extra stuff too.

The real question is, how difficult is it to accomplish these tasks in Seam and is it easier than using an alternative. I am not going to lie to you and say that you don't have to think. Even if you do focus your mind on the task, some people are going to be better than others at picking it up. My feeling, though, is that Seam requires you to type the least and get the most bang for your buck. It accomplishes this using annotations, XHTML-based templates, and JSF components. I have gone on too long without examples, so let me dish a couple out.

You can add a pie chart to your page as follows (numbers are made up):

<p:piechart title="Framework Market Share Distribution">
  <p:data key="Seam" value="25"/>
  <p:data key="Spring" value="25"/>
  <p:data key="Struts" value="25"/>
  <p:data key="JSF" value="25"/>
</p:piechart>

The result is a nice JFreeChart piechart with four equal parts. Let's say you want to upload a file:

<s:fileUpload id="image" data="#{newFramework.logo}" accept="image/*" contentType="#{newFramework.logoContentType}"/>

The action handler (a Seam component perhaps) will have two properties populated when the form is submitted, a byte[] property named logo with the image data and a String property named logoContentType with the image content type sent by the browser. Now let's say you want to create a PDF:

<p:document title="Framework Market Share Report">
  <p:font size="18"><p:paragraph>Framework Market Share Report</p:paragraph></p>
  <p:piechart title="Market Share Distribution">
    <ui:repeat var="_framework" value="#{frameworks}">
      <p:data key="#{_framework.name}" value="#{_framework.marketShare}"/>
    </ui:repeat>
  </p:piechart>
  <ui:repeat var="_framework" value="#{frameworks}">
    <p:font size="14"><p:paragraph>#{_framework.name}</p:paragraph></p:font>
    <p:image value="#{framework.image"/>
    <p:font size="12"><p:paragraph>#{_framework.summary}</p:paragraph></p:font>
  </ui:repeat>
</p:document>

The PDF is rendered and pushed to the browser when the URL of this template is requested (perhaps /frameworkReport.seam). How about a component that handles this logic.

@Name("frameworkAction")
public class FrameworkAction {
    @In private EntityManager entityManager;

    @DataModel List<Framework> frameworks;

    @Factory("frameworks")
    public void loadFrameworks() {
        frameworks = (List<Framework>) entityManger.createQuery("select f from Framework f").getResultList();
    }
}

Granted, I went a little overboard on the component definition, but I did just made it up off the top of my head. The point is, Seam just gets you right to the features and you are having fun and getting the requirements done at the same time. To see more great examples of Seam and to learn all of the intimate details of components, context variables, conversations, page flows, business processes, JavaScript remoting, security, extended persistence contexts, and more check out my book Seam in Action. I have worked *very* hard on giving you all of the critical information that you not only need to use Seam, but to develop web applications with Java in general.

Dan Allen replied on Fri, 2008/02/01 - 2:54pm

You might be asking yourself, what about Spring? Seam and Spring are both competitors and complements. What Seam does for Spring is bring it state. That means extended persistence contexts, conversations, page flows, etc. You can use Spring to do what Spring does best and leave Seam in charge of maintaining state for the UI. In that regard, Seam and JSF have a similar relationship. Seam does not paint the UI, at least not a majority of it. That is left up to the extremely rich set of JSF components. My personal favorite is RichFaces because it looks nice and has just about all the components that I need on a daily basis. It also has the nice benefit of Ajax4jsf, which I discuss in my third IBM developerWorks article.

I apologize for this post being long and not well organized, but my point here has been to give you some substance, rather than another "you should use Seam" cheer that is mostly shallow. There are some rough spots in Seam, JSF, and just about any other framework we use. But with Seam, those rough spots are far outweighed by its ability to get you doing the advanced parts of your application very early on. You no longer have to dread those wild and crazy requirements that come from the user. If there is one thing to take away from this post, that would be it.

Dan Allen Software Consultant / Author of Seam in Action / Committer on the JBoss Seam project

David replied on Fri, 2008/02/01 - 1:35pm

Nice article Rick, as usual. We took a look at Seam a while back in hopes of overcoming some of JSF's "limitations" like bookmarking or deep linking, back button support, conversation scope, etc. but thought it was a bit much to swallow just for these things. So, we've moved toward solutions like RestFaces for bookmarking and Apache Orchestra for conversation scope, so we only swallow those bits that we need and aren't choking on stuff we don't need. :)

Rick Hightower replied on Fri, 2008/02/01 - 2:01pm in response to: defurd

David,

Good to hear from you. It has been a while since we been in the trenches together. Hopefully soon….

Very good point. We took a look at Seam in March 2007 and came up with a similar conclusion for our project. It was nice, but integrating yet another framework into what we were already doing seemed like asking for trouble. Plus the Spring support seemed nascent (at the time).

RestFaces and Apache Orchestra seem like good choices as well…. We should talk more often. I did not know you guys did that… I will have to pick your brain.

I have spoke to some folks that do really like working with Seam. Someone just integrated Seam and Crank (out of the blue).

Andrew Barton replied on Fri, 2008/02/01 - 3:28pm in response to: defurd

We also choose to adopt Orchestra instead of Seam. We had an existing application upon which we were doing significant refactoring. Among the many changes, we were going to make greater use of JSF and replace much of our core EJB 2.1 model with Hibernate. Due to the need to take advantage of lazy initialization for performance, we needed some way to manage the hibernate session across multiple requests. Both Seam and Orchestra offered workable solutions. But moving to EJB 3 seemed a bit risky given our schedule and budget. With Orchestra, we were able to create a simple persistence context factory that bound Orchestra to Hibernate directly without using JPA. Like you we choose a solution that allowed us to add just what we needed without having to 'swallow' additional frameworks that we had no immediate need for.

Dan Allen replied on Fri, 2008/02/01 - 4:01pm in response to: andrewbarton

> But moving to EJB 3 seemed a bit risky given our schedule and budget.

Seam definitely does not require the use of EJB3. In fact, when I use Seam personally, I never use the EJB3 piece. I just use regular-old JavaBeans and annotate them with @Name and @Scope(ScopeType.CONVERSATION) to get a stateful component. I am also a bit confused as to why there is this notion that Seam is any larger than Orchestra. The core of Seam is about a 800K JAR file which bootstraps a JSF PhaseListener. That's pretty much all there is to it. You can then add additional features a la carte. What's better is that instead of just having a conversation scope, you can have Seam manage the persistence context so that it is extended over the lifetime of the conversation without you even having to think about it. Recently, JBoss Seam added Maven 2 support so you can start using Seam in your project in a handful of steps (http://in.relation.to/Bloggers/SeamPublishedToMaven). Keep watching for more information in this area.

Remember, Seam is not necessarily an all or nothing choice. You can use it for its strengths and still get the great features of other frameworks such as Spring, GWT, and Crank.

Magir Nrave replied on Fri, 2008/02/01 - 4:53pm

Seam got a lot of things right. And it not just for EJB or JSF I just came across http://tacos.sourceforge.net/tacos5/tacos-seam/ which weds Seam2 to Tapestry5

Jim Hazen replied on Mon, 2008/02/04 - 3:30pm in response to: rhightower

> So how do you think JBoss can dispel this?

I think there are a few things that JBoss needs to be aware of/address.

IMHO Seam's Spring integration is the best thing it has going for it in terms of a selling point. Selling Seam as the best Spring plugin ever could greatly increase adoption. Spring is far too entrenched, and honestly, too good to be thrown out en mass. There isn't enough wrong with it to toss it.

However JBoss could/should argue that there are more things that could be better with Spring, enter Seam. Seam as a Spring plugin gives Spring developers some excellent new features. In the end both JBoss and Interface 21 have the common goal of delivering frameworks and tools to help Java developers. I have respect for both camps and could care less about brand loyalty. Seam's Spring support caught my eye because it demonstrated JBoss' willingness to achive this goal, giving me the developer the best tools regardless of camp or philosophy.

Once Spring users start to use and experience the wonders of their new Seam plugin, introducing them to active injection, conversation scope, the benefits of UI component driven and event driven development with JSF, …, should be a much easier task. From there developers have added choice. They can leverage the Seam features that present added value to their project on a feature by feature basis. They can mix in Seam over time without any fear of "loosing Spring".

Personally I already like Seam (for its great JSF and JPA support), however I'm beginning to realize that fighting against Spring is a loosing battle. Once in the door, Seam my very well change things from within. At this point though I don't really care if Seam completely replaces Spring in my projects as long as I have the opportunity to use the Seam features that will help me now. I can't use those features without getting Seam in house as an "approved framework" and I can't do that without selling it as a way of decreasing our Spring development time while in no way replacing or ripping out Spring.

Jim Hazen replied on Mon, 2008/02/04 - 5:52pm in response to: rhightower

I haven't taken a look at Apache Orchestra. From comments here it sounds like it implements some Seam conversation context features. But since I already have Seam I haven't looked at Orchestra.

Frankly we liked Acegi because of its tight and transparent integration into CAS our enterprise single sign-on provider. Now that we're moving away from CAS the value of Acegi (or really any security framework) has diminished for me. I don't need security driven display, or domain object filtering enforced at the application tier. Down the road if I do end up evaluating a security framework again, I'll reach for whatever most simply exposes the features I'm looking for.

I will say though that I personally would take a look at Seam Security first. When JBoss decides to do something they tend to carry the concept throughout the framework. Where as in my experience Spring as been good at providing additional granuals that a developer could composite if they wanted to, but tend to leave things at that level; able to be bolted on if so desired but not tightly woven out of the box. More and more I just want things to work out of the box and I'd like for core themes (like security) to be baked in and handled consistently throughout the range of core functions.

If for example if I had a web service being called by a remoted JSON object that had to choose an appropriate workflow based on parameter values and the transparent security credentials of the caller (as defined by the web user they were logged in as). I'm more confident that Seam would have a prepackaged solution than Spring. It may be that both frameworks can accomplish the same thing, but for whatever reason I assume I'll have to jump through fewer hoops to do it with Seam.

documented on: 2008-02-10