- Posted by: Keith Donald
- Posted on: May 19 2008 10:21 EDT
- Worth looking at by Mirko Novakovic on May 19 2008 10:55 EDT
- Nice by Rick Hightower on May 19 2008 14:02 EDT
- Spring for world domination .... by Bernd Schuller on May 19 2008 15:00 EDT
- Re: Nice by alberto gori on May 19 2008 18:43 EDT
- Re: Seam vs. Spring Web Flow by Andy Gibson on May 20 2008 12:11 EDT
- Re: Nice by Ben Alex on May 20 2008 12:15 EDT
- Re: Nice by Keith Donald on May 20 2008 12:37 EDT
- Re: Nice by Juergen Hoeller on May 20 2008 03:37 EDT
- Re: Nice by Louis Sacco on May 21 2008 12:24 EDT
- Is JSF dead already?? by Hank Li on June 03 2008 16:59 EDT
Very nice framework - definitly worth looking at it. Thanks for the new features and modules in version 2.0! If you look for a comprehesive introduction to Spring Web Flow in German, look at: Spring Web Flow Intro - German - Mirko -
Tho I havent used it in any project, rife's continuations seemed like a much simpler solution to many of the problems webflow tries to solve
A lot of my clients use JSF and Spring together. I think it is great for my customers that JSF is finally getting first class support for Spring. Spring and JSF play well together and now there is support for additional scopes and such. So now this begs the question... Why would use Seam? It seems Spring now will have just about everything you need and there is major overlap between what JBoss provides and now what Spring provides. A lot more developers use Spring + JSF then Seam + JSF. (Granted some use all three.) Spring now provides JSF Ajax components... Who would of thought it....
So now this begs the question... Why would anyone use Linux? It seems Windows now will have just about everything you need and there is major overlap between what Linux provides and now what Windows provides.SCNR :-) There is Spring This and Spring That, and I'm sure other vendors / projects start feeling a bit pressured. For the users the freedom of choice is great.
So now this begs the question... Why would use Seam? It seems Spring now will have just about everything you need and there is major overlap between what JBoss provides and now what Spring provides.I don't think Seam is comparable to Spring + JSF integration. At least not with this integration. A more comparable project is surely Orchestra, that offers a much more intersting integration between JSF and Spring IMHO. But anyway they are both far to get the quality of Seam: -@In and @Out annotation are great and seem to be more powerfull of Spring DI, -email, PDF generation throught Facelets templates, -a RESTfull style programming model strongly integrated with Seam and its conversations (I don't think it is so much integrated in this spring library) -and possibility of inject a conversational EntityManager in a scoped bean (and much important also in combination with FlushMode.MANUAL emulating something similar to a long running transaction) -its unit test environment test can also emulate a JSF lifecycle -remoting, -security, -ecc ecc... You can get only some of these points using Orchestra or JSF + Spring integration. Spring modules tend to be more isolated as possible, while in Seam they are strictly coupled. IMHO this result in a better quality of the product/technology.
I've started looking at SWF as a Seam user, and am looking at writing a few articles comparing the two. They are very comparable, and they both have their strengths and weaknesses. Regardless, with two+ stellar full stack frameworks, the options for a full JEE java solution with a smaller learning curve are getting better and better. Cheers, Andy
But anyway they are both far to get the quality of Seam:In the interests of time - and remaining within my area of deepest expertise - I will only address the issue of quickly comparing Seam security and Spring Security. Based on a review of Chapter 14 of the Seam 2.0.2.GA reference guide, the following capabilities are provided by Spring Security out of the box whereas they are not provided out of the box by Seam security: * Ability to add enterprise-class security to your application with a single web filter and a 10 line XML configuration file. * First-class support for your choice of web applications, integration tests, batch processing engines, remote clients, web services, RESTful services and more (not simply web applications alone). * Deep domain object instance security, including bit masked permissions in a high performance, security identity agnostic manner (which is also persistence layer independent). * Dynamic generation of a login form if one is not provided by the user, plus the ability to easily use a choice of login controllers for username/password based authentication. * A choice between basic, digest, form, X.509, JA-SIG CAS, container managed, JAAS, JDBC, XML, LDAP, properties file, SiteMinder, OpenID, and NTLM authentication subsystems (Seam appears to only support basic, digest, form and JAAS from what I can see in Chapter 14). * Ability to tightly integrate container managed authentication with the security framework, including not only JBoss application server but also Tomcat, Resin, Jetty and WebSphere. * Comprehensive rich client support, including a shipped sample that shows using basic authentication over HTTP. We also support RMI security context propagation, and I demonstrated at JavaOne two weeks ago how to perform GWT authentication using Spring Security. * The ability to perform authorization on your choice of web request URIs, method invocations via AOP Alliance and/or AspectJ, plus web component authorization (for flow, state and transition events). * RESTful authorization of web requests, including distinguishing between HTTP methods and permitting a choice of URI pattern formats. * Completely decoupled method authorization backends, including - in the case of method authorization - instance-specific protection via XML, JSR-250 annotations, @Secured annotation, AspectJ pointcut metadata application, or your own ObjectDefinitionSource (which people use, for example, to source authorization details from the database at runtime). * Hierarchical roles, which is very helpful for minimizing the number of roles used or decoupling application roles from authentication roles. * User management API, including first-class support for groups (against both JDBC and LDAP authentication repositories). * Not requiring people to write rules or EL expressions to perform authorization logic. Most Java programmers prefer to program in Java, and Spring Security supports Java as a first-class citizen - simply implement AccessDecisionVoter and you're done. Naturally you can use Java to delegate to a rules engine or EL parser if you prefer, and there are public examples of people having done this using Spring Security. * Complete integration testing support. We go beyond simply switching off security during integration tests. You can test to confirm your security configuration is correct. * Comprehensive integration with WSS (Web Services Security), via our specialist web services framework, Spring Web Services. * Comprehensive tooling integration, including both Spring IDE and the SpringSource Tool Suite. The latter includes task-focused tutorials which cover security, plus integration with our knowledge base (which includes articles on security). You can even use SpringSource Tool Suite for personal use at no charge. * Spring Security has a five year history (first circulated to the Spring Community in 2003), underscoring its flexibility and maturity. Our JIRA issue tracker currently contains some 838 issues, of which 7% are open. By contrast, Seam's security module contains 24 open issues out of 104 total, so 23% remain open (even though Spring Security has eight times the number of issues reported and resolved).
Spring modules tend to be more isolated as possible, while in Seam they are strictly coupled.Low-cohesion, tightly-coupled design is not a good thing. The Spring team (and most OO practitioners) prefer high-cohesion, loosely-coupled systems. Despite observing these OO design practices, the Spring team ensures its project portfolio offers very tight integration (as distinct from coupling). To take a simple example, Spring Security fully integrates with Spring Web Flow, Spring Web Services, and Spring IDE. We also move good ideas from one part of the portfolio (eg security's FilterToBeanProxy) into more general framework components (eg Spring Framework AKA core) as the situation warrants. This leads to a much better overall architecture, release schedule, issue resolution and correspondingly strong benefits to the user community. Best regards Ben Alex Principal Software Engineer - SpringSource Lead - Spring Security project
IMHO this result in a better quality of the product/technology.
Hi Alberto, We believe that Spring Faces provides the most complete JSF + Spring integration module available today. I invite you download the Web Flow 2 release, evaluate the "faces" flavor of the Spring Travel reference application, and see for yourself. From your reply, it sounds like you would especially be interested in the flow-managed persistence, unit testing, and URL mapping features. We do take a different approach than Seam does. Our goals are the same, to provide the infrastructure and integration needed to make JSF projects succeed in practice, but our approaches are different. Seam has its own component model that builds on EJB 3.0. We embrace Spring all the way down, including the core component model and the MVC+Web Flow Controller models. Seam seems to generally favor a more traditional "view-driven" approach to using JSF; where views trigger instantiation of Seam components managed in a shared registry, which then handle postback events and delegate navigation responsibilities to a separate NavigationHandler. We favor a "controller-driven" approach where the Controller is in charge, responsible for managing the instance state associated with an application transaction, fully encapsulating view selection, event handling, and view navigation routines in one-place. With this approach, there is simply no need for this @In and @Out magic. Whatever you fancy at the moment, having a compelling Spring + JSF offering is definitely a good thing for the JSF community. It will likely be good for Seam users, too. Keith
-@In and @Out annotation are great and seem to be more powerfull of Spring DINote that Spring 2.5's @Autowired and related annotations are designed to provide equally complete power for your overall injection needs, building on the core Spring 2.0 bean definition model and its scoping capabilities. That said: Seam's @Out is actually about to become a legacy of the past, since the Web Beans specification (to be used as the core component model in Seam 3) dropped @Out completely in favor of Spring-style scoped proxies. So as of the next generation of Seam, only @In will remain - very analogous to Spring 2.5's @Autowired. Juergen
Note that Spring 2.5's @Autowired and related annotations are designed to provide equally complete power for your overall injection needs, building on the core Spring 2.0 bean definition model and its scoping capabilities.Does @Autowired support scoping or EL?
Does @Autowired support scoping or EL?@Autowired supports scoping through resolving against correspondingly scoped target beans. Scoping always happens at the target bean level; @Autowired is simply able to inject any such bean, not requiring specific scoping support itself. There is no direct need for @Autowired to support EL: @Autowired expresses a need for dependency injection and optionally specific hints on what exactly is needed (through the use of qualifiers). EL wouldn't be particularly useful here, since the @Autowired model allows for using the ApplicationContext's full management power in the background - and this latter place is where all the scoping and pointing to specific named attributes happens (which is what EL would be useful for). That said - we will actually have comprehensive EL support throughout the framework in Spring 3.0, however, mainly in the bean definition model and for bean property binding. This will be a successor to Spring's traditional property path navigation capabilities. For the time being, EL integration is provided for JSF usage (accessing any Spring bean by name in a JSF EL / Unified EL expression) and in specific portfolio projects such as Spring Web Flow (in the context of its flow definition model). In general, note that Spring differs from Seam in *how* it addresses specific problems. Just that there is no identical construct doesn't mean that you cannot achieve the same effect in an equally simple way. Spring just sometimes takes a different approach in terms of how and where specific things are typically expressed. FWIW, the upcoming Web Beans specification is actually pretty close to Spring 2.5's approach overall; so I guess it is obvious that Spring's approach isn't inferior by any means. Juergen
I think besides all the technical measures of each framework, one must also consider the level of support and how vibrant the Spring community really is compared to that of Seam. I've met several of the Spring guys and their non-pretentious, personable style carries over to the forums that many of them actively support and contribute to. I can't say the same for the Seam community. This is a very important aspect of leveraging open source -- you want to know there's an open, vibrant community that truly backs the success of the framework they're pitching. With Spring, I feel this is much the case, especially given their JIRA track record as Ben pointed out. Besides that, I have been playing SWF 2 for the last couple of weeks and have been thoroughly impressed with the ease of use and general speed that I have been able to put together JSF applications using a Spring-centric approach -- no more lazy-initialization errors and finally true conversational scope! Moreover, I have been able to easily plug-in with our UI team using the CSS provided and JS libraries that are exposed through their taglibs, and not to mention A4J and RichFaces support. I encourage you to take a look as well. I did find a few gotchas which I blogged about here, but otherwise, it's been mostly smooth sailing. -Lou
I think besides all the technical measures of each framework, one must also consider the level of support and how vibrant the Spring community really is compared to that of Seam. What I can see is that very few posts in their Seam forum remain unanswered. IMHO the support is very good.
Besides that, I have been playing SWF 2 for the last couple of weeks and have been thoroughly impressed with the ease of use and general speed that I have been able to put together JSF applications using a Spring-centric approach -- no more lazy-initialization errors and finally true conversational scope! Moreover, I have been able to easily plug-in with our UI team using the CSS provided and JS libraries that are exposed through their taglibs, and not to mention A4J and RichFaces support.I admit I was wrong: SWF seems very close to Seam in some points and different in others. But what is sure is that it's a strong integration between JSF and Spring. Anyway I gave a look and found it more complicated and less easy then Seem. When I looked at Seem for the first time I was suddenly able to understand much of its basics. This is not the same for SWF (I am speaking about me!). The problem IMHO is the XML: too much xml! Also in Seem you have a components.xml etc...but many times you only need to *declare* the intent of using some aspects, not to *configure* something like in SWF.
I encourage you to take a look as well.
I though JSF is dead. I am surprise that there are still many people using it.