We Keep Coding

Is it better to use spring mvc with hibernate?

I am going to develop small ERP System. The product has only one major requirement to support multiple databases.
I have planned to use
Front side: JSP+JSTL+JQuery [I have good command on that] + I have create my own custom component for re-useability and full control of my component.
Back-end: Using hibernate[ORM] framework [due to Cross database] and I have also good knowledge of it.
I am happy with above and feeling confident to build product, soon.
BUT
My friend made me unhappy ;)
My friend suggest me that you should use spring MVC with hibernate, because when your product become large,it create a problem in future due to many developers involvement.So, you should use framework , so that every developer follow the pattern and then your product remain stable.
But I am already follow hibernate pattern :)
I have no any knowledge of Spring MVC. When I search about spring MVC , I found it is a different thing than my requirement and also find Cross database context issue, if I use Spring MVC with hibernate.
Either should I used spring MVC or not. If yes, I have to learn then Spring MVC and
I do not want to waste my time, if spring is not suitable for me.
That's why I am consulting that forum , to go for right direction.

Actually, Spring MVC does not interfere with any of the components you have chosen already. It just introduces a way to structure your frontend - backend interface in a standard way (MVC pattern).
I actually run the very same setup and is very happy with it. (Jquery, JSP, Spring MVC, Hibernate).
Other than structure, you will get easy return of invested time in Spring MVC when you want to do Ajax heavy things (as I assume you want in an ERP app). It's trivial to build AJAX/JSON stuff with jQuery and SpringMVC.

Using Spring MVC will make your application structured. This will help in future maintenance.
Your code will look clean and you can separate your code into components and Spring will help you wire them together and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different settings or environments. This would be great for multiple databases when used with hibernate.
Learning spring will not take much time if you have a good knowledge of Java EE.

Spring MVC Struts Mixing

This is really a general question.
I have an ecommerce webapp that I built solo about 4 years ago. At the time, I made the decision to use Struts as my mvc framework. As years passed working on other projects, I came to appreciate and feel much more comfortable with the feature set and flexibility offered by Spring MVC.
The service layer is solid, and is built using the spring framework.
I'd like to refactor my current web layer to now use Spring MVC. But as I have mentioned previously, I wrote the app solo and it's more of a side project. The point being that I do not have time, nor do I want to risk throwing away and completely reengineering the web layer from scratch.
So I'm asking the community on what their strategy would be for this refactoring effort?
Ideally, I would like to tackle pieces at a time, and ultimately mix the two technologies until eventually when I can completely turn off Struts.
All new functionality for my site would best be developed in Spring MVC.
The good thing is that my existing views, which is currently using apache tiles, would not have to change much, with the exception of removing struts tag libraries and replacing them with Spring MVC.
One requirement I'd like to keep is that the URL's should not change.
In other words, the ActionServlet and the DispatcherServlet would have to map to separate paths but somehow go to different implementations.
For example, how can I say that mysite.com/show-product maps to a Spring Dispatcher servlet, but mysite.com/show-category maps to a Struts action servlet.
Your thoughts are appreciated.

You can run them both in the same container with appropriate mapping.
I don't understand the question "should I convert action classes to spring controllers one at a time", how else would you do it?
Whether an action class should map to a method of a controller has more to do with your existing app's organization than anything else, or at least how you want the Spring app organized.

No, you don't need to rewrite your actions. See here:
http://docs.spring.io/spring/docs/3.1.x/spring-framework-reference/html/web-integration.html
Look for "18.4 Apache Struts 1.x and 2.x"

What web frameworks can be used successfully on Google app engine? What about Struts/Spring?

I'm interested in porting an existing application which was written using Spring/Struts2/Hibernate to GAE. I didn't read many successful stories about that so first of all I'm wondering if it is wise to use any of them there. I want to get rid of hibernate and to use the google data store instead since it's obvious hibernate is not a good choice on GAE. So my main questions refers to Struts2(webworks)/Spring. My app uses simple JSP pages, no other template mechanism.
My question refers to the following aspects:
Currently each page has struts actions associated. Each request is taken by struts dispatcher an then it is dispatched to specific action class after which it invokes a specific jsp, according to the config file.
Everything is instantiated by Spring(actions, factories, hibernate layers,...)
The security is managed through a Spring Security(former acegi).
My first impression is that I should get rid of Spring because GAE should manage all the objects in order to work in a distributed environment. I have a few antagonistic thoughts regarding Struts. However, if I get rid of them ,I'm not sure if I should do it and in case I will, what to choose instead. Is GAE good enough to provide all the things I needed? I assume instantiation should be handled by GAE to have a truly sclalable solution. What about session management, security & user privileges? GAE provides good mechanism to manage them behind the scene or I should manually handle them like in a classic jsp solution? Will I end in having a huge web.xml?
Are there any frameworks that fits well in GAE and which can replace Spring/Struts? I would be interested to find out from someone who experienced those problems in GAE.

Here is a list of frameworks which are known to work or to have issues:
http://code.google.com/p/googleappengine/wiki/WillItPlayInJava
In general Hibernate will not work, but you could potentially use Java Persistence instead. Struts should be OK, but Spring Security is not fully compatible while other Spring parts are fine.

As far as I know, Struts is generally a layer over standard Servlet API - so it should be running without many changes. Spring also is not a problem, in fact, on the web there are many blog entries about spring on GAE. Hibernate - yeah, better use JPA.
If you want to rewrite whole app, you can always go with GWT, even with Spring ( GWT/GAE Spring IoC powered )

Best view layer with simple URLs for an EJB3 application

I would like to get your input on what would be the most fitting view layer for EJB 3.0 [1] Java application for me.
JSF is no good because it is a mess when it comes to web URIs. I would like a view framework which would help with automating html form submission and validation while using clean URIs like example.com/story/1 or example.com/?story=1 (using GET method).
My first guess was to go with Spring MVC. Spring is great but it feels like an overkill since JPA plus EJB already does the heavy lifting. I only need couple of things, well, four of them actually:
JPA, EJB 3.0 for business layer
Clean URIs: example.com/story/1 preferably
HTML form helpers (validation, converters, etc)
Templating similar to Apache Tiles or JSF's ui:composition
So, which one would you pick?
Ad [1]: It's used mainly for JPA and stateless/stateful local session beans

My first guess was to go with Spring MVC. Spring is great but it feels like an overkill since JPA plus EJB already does the heavy lifting.
I disagree with this statement. Spring need not be an "all or none" proposition. I see nothing wrong with using Spring web MVC if that's all you need.
I'd put your EJBs and JPA behind Spring service interfaces and let the web tier deal with those, using the usual Spring idiom.

Apache Wicket supports RESTful URL:s out of the box using a combination of BookmarkablePageLinks and PageParameters constructor of the WebPage object. Wicket does also support Velocity templates and since it's entirely OO/POJO based it's easy to maintain in general.
Wicket fits into the Model and View parts of the MVC Model 2 and contains some samples of generic validators and specified form validators and as such it has sufficient mechanisms for supporting such features.

What Are the Benefits of Struts

I recently added Struts 1.3 to my application on Tomcat. Here are my observations,
MVC. Servlet/JSP does this fine for me, where JSP is the view and servlet is the controller. I don't see any benefit to get the mapping from an XML file since our mapping is very static.
Action Form. I can see some benefits of action form but not huge.
Tags. I already uses JSTL and don't see any advantage using Struts tags.
So I am thinking about removing Struts. Anyone can think of any other benefits I might have missed?

Personally I myself prefer jsp/servlet but theoretically Struts has some advantages.
Here are some of the advantages i know of, you might have mentioned them already, but i thought it would be better if i list all of them here.
Centralized File-Based Configuration.
Struts values/mapping are represented in XML or property files. This loose coupling means that many changes can be made without modifying or recompiling Java code, and that wholesale changes can be made by editing a single file. This approach also lets Java and Web developers focus on their specific tasks (implementing business logic, presenting certain values to clients, etc.) without needing to know about the overall system layout.
Form Beans.
Bean Tags.
Struts provides a set of custom JSP tags that let you easily output the properties of JavaBeans components.
HTML Tags.
Struts provides a set of custom JSP tags to create HTML forms that are associated with JavaBeans components. This bean/form association serves two useful purposes:
It lets you get initial form-field values from Java objects.
It lets you redisplay forms with some or all previously entered values intact.
Form Field Validation.
Struts has a robust, extensible validator that can be used to uniformly validate your form fields. This validation can be performed on the server (in Java), or both on the server and on the client (in JavaScript).
"Plumbing code" contained within the Struts framework.
Mapping HTTP request parameters to Java objects is handled by Struts, for example. You don't have to do it. This allows you to focus more on the domain problem instead of building infrastructure.
Good documentation & plenty of books.
If you have to leave the project and/or someone else has to maintain it then using a well known and well documented framework will make that job much easier. A homebrewed framework just can't match that.
Broad user testing.
Since Struts is used in plenty web-apps the framework will get looked at by many more eyes than anything you could write alone. Usually, but not always, that means any problems you have will have been seen by someone else (and hopefully resolved) first.

Large knowledge base.
I agree that this perhaps isn't as valid as it used to be but Struts has been used in a lot of projects over the years. From a maintainability point of view using a well known framework makes it easier for other people to work on your application and also help build your own resumé for the future. Right now most development is either in the component based space (like JSF, wicket, tapestry) or in the rails-like space (like rails, grails, lift) but the struts arcitechture is still in use and valid.
You didn't say if you develop in a corporate environment or not, for a personal project perhaps the maintainability issue isn't that much of a problem.
If you decide that struts suits you well you could also have a look at stripes, a struts-like framework that's based on the same concepts but is less verbose when it comes to configuration with more sensible defaults, less xml and support for annotations.

I totally agree with your points about Struts - personally I think its time has come and gone.
I went off Struts in v1 (which I believe is nothing like the latest versions) because the form beans where just added boilerplate code to write.
Since then most applications I've worked on are using Spring as the dependency injection framework, which has made Spring MVC the natural choice - it's simple, straight forward and minimal.

Not just for Struts. But some points to consider for using a framework:
Standarization.
Specialized IDE or plugins for your favourite IDE.
Portability. For example, someone can develope a portlet for integrate your existing struts application in a portal server.
Internationalization.
The most important for me:
You dont have to worry about the issues on the struts code, just upgrade.
You can focus your work in business logic.

Struts is Open Source--
Large Community----
Number of Books available-----
Proven FrameWork----
Popular framework-----
Available since 2001----
+----
the features mentioned above...........
but when u r using struts,the better choice is struts2.

I think your feeling about removing Struts is a sound and understandable reaction. Struts just doesn't seem to do very much for an application.