Rick has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

Seam 2.0.1 released, Is Seam or Spring the best way to write JSF/JPA based applications?

02.01.2008
| 38069 views |
  • submit to reddit

Seam 2.0.1 is out and ready for download. Seam is a framework that supports web applications that are built with EJB3 and JSF--JEE5 centric.  Seam 2.0.1 provides cleaner RESTful URLs which "means that you don't have to do any extra work to consume or generate cleaner URLs" (Seam blog).  This is the first GA release of Seam in over six months.

Seam 2.0.1 works with the latest version of JBoss Tools (merged JBoss IDE and Exadel Studio), which provides support for building Seam applications, visual page editor, JSF support, Facelets support, JBoss AS support, and more.

The new release provides documentation for using Seam with WebSphere, OC4J, WebLogic, Tomcat, etc., and now runs with the latest version of JBoss 5.

The Seam generation tools now generates Seam apps based on an existing database or JPA annotated classes. 

What is Seam?

"EJB 3.0 has changed the notion of EJB components as coarse-grained, heavy-weight objects to EJBs as lightweight POJOs with fine-grained annotations. In Seam, any class may be an EJB - Seam eliminates the distinction between presentation tier components and business logic components and brings a uniform component model to the EE platform...But Seam is not limited to environments that support EJB 3.0. Seam may be used in any J2EE environment, or even in plain Tomcat. " from Seam site.

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.

Questions for Seam users:

  • Are you using Seam now, if so what do you think?
  • How is the Seam learning curve? 
  • What is your experience working with Seam?
  • What features of Seam can you not live without?
  • How good is the Seam generation tools?
  • Is Seam the best way to write a JPA, JSF based application?

Questions for Seam versus Spring:

  • How would you position Seam and Spring? competitors or complementary? overlap or augmentation?
  • If you are using Seam and Spring, and you had to live without one of them, which one would it be?
  • Do you use Seam with or without EJB3?
  • Do you use Seam with or without Spring?
  • Where do you think Spring and Seam overlap and when they do overlap which one is better?
  • Do you think Spring JSF support is weak or strong?

Getting started with Seam 

IBM developerWorks has an excellent series of articles introducing Seam features, namely, An application framework tailor-made for JSF, Conversations with Seam, and Ajax for JSF.

Resources
  1. Seam blog announcing new version of Seam
  2. Seam site


About the author

Rick Hightower is CTO of Mammatus and is an expert on Java and Cloud Computing. Rick is invovled in Java CDI advocacy and Java EE. CDI Implementations - Resin Candi - Seam Weld - Apache OpenWebBeans

Published at DZone with permission of its author, Rick Hightower.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

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: Daniele Gariboldi

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

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.

rick hightowercto of arcMindbloglinkedin

Carlos Sanchez replied on Fri, 2008/02/01 - 1:27pm

Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...

http://www.carlossanchez.eu

Rick Hightower replied on Fri, 2008/02/01 - 1:31pm in response to: Carlos Sanchez

I agree they get that rep, whether its deserved or not. What can they do to change it? Also, Seam relies heavily on EJB3 or at least it did at first, which I think hurts it. I think if they advertised their Spring support more and added some Guice support, things would be better.

 

rick hightowercto of arcMindbloglinkedin

Cay Horstmann replied on Fri, 2008/02/01 - 1:50pm

I find it interesting that you say that people pick up JSF the fastest. Maybe it isn't as complex as its detractors make it out to be :-)

I find that my students pick up JPA very quickly as well, so Seam sounds like a winner for gluing the two together.

Seam doesn't need Hibernate persistence, but it is a bit of an effort to strip out the unnecessary pieces when you deploy on an app server other than JBoss. I think it would be good if the Seam packaging was more vendor-neutral.

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

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).

rick hightowercto of arcMindbloglinkedin

Jim Hazen replied on Fri, 2008/02/01 - 2:04pm

* Are you using Seam now, if so what do you think?
Have used in the past. Not yet in production.
* How is the Seam learning curve?
Pretty shallow actually. Since it's geared towards smoothing the edges and easing JSF/EJB/JPA development you end up learning the framework quickly by solving one previous headache at a time. A J2EE Seam development cookbook would be a great resource.
* What is your experience working with Seam?
Been playing with it since early betas. Evolves at an amazing pace and yet continues to refine the total picture of J2EE web development. The Netbeans of frameworks. High quality, focused, integrated.
* What features of Seam can you not live without?
Annotations, contextual variables. Contextual variables = information discovered by a bean that can be scoped and injected into other beans and JSF EL.
* How good is the Seam generation tools?
Can't comment on the IDE tools however using seam-gen to get started on a new project without having to worry about dependencies is pure gold.
* Is Seam the best way to write a JPA, JSF based application?
Absolutely.

* How would you position Seam and Spring? competitors or complementary? overlap or augmentation?
Complementary for now. Because of the Spring integration both frameworks can coexist. However I'd anticipate that in the future Seam will prove to have the best tools for my jobs and my use of Spring beans will dissapear over time.
* If you are using Seam and Spring, and you had to live without one of them, which one would it be?
Spring
* Do you use Seam with or without EJB3?
Both. EJB provides many very useful middleware services in a nice standard package. With EJB 3.1 dropping the business interface requirement I don't see why anyone wouldn't want to use EJB with Seam. Unless they're using Groovy with Seam.
* Do you use Seam with or without Spring?
Both
* Where do you think Spring and Seam overlap and when they do overlap which one is better?
Dependency injection = Seam wins. Utility features = Seam has far supperior JSF support. As well as good EJB and JPA support. Is the Seam EJB/JPA support better than Spring? Yes. Both frameworks can inject an EJB or an EntityManager but in my book Seam consistently provides utility for working with EJB and JPA. Seam was first with great EJB/JSF integration (improved EL, improved components, data binders, converters, validators) not just variable resolver integration. It was also first with great JPA integration. EntityHome and Query frameworks are excellent value adds over prior XXXTemplate functionality. Seam also provides a zero config OSIV solution, something that many Spring users unfortunately still struggle with. I'm sure the same features can and perhaps have already been implemented in current versions of Spring. However Seam has gone out of its way to ensure it excels at supporting JSF+business services+data in a clean and integrated way. If I need a tool for a JSF/JPA problem I'm going to reach for Seam first. If I later find that Spring does a better job, I'll use the Seam/Spring bridge and be happy use the Spring bean.
* Do you think Spring JSF support is weak or strong?
Weak. When put next to JBoss' continued involvement in JSF and the JSF ecosystem (components, tools, frameworks, standards bodies) Spring doesn't compare. Sure, if someone were so inclined they could use the Spring framework to privide many of the same services that JBoss employees have already written for Seam. If someone were so inclined...weak.

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. (next post)

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

Great to hear from you Jim. It is good to hear from someone who has used Seam. Thanks for the insight and opinions. Thanks for the detailed comment.

 

rick hightowercto of arcMindbloglinkedin

Jim Hazen replied on Fri, 2008/02/01 - 2:37pm in response to: Dan Allen

Excellent post. Couldn't have said it better myself and I tried.

Dan Allen replied on Fri, 2008/02/01 - 2:38pm in response to: Carlos Sanchez

[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]

This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.

Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.

Dan Allen replied on Fri, 2008/02/01 - 7:07pm

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
Software Consultant / Author of Seam in Action / Committer on the JBoss Seam project

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 JBoss Seam project

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

[quote=mojavelinux]

[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]

This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.

Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.

[/quote]

Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.

 

rick hightowercto of arcMindbloglinkedin

Dan Allen replied on Fri, 2008/02/01 - 3:02pm in response to: Rick Hightower

I never made a claim that Carlos is stupid. I am very familiar with his work and I know he is extremely smart. What I was saying was not make stupid comments.

People think Seam is JBoss focused because people keep saying it is, not because it is. Perhaps it is my personal mission, but I hope to oust this myth. There have been a couple of members of the Seam project who have skipped sleep many at night to try to get Seam working on all application servers, a lot of that time spent because the application server has bugs, not because of bugs in Seam. There is a very strong effort and while I don't want to offend Carlos, he offended the work done by very dedicated folks on the Seam project. So if you have something to say, *back it up*.

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

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

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: Andrew Barton

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.

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

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 

 

Rick Hightower replied on Sat, 2008/02/02 - 1:47am in response to: Dan Allen

I do a lot of consulting and I talk to a lot of decision makers. There are a lot of decision makers (guys who hold the purse strings) out there who feel similar to the way Carlos does (I am personally on the fence). So if it is a misconception, it seems to be common one. So how do you think JBoss can dispel this?

 

rick hightowercto of arcMindbloglinkedin

Dan Allen replied on Sun, 2008/02/03 - 2:24am in response to: Rick Hightower

So how do you think JBoss can dispel this?

Now that is a great question! As with all misinformation, the first step is admitting that it exists. Okay, we admit it exists. Next, you have to focus on your interop. JBoss hired a Seam developer specifically for this purpose. The Seam reference documentation is getting beefed up with a whole bunch of sections on running Seam on the various application servers. With that started, the next big step is building a great community. My mouth is zippered because I don't want to be the spoiler on this, but just know that before you are kissing your loved one on the cheek this Valentine's day, there is going to be a long awaited announcement in this area. Finally, you just keep making the software better, because at the end of the day, we really do just pick the best software out there.

On a side note, I really like what you are doing with Crank and I do hope that Seam developers have full opportunity to take advantage of the work you have done there. Integrating infrastructure like that into Seam is not difficult and worth it, as Seam offers a wide-range of integrations that act as a nice complement. 

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

John Denver replied on Sun, 2008/02/03 - 6:08am

Spring Forever!. The best technology happened to Java, Changed the way on how to write middleware. I use Wicket+Spring also SpringMVC+Spring and sometimes JSF+Spring depend the project.Also Spring 2.5 include many annotations that you can do the same thing as seam with JSF and Spring and you don't need a heavyweight appserver.

Really EJB3 and Seam came to late why this projects didn't exist in 2003, Now is Spring Time!.

Magir Nrave replied on Sun, 2008/02/03 - 7:59am in response to: Dan Allen

[quote=mojavelinux]

So how do you think JBoss can dispel this?

Now that is a great question! As with all misinformation, the first step is admitting that it exists. Okay, we admit it exists. 

[/quote] 

It's amazing how the very next comment (by Sidewinder) proves this

 

Rick Hightower replied on Mon, 2008/02/04 - 1:30am in response to: Dan Allen

On a side note, I really like what you are doing with Crank

Thanks. I was not sure many folks noticed it. Good to hear.

Seam seems to have a lot of features.

 

rick hightowercto of arcMindbloglinkedin

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

[quote=rhightower]So how do you think JBoss can dispel this?[/quote]

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

1. Spring was first and it's already in production. Most development shops are already using Spring to some degree. They sold Spring by painting EJB as a heavyweight devil and Spring as a framework that was "lightweight" enough to do everything.

2. Developers are not dissapointed with Spring. Where there were a lot of developers thirsty for an alternative to EJB 2.x, there are much fewer actively looking to replace Spring. Spring development is active. There is room for improvement in every framework and Spring has actively evolved, introduced new beneficial improvements and made itself easier to use. There's a worry that Spring/Seam will leap frog each other release after release and since it's too difficult/costly to constatly switch from one to the other, shops stick which what they're running (Spring).

3. Selling Seam by selling JSF/EJB/JPA is a problem. While it's true that Seam makes using these great technologies easier, many assume the converse, that you need to use these technologies in order to use Seam. I hear time and time again that there's no point in Seam because we're using WebWork/Spring/Hibernate already. Is the JSF/EJB/JPA stack better? If so it'll need to be demonstrably better, a mere 10-15% better won't justify a migration.

--

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.

Rick Hightower replied on Mon, 2008/02/04 - 4:22pm in response to: Jim Hazen

Jim,

Thanks for your insight. You, David and Andy have given me a lot to think about.

How do you think Seam does against Apache Orchestra?

How do you think Seam Security does against Acegi?

It seems that Spring has mostly ignored JSF. There is very little support for JSF (I know what support is there and its not much). Unless you count Spring WebFlow, which.... another topic.

 

 

 

rick hightowercto of arcMindbloglinkedin

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

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.

Rick Hightower replied on Tue, 2008/02/05 - 5:16am in response to: Jim Hazen

As always, good feedback Jim.
rick hightower cto of arcMind blog linkedin

Rick Hightower replied on Wed, 2008/02/06 - 8:12pm in response to: Dan Allen

It was nice meeting you Dan. I hope your book does well.

 BTW There are a few books on Seam already... what do you think your book has that the other book's don't? what is the differentiator for your book?

 

rick hightowercto of arcMindbloglinkedin

Rainer Eschen replied on Fri, 2008/02/15 - 1:51am

Rick, we're using Crank for some time now, but without the JSF integration from the Crank examples. We preferred ICEfaces and had no time to port this. So, at the moment we don't get Crank-paged tables and the like. We use ICEfaces plus its Facelets integration, but Spring-managed backing beans and Acegi, Crank on Hibernate. We came from a EJB 2.x/3.x environment and used Crank to trim our architecture. Do you think we should have a look at Seam to ease our JSF development?

Springsteam Blog - Next Generation Java Development

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.