We Keep Coding

Difference between spring mvc and Jersey

Is there any trade off between using Spring mvc and Jersey Rest servlet container ? Jersey follows Jax RS standard. When I learn Spring mvc, more or less looks the same. In some applications I found people use jersey spring servlet. If spring (dispatcher servlet with handler mapping) can do all the work, then what is the need of Jersey here ? Thanks in advance.

Spring MVC is a full Web frontend framework including support for HTML and other templating, plus other features, in addition to the JSON/XML REST features provided by Jersey.
Spring MVC was around first and has its own way of doing things. JAX-RS was defined as a standard for annotation-based REST handlers, and Jersey is an implementation of that standard. (It's very similar to #Autowired and CDI.)
I personally prefer Spring MVC because I build on a Spring stack and can reuse code between my JSON and HTML handlers, but components intended to be deployed as one part of a customer's own system might be more flexible if using JAX-RS.

Personally I think it's just a matter of preference and what perspective you are looking at it from. I would go on to say that when making this consideration, when building different tiers, you can say that there is an extra "REST layer", on top of the other business, persistence, etc. layers. Just like persistence implementations can be swapped out, so can REST implementations.
That being said, though the endpoint/controller/resource classes look similar in implementation, other features (of the REST layer) are implemented completely different. Looking at it from a Spring perspective, I think those comfortable with Spring would choose to keep MVC as the REST implementation, for it's familiarity
Looking at it from a Jersey perspective, this is where I think most of the integration decision comes in; choosing how to implement the layers below the REST layer. For that Spring would be a viable choice, as it has a rich eco system. But being a Jersey user, the Jersey framework (for a REST implementation) seems a lot more intuitive, but that is completely bias. To use Spring and Jersey together, you can have a look at Combining Spring project and Jersey
As far as Jersey being a JAX-RS implementation, I don't see it being a deciding factor in choosing the REST implementation, when looking at it from a Spring perspective. I really don't see it being much of a factor at all. In a Java EE environment, sure you can swap out implementations with little hassle, but when Spring integration is involved, it's not that easy, as there are integration modules and configurations involved in integrating each different JAX-RS implementations with Spring.

Spring MVC and templating engine like Facelets

Is there a real alternative to JSP tags when using Spring MVC?
I'm using Spring MVC to integrate it to a JS framework.
What i'm missing in Spring MVC is a kind of templating framework
I have previously used Facelets templating with JSF2 and I love it.
Is there a framework/technology that integrates well with Spring MVC and offers similar features as Facelets?
no (or little) xml configuration
can define sections in one template file and fill all supply content for all sections from one file
I was looking at Apache Tiles documentation and it seems that you need to have separate files for each section in template.
Example (pseudocode) :
template.html:
<insert:headerSection>
<insert:bodySection>
using-template.html:
<use-template: template.html>
<define:headerSection>this is a header</define:headerSection>
<define:bodySection>this is a body</define:bodySection>
I know that I can achieve this using JSP but code looks much cleaner and faster to write using Facelets.
If JSP is my best choice I found some suggestions in this thread

I think Spring Webflow has JSF 2 support. If you want to stick with pure Spring MVC, it also offers templating with Tiles and Velocity, or you can even write your own custom ViewResolver.

After some testing with Tiles I decided to go with JSP.
I needs no configuration and I achieved the above functionality writing a simple tag file and using <jsp:attribute/> and <jsp:invoke/> tags.

What about freemarker or velocity, there's a clear explanation about how to integrate those technologies with Spring MVC. Take a look at the following: http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/view.html

It is possible to configure Facelets with Spring MVC. Check it out here: https://github.com/acichon89/springmvcfacelets

I consider that frameworks to make templating are getting deprecated. In this regard, you could think about exposing a Restful API, so that you can separate back-end from front-end technologies. This way you can use the benefits of Spring-MVC in back-end and letting the Front-end to decide the technology to build user interfaces (AngularJS).
Spring-MVC supports the build of Restful controllers, you just need to mark your classes as #RestController.

Architectural Differences in Java MVC Web Frameworks

I'm trying to choose an AJAX-friendly Java framework for my first web application and am interested in first
understanding the architectural differences between the different flavors that are out there.
I like the concept of MVC frameworks, and so am primarily considering the following:
Any JSF variety (ICEFaces, RichFaces, PrimeFaces, etc.)
Spring Web Flow
ZK
Wicket
I've downloaded each of these projects and tried to follow their samples/tutorials, and there is
so much information to ingest I figured I'd take a breather and come here to cover some preliminaries
first.
I'm interested in how each of these frameworks implements the MVC pattern. Obviously, something rooted
in JSF (like ICEFaces) is going to have a different architecture than Spring. I'm sure that this is a
huge question, so I'm not looking for a full-blown tutorial on each of these frameworks; I'm just
curious as to what sort of artifacts (Java sources, XML config files, etc.) a developer has to write in
order to build a single AJAX-driven page using these. I'm interested in the differences to their approach,
nothing more.
For instance, I would imagine that each framework at some point uses a FrontController (or its likes) to
map HttpRequests to the right Controller implementation. That Controller (bean) would then need to do
some processing, possibly hit the database for some information (using ormapping and forming the Model), and
then construct a View/HttpResponse to send back to the client. This is an oversimplification I'm sure, but
there has to be an easy way to explain the high-level architecture for how each of these frameworks accomplishes
that.

Struts uses the ActionServlet (with Struts2 now its just Action) as the controller and model and jsp is the view.
For Spring MVC is achieved by DispatcherServlet which does the routing and Model is not bound to any framework related object you can use any.
JSF - UI jsp or jsf itself, Model - ManagedBean, Controller - FacesServlet.
I did some similar search for my own project a while ago, have a look at the links below:
Comparison based on multiple parameters : http://static.raibledesigns.com/repository/presentations/ComparingJavaWebFrameworks.pdf
Difference between JSF and Struts
http://struts.apache.org/2.0.14/docs/what-are-the-fundamental-differences-between-struts-and-jsf.html
Somewhat related post
https://stackoverflow.com/questions/7633583/which-mvc-is-better-spring-or-struts
Spring and JSF
http://blog.springsource.org/2007/04/21/what-spring-web-flow-offers-jsf-developers/
Spring MVC : http://static.springsource.org/spring/docs/2.0.x/reference/mvc.html
Best Fit For JSF Component Library: Primefaces based on my own experience
From IBM Clearing the FUD : http://www.ibm.com/developerworks/library/j-jsf1/
Hope this gives you some insight.

Have a look at Matt Raible's talk on Comparing JVM Web Frameworks here. You can also consider looking at Spring MVC and 'Tapestry`.
Also, this link gives you a matrix on capabilities of various java web frameworks.

You should also check out the Play framework. I have used it a little and really like it.
It is very easy to get started with minimal configuration (reminds me of Rails).
http://www.playframework.org/

why do we always put Hibernate, Spring and Strut in one app?

Definitely, I'm talking about working with MVC pattern.
Definitely, Hibernate make our life easier with Model layer.
But, Spring and Strut both work with Controller and View.
So, my question is: "I cant understand why other guy always put both Spring & Strut in one application while we need just one of them (Strut or Spring). If anyone understand that, please tell me, thanks!"
I'm just a kid in Java world, so any comments are appreciated.

But, Spring and Strut both work with Controller and View.
Spring is many things, as you can see in this diagram:
One of these things is the Spring MVC framework. I agree, it does not (usually) make sense to use Spring MVC together with Struts (although in large sites, different departments may have different requirements).
However, Spring is also many other things, most of all an IOC framework, and as such it makes perfect sense to integrate different model and view technologies.

Spring is both Spring - the IOC container and Spring MVC - the web action framework. Struts is only a web action framework. So if you prefer Struts over Spring MVC, but also want an IOC container, you will use Struts with Spring.
Additionally, Spring also provides declarative transaction management, a security framework, a set of JDBC helper classes, etc., that you might want to use in a Struts/Hibernate application.

I wouldn't say always. Personally, I have never put Spring and Struts together in the same application, and I am willing to bet that most Spring/Hibernate projects also do not also use Struts.

Spring isn't just MVC. It has much more integrations, such as database, security, DI etc. Usually you want to use one of that features if you use Spring (which doesn't also mean, that you have to use Spring MVC).

Lets say that Spring and Struts are both frameworks that do overlap in some aspects. Even if I think that, if you are utilizing spring to its full extent, there should be no need for struts at all. But people tend to stick with the stuff they are used to. As Struts has been around for quite some time there are a lot of applications based on this and a lot of people that have made a profession out of this and would never commit throwing that away. That's why I have seen quite a lot of these hybrid application around.

I think you misunderstand MVC Pattern in first place. Model is not about persistence, but about the business logic in first place. It usually involves some persistences and service classes. For this purpose, many people choose Hibernate for persistence and Spring IoC for dependency injection purpose.
For the View and Controller part of web application, a well known web mvc framework is Struts and Spring MVC. Spring itself is consists of many components, Spring IoC and Spring MVC is two of them. Spring MVC is an equivalent with Struts so you don't use them together. But it is ok to combine Struts and Spring IoC.

Struts - usually provides MVC framework (most of Production support & maintenance applications are already integrated with it).
Spring - to inject/ add new componenets without disturbing the existing java classes/ code.

IT mostly depends on your project requirement, in our project we have used JQuery there are lots of Struts tags are used at the UI Layer and that is the main reason we are using struts2 because struts2 is having very good integration with JQuery
Struts2-JQuery Tag Library is very useful hence we are using Struts2
+
Spring framework provides an easy way to manage the dependency. (because of its DI and IoC)
It can be easily integrated with struts 2 framework.
The ContextLoaderListener class is used to communicate spring application with struts 2.

Understanding Java Web development and separating logical tiers

When developing Java EE applications how do I separate Business Logic so it can be reused?
I inherited an application that is mostly Model 1. Business logic is located in JSPs, Servlets and DAO code.
I want to separate the business logic but I am confused by all of the frameworks etc. that exist.
I am looking into Hibernate with JPA to handle all database persistence. Currently all SQL is hand coded and separate SQL is used for different RDBMS. My DAOs will call the code necessary for persistence.
I am thinking of using Struts for my web layer. The part I don't understand is the Business Logic.
I don't want my logic tied to the Web Layer because I want to reuse the logic in a Java SE application.
I thought about putting business logic in Entity classes but that seems like a bad idea.
Is there some technology or pattern that can be used as a guideline for creating reusable business logic?
If I am not clear I will edit.
Thank you.

To separate your frontend code (the view) from your business logic (controller) and your data (model) you can follow the MVC pattern.
You can have your controllers access other classes that contain the reusable business logic that will be used within your Java SE applications.
There are a lot of frameworks that help you to build web applications in this style like Grails (uses Groovy), Play or Roo. But because you said 'enterprise' you should have a look at the Spring framework and its MVC module. Spring offers good integration with Hibernate and allows you to follow the MVC pattern with your web applications.

I would say take it piece-meal. Solve the biggest problems first, which is in your case having business logic in the jsp pages. You can accomplish this using any web MVC framework of your choice (Struts, Spring MVC, Grails are all good. Pick one that you are most comfortable with).
The next problem is organizing your business logic in a separate Model layer that your controllers can invoke. Spring is a good DI framework for organizing and bootstrapping your application. Also, Spring supports a number of web MVC frameworks including Struts, JSF etc.
The last problem is your Dao layer. You mentioned you want to use Hibernate/JPA. I dont know how familiar you are with Hibernate, but make sure that you are trying to solve an actual problem by switching to Hibernate (since switching to Hibernate usually comes at a significant cost and headaches).