Spring mvc is a framework that has been long time out there, it is well documented and proven technology. A lot of web sites are using spring.
Seam is a framework based on jsf - rich faces implementation.
It has a lot of ajax based components.
It uses some heavy stuff like EJB, JPA.
All of this is prone to errors and this framework is so slow (at my computer it is almost impossible do develop something because it is really slow, especially redeploying on jboss)
But is is very good for back office applications.
Does someone have a professional experience with this two frameworks?
Can you recommend the better one ?
Why?
Regards
I use both: Spring-MVC (2.5) and Seam
Because Seam uses Java Server Faces Technology (A server-side based Technology), behind the scenes, It is better designed for small and medium applications. (Each JSF view Tree is stored on Session - You can store on client side, but be aware bandwidth issues). But it has some advantages:
Typically web application uses the following path
view >> controller >> service >> domain
With Seam, you can get
view >> service >> domain
Or even (by using mediator pattern provided by Seam Framework)
No controller, No service
view >> domain
Besides that,
JSF 2 supports JSR 303 - Bean Validation
You can use Wicket instead of JSF if you want
Conversation and Business process management support
Use can use Spring DI if you want
Spring-MVC
It has a powerful web-Tier infrastructure
Handler Mapping (It chooses which Controller should handle the request)
View resolver (It chooses which View should render the response)
It can be used for large applications
Powerful data-binding
Spring 3.0 supports Annotation-based Controller (JSR 303 - Bean Validation, coming soon)
But i still not use Spring 3.0 because
By using (and extending when needed) MultiActionController, i can get convention over configuration without no xml settings to define your Controller (You just need to set up your MultiActionController as #Component)
SimpleFormController provides similar behavior found in Spring 3.0 annotation based controller
...
About The learning path, i think both are similar.
I have worked professionally with Seam and it is a killer framework. It really boosts up your productivity. You can use POJOs instead of EJBs, if you think EJBs are slowing you down. About the deployment, just consider deploying to Tomcat instead of JBoss. On my machine redeployment in Tomcat is done in a couple of seconds. But I still haven't used Spring MVC to compare them.
We have been using Seam for a very large site using POJOS and communicated with web services or Hibernate deployed on Tomcat. We have found that the back button support does not work well or is prone to being specific to implementation patterns. Additionally, there is a tendency for sessions to grow very large if using server side state. Attempts to reduce the session size impact back button support or iframe usage due to reduce number of view states stored in session. More or less, our issue have all been performance related. The tomcat requires more memory and supports less users when compared to a struts 1.2 or spring mvc. We are using around 50 tomcats to support our userbase.
I have used both SEAM and Spring MVC for a few months.
I prefer Spring MVC to SEAM. BTW I noticed JBoss halted the SEAM3 development.
I found a interesting article about comparison of SEAM and Spring MVC.
The link is
http://java.dzone.com/articles/why-java-ee-lost-and-spring?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+%28Javalobby+%2F+Java+Zone%29&utm_content=Google+Reader
Thanks
I have used both Seam 3 and Spring 3 frameworks.While Seam 3 is easier to code and has a lot of features supporting session management and transaction management ,the performance is slow.Spring is much faster.
Related
I have a Struts 1 application and I am exploring different options for upgrading the system. One option is Spring MVC or Spring Boot. If I were to choose either framework to migrate the application to, can I do so transitionally (piece by piece) or would it be a complete wholesale change or complete rewrite. Don't know if I'm making myself understood.
Spring 3.0, had explicit support for integrating struts 1. This was two major versions of spring and 9 years ago. There is documentation here:
https://docs.spring.io/spring/docs/3.0.5.RELEASE/reference/web-integration.html#struts
Integration consisted in either using the ContextLoaderPlugin to allow spring to manage all your action classes, or to make your action classes aware of the spring context. A fair amount of struts specific code was available to do things like map struts action handlers to action beans in the spring context.
You could probably reproduce a lot of this in spring 5, but you'd have to do a lot of heavy lifting on your own. There are probably very few struts/spring 5 users out there to help you.
You could also go with spring 3.0 to make the integration easier, allowing you to do the migration in steps, but then you are in a different bad place. You have an old version of spring that fewer people use, and none of the goodness that 9 years of releases have wrought.
If you want to migrate your struts 1 app to spring, you are probably going to have to do it all at once. Redo your action classes as springmvc controllers and then rewrite your views (templates). spring mvc is pretty view agnostic and there are many good choices.
Good luck and have fun!
I am learning Java EE and wanna build up a complete management system for a restaurant. Now I am confused what presentation layer should I use for my RMS because I heard that the struts 2 is one of the best UI layer but, the thing is, if I am using spring for my business logic layer then I can use the spring MVC can't I? By the way, I am really interested to build a complete application which is follow the multi-tier architecture.
Yes, of course you can use Spring MVC.
You can use Struts 2 if you'd like as well, because Spring integrates with it nicely.
But I don't see any reason why you'd want to do that. The person who told you that Struts 2 is
one of the best UI layer [sic]
is misguided. If you compare it to Spring MVC, you'll see that the two are based on similar ideas, but Spring improves on Struts. JSF has superceded Struts as the default Java EE web view technology, so it's not even considered "best" by the Java EE standard.
Stick with Spring. You won't be sorry.
I will not blame struts 2, indeed it's a great product, I work with it every day. But in my experience spring MVC is a lot simpler and clearer. This doesn't mean you don't get as much features.
Try both, and you'll see what I mean.
Tell us which one you choose!
I am doing some research for some social network project which i am going to start. I used Spring before yet i cant make a decision at the moment since there are way too many options to choose.
I would like to use JSF2.0 components on my views , and as far as i figure out webflow is a nice way of doing it yet it is not a must.
What benefits does webflow give over Spring web mvc ? My first impression about WF is it makes things way too complicated.
Thanks in advance
Webflow is about flows in web application.
Think of a Wizzard with several Pages, then Web Flow helps you to connect this Pages (in a flow), and provides a variable scope to connect variable with this flow.
While Spring MVC is "only" about isolated Pages.
I've been reading/learning more about Spring lately, and how one would use Spring in combination with other open-source tools like Tomcat and Hibernate. I'm evaluating whether or not Spring MVC could be a possible replacement technology for the project I work on, which uses WebLogic and a LOT of custom-rolled Java EE code. The thing is, I've always suspected that our solution is over-engineered and WAY more complex than it needs to be. Amazingly, it's 2009, and yet, we're writing our own transaction-handling and thread-pooling classes. And it's not like we're Amazon, eBay, or Google, if you know what I mean. Thus, I'm investigating a "simpler is better" option.
So here's my question: I'd like to hear opinions on how you make the decision that a full-blown Java EE application server is necessary, or not. How do you "measure" the size/load/demand on a Java EE app? Number of concurrent users? Total daily transactions? How "heavy" does an app need to get before you throw up your hands in surrender and say, "OK, Tomcat just isn't cutting it, we need JBoss/WebLogic/WebSphere"?
I don't think that the decision to use a full-fledged Java EE server or not should be based on number of users or transactions. Rather it should be based on whether you need the functionality.
In my current project we're actually moving away from JBoss to vanilla Tomcat because we realized we weren't using any of the Java EE functionality beyond basic servlets anyway. We are, however, using Spring. Between Spring's basic object management, transaction handling and JDBC capabilities, we aren't seeing a compelling need for EJB. We currently use Struts 2 rather than Spring's MVC, but I've heard great things about that. At any rate, Spring integrates well with a number of Java web frameworks.
Spring does not attempt to replace certain advanced parts of the JavaEE spec, such as JMS and JTA. Instead, it builds on those, making them consistent with the "Spring way", and generally making them easier to use.
If your application requires the power of the likes of JMS and JTA, then you can easily use them via Spring. Not a problem with that.
Google open sources a lot of their code. If you're writing low-level things yourself, instead of implementing code that's already written, you're often overthinking the problem.
Back to the actual question, Walmart.com, etrade.com, The Weather Channel and quite a few others just use Tomcat. Marketing and sales guys from IBM would have you believe different, perhaps, but there's no upper limit on Tomcat.
Except for EJB, I'm not sure what Tomcat is missing, and I'm not a fan of EJB.
What tomcat does not offer apart from the more exotic elements of Java EE is session beans (aka EJBs). Session beans allow you to isolate your processing efficiently. So you could have one box for the front end, another for the session beans (business logic) and another for the database.
You would want to do this for at least 2 reasons:
Performance; You're finding that one box to handle everything is loading the box too much. Separating the different layers onto different boxes would allow you to scale out. Session beans are also able to load balance at a more fine grained level. Tomcat and other web services of that ilk don't have clustering out of the box.
Flexibility; Now that you've moved your business logic into its own environment you could develop an alternate front end which used the same layer, but say, was a thick client front end for example. Or maybe other contexts would like to make use of the session beans.
Though I should probably point out that if you use web services to communicate with that middle tier, it could also be on tomcat!
The only reason to use a full blown Java EE server is if you need distributed XA transactions, if you don't need XA transactions then you can use Spring + JPA + Tomcat + Bean Validation + JSTL + EL + JSP + Java Mail.
Also a Java EE server is supposed to implement JMS but it does not make sense to run the JMS server in the same VM as the rest of the app server so if you need JMS you should have a separate JMS server.
I strongly disagree with all answers given here.
Everything can be added to Tomcat, including EJB, CDI, JTA, Bean Validation, JAX-RS, etc.
The question is: do you want this? Do you want to assemble all those dependencies in the right versions and test that it all works together, when others have already done this?
Let's be clear: nobody uses only Tomcat! Everyone always adds a web framework, an ioc container, an orm, a transaction manager, web services, etc etc
Lightweight Java EE servers like TomEE already include all of that and makes the full stack experience of having all those things integrated so much better.
Maybe this can be of interest:
http://onjava.com/onjava/2006/02/08/j2ee-without-application-server.html
HTH
What are the advantages/disadvantages of Seam over Spring? Why would I use Seam in lieu of Spring?
Is there anything that can be done in Seam that can't be done in Spring? Anything in Spring that can't be done in Seam?
What about stateful/stateless architecture? I am a Spring user, so I am biased, naturally.
Why Spring?
Cleaner code
Streamlined application configuration
Nice integration with popular open source products
First class AOP support
Enterprise-scale security: Acegi
Highly flexible MVC
Abstracted data access (JDBC is OK)
Enterprise Java without EJB
Testing is easy
Why Seam?
Merge Java EE 5 standards (EJB 3.0, JPA, JSF, Annotation) seamlessly
Stateful by design
Bijection
Integrated Ajax (ICEfaces and Ajax4JSF)
Business process integration (jBPM)
Business rules integration (Drools)
Workspace management
Deliver complete stack (from JBoss & RedHat)
Seam Text and EL enhancements
Probably will be a standard (JSR-299: Web Beans)
From Framework Deathmatch: Spring vs Seam. Thomas Wiradikusuma (Spring). Joshua Jackson (Seam). Java User Group Indonesia. JaMU 07.03. March 17, 2007 power point presentation here
although seam does have many advantages over spring, there is a magic word that really is worth paying attention to and this is PERFORMANCE!!! if you are not worried about performance issues I would go with seam. From the other hand if you want your application to be as fast as possible and your hardware is limited I would use spring. I am not saying that you can not develop fast applications with seam, but in order to do this you really need to know what you are doing. I have used both of them (i am not a guru in any of them) and what I found out is that although spring needs more effort to build what you want, at the end the result is more flexible and is performing better. I do not think that there is something that can be done in one framework that it can not be done in the other, saying that, remember that I am not an expert to any of those.
Seam will give you a pretty, ah, seamless, integration between the components that make up the seam stack. All very nice as long you keep within that stack, and within the seam model and foing things. It all starts to look a little less convincing as soon as you start doing something unusual, though.
If it's not too much of a generalisation, Seam is very "microsofty" in that regard. This isn't a bad thing, it's just a stylistic thing. Spring is more open-ended and takes more effort to get going, but it's ultimately more flexible, and a lot more open.
You can use Spring and Seam together - Spring for backend components, Seam for enhancement of web layer (JSF/GWT/Wicket) and other stuff. Seam offers a lot of Spring functionality (i.e. IoC container, transaction managment) - in your project you can decide - witch implementation to use.
More details on integrating Seam with Spring - "Seam in Action - free bonus chapter"
Let's compare the two.
What is common?
Both are open source, follow MVC architecture and has a servlet based front controller.
Advantages of Spring MVC
Extension of Struts.
View can be developed using JSP and HTML. You can also plugin other's like PHP or velocity.
Has large number of controllers predefined.
Integrated out of the box with Spring framework.
Advantages of Seam
Extension of JSF
View can be developed using JSF component library. There are large number of vendors to choose from.
Integrates JPA entities with Web layer
Annotation based validation
Integrates with EJB 3.0
Out the box jBPM support which provides process flow definitions.
Integrates with Drools where you can define web layer business rules.
Good community support.
Conclusion
Since Seam is built on JSF, it has large number of UI Component libraries to pick from. It reuses Java EE stack better. It has lot of interesting modules integrated beforehand.
Spring MVC is built on top of Struts and Spring, so it will reuse Spring framework stack far better than others. But the view is built using JSP, so we have to rely on JSP tag library vendors to build rich components.
Seam framework would be a better choice as Spring framework is anyway extensible enough to be leveraged by Seam.