I would like to modernize my Struts 1.x application. There are quite a number of articles which advocate migration of codes, instead of rewriting the entire system.
I would like to seek the advice of someone who has successfully modernize legacy applications.
My current system is using struts 1.x and JDBC prepared statements as the data access layer.
I am looking forward to improve the legacy application with the following objectives:
Web Pages should be coded with Responsive Web Design in mind.
Replace struts 1.x with Spring MVC
I am looking to breaking up the modernization into the following phases:
Phase 1 - Change all jsp pages to HTML 5 and CSS 3
Phase 2 - Change all DAO classes to Spring JDBC Template or Spring JPA
and transactions managed by Spring
Phase 3 - Ultimately, replace Struts 1.x Action Forms, Actions with Spring MVC
Before I start the changes, I would like to find out if it is possible for:
Struts 1.x with HTML 5 and CSS 3? I am looking at replacing all struts 1.x html taglibs with HTML 5 and JSTL/EL.
Running Struts 1.x with Spring 3/4? Is it possible to run non-spring managed pojo with Spring beans?
What should I take note of and how/what are the best practices to handle this modernization process? The code base is about 500k of HTML/JSP codes and 3 million Java codes.
It's been a while since I last worked with Struts 1.x, but I see no problem replacing at least most of the Struts tags with JSTL/EL. You should be able to paint HTML5 with Struts 1.x JSPs. I remember working using little or no Struts tags, only JSTL/EL, but this was before HTML5.
You can invoke Spring Context from any Struts ActionForm or, essentially any class within your webapp. You'll probably have to do it manually though and not with annotations, something like this:
WebApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext());
With all this said, I can see you're intending to do a serious update of your app, therefore I must ask, are you positive about keeping Struts 1.x? If you want to ditch Struts tags, use Spring 3/4 and HTML 5, why not dispense with Struts entirely and migrate your app to Spring MVC? It's very easy to use, powerful and, needless to say, it integrates perfectly with the Spring components implementing your business logic, persistence, etc.
Cheers.
(Not an answer, informational.)
There's no reason you can't have an S1 app running alongside Spring MVC. It's a reasonable way to migrate piece-by-piece instead of a longer project that does a complete replacement.
Older Spring has direct support for Struts 1. Depending on your timeframe I might consider using the older Spring until you're further along.
Replacing S1 tags with pure HTML/CSS will be a pain because the S1 tags render other stuff besides just the input fields (e.g., labels, error messages, etc.) It's totally doable, especially if you write your own custom tags.
jQuery v. (AngularJS | React | similar) Switching to a full-on client-side app is a big lift, especially if your back-end isn't already designed that way. I wouldn't do that, but you could get a start on it by putting business logic in its own place and using that from the web layer. Then...
... you start to consume API calls on the client side using jQ or other client-side framework injected into the existing pages. Only then would I start considering going full SPA.
The bottom line is you have a fairly large app. Rather than converting the entire thing I would consider removing functionality from the mainline app and break it up into sub-applications, each of which could use whatever tech stack seems reasonable.
I've done a lot of project like this as a consultant: it's a lot of busywork that requires a wide range of knowledge and skills, and it's difficult to get right.
Related
I am working on migrating a software module from Struts 1.1 to the Spring MVC Framework. After doing some research, one of the first steps is to convert Struts tags to their HTML/JSTL equivalents.
However, I don't have experience with Struts (I just graduated), and my PM's opinion is that I don't need to learn Struts since they are migrating everything away from Struts. The online resources I found is useful in walking me through the migration process, but it doesn't give me a complete table of tag mappings, only a few examples (5-6).
I don't know how to identify Struts tags, much less know what is its Spring-compatible equivalent. I suspect the .jsp files are already in HTML, but I can't say for sure since I won't know a Struts tag when I see one. Is there any resource or reference I can refer to in order to help me in this respect? A list of Struts tags and/or a list for HTML/JSTL. It's best if there's a list of such mappings.
Note that installation/downloading of additional software/libraries etc. is out of the question. The project is on a separate network not connected to the Internet, so I can only use native libraries.
Is it fair to say that the most important justification to use Spring Webflow over Spring MVC is this:
Using Spring MVC, the different stages of the workflow needs to be in code. i.e. If Stage 1 ends in success, in the Controller we need to forward to the jsp for stage 2 and so on. In SPring MVC, we cannot do it in xml file.
But in Spring webflow we can configure the flow in xml file without touching code.
Is this wrong or over simplification? I looked at http://forum.springsource.org/showthread.php?16393-Difference-between-Spring-MVC-Web-Framework-and-Web-Flow and was trying to make a summary of the explanation.
If your application have complex Flow pages, events which need to be defined as Finite state machin then use Webflow. It would be justified to use webflow for website where you buy Insurence, Flight Tickets.
Otherwise use normal MVC framework like Struts, learning curve for webflow can be bit hard than other MVC frameworks.
I would say below point mentioned in post is fully justified.
The main point: webflow is a powerful controller. That's it. Use it when you need its power. use plain old controllers where you don't.
Taken from http://forum.spring.io/forum/spring-projects/web/web-flow/7159-difference-between-spring-mvc-web-framework-and-web-flow
MVC is an implementation of the Model View Controller design pattern, webflow is an implementation of a "web flow" state machine.
Web flow sits on top of springs MVC and allows you to define complex navigational flows.
Quite simply; if you have lots of independent single pages, which don't do much and don't interact, use plain old MVC. If you have a set of pages that represent a workflow, use webflow to model the workflow. If you have both; mix and match
I have to develop an application which takes XML reports stored in File System parse it and put it into database and display the reports by querying the database in various MIME types(XML,JSON,RSS and HTML). So what I have done till now is parsed the XML reports in the file system ,setup schema for database in MongoDB,put data in database using Spring-data and also managed to have a web service which shows rough draft of reports in XML,JSON and RSS feed.Now I want to display the reports in HTML as well and my supervisor suggested me to use Backbone.js to dispaly it in HTML format by calling the web service.Kindly advice me to choose b/w Backbone.js or write another Spring MVC web service which generates reports in HTML.
Thanks in advance
Swaraj
What you are asking are two different things and choosing between them.
You have to know what your overall objective is with the webapp is and what framework is best for it.
Short answer, Spring MVC integrates with Dojo.js right out of the box, which might do what you need to do, but since your supervisor is suggesting otherwise your options are:
Use Spring MVC to construct and display the data in the HTML using what ever render of your choice.
Or
Build out your Spring MVC wepapp API so that you can use a JavaScript MVC framework, such as Backbone.js or one of the many others (see TODOMVC for samples), to interact with your spring controllers.
Option 1 might be easy enough, used in conjunction with JavaScript or jQuery and plugins
Option 2 would be good if your webapp is complex and will be mostly a SPA (single page app) that utilizes a lot of JavaScript and you want a way to organize your js code better. See JavaScript MVC diagram for an example of how it works.
We are in the phase of evaluating some of the frameworks for portlet development. As of now I know of below 3 options. I would like to know your experiences with them and others
Struts 2
Spring Portlet MVC
Liferay 6.x MVC Framework
Please try to share Pros/Cons in following areas along with what you think is important
Speed of development
Maintenance
Ease of development with Geo Distributed teams
Please suggest any other frameworks which can be used as alternative with some pros/cons
From my point of view, using MVCPortlet and JSPs without Spring-mvc or Struts is suitable enough only for a simple portlet. I would definitely try at least a sample portlet to see how it works if developers haven't done portlets.
The only advantage of using Struts is that the Portal itself is heavily using it because spring-portlet-mvc is relatively new. So that you can learn a lot from variety of examples. Otherwise the technology afaik is dying (regarding portlet development) and if you haven't been working with Struts, the better option for you would be go for spring-portlet. I've been using spring-portlet for more than a year, and I must say that I was amazed how well integrated it is into portlet container and what features are implemented there. You can do practically everything as with spring-mvc (servlet spec), except for some minor support that I found redundant anyway.
Speed of development
an experience developer that knows spring-mvc can create a robust application with only a few spring controllers.
Maintenance
The amount of source code is significantly lesser with spring then struts. Spring-portlet has implemented 268 JSR, so that it saves couple of workarounds.
Ease of development with Geo Distributed teams
I sense you are going for something bigger, so that ask developers about their experience with Spring and Struts and make your choice. Anyway, Liferay is a pretty robust portal solution and to "learn" it and find a way to use it properly is more important issue than how to develop portlets.
Also be interested in developers knowledge of Javascript. If they don't know JS much or you don't have front-end developers, I would probably give a shot to Vaadin or GWT portlets. However Liferay has a very good client-side support and you'll see that a lot of things can be done on client-side in Liferay. JSP tag libraries provides a significant amount of dynamic behavior and Alloy JS framework that is built on top of YUI provides you with a nice environment and it is not hard to use.
EDIT: The comparison of Struts vs. Spring is regarding portlet specification, where (my opinion) struts support is an old Volkswagen and spring is Bentley continental gt :-)
ALSO: The key tool for Liferay portlet development is so called ServiceBuilder, which is a code generator, that generates a significant part of your persistence layer, remote service layer based on domain model and metadata. If you choose to use it, your portlet is automatically Spring based. And I'd recommend to use it, because once you try it, you won't let it go. For instance, to create Ajax calls from client-side to remote services is a question of 2 minutes to set it up and be able to call them and even get the return value. Hibernate setup is fully optimized and ready to use after you run servicebuilder. And much, much more.
It's Really depend on your requirements, since liferay MVCPortlet are just simple sub-classes of the javax.portlet.GenericPortlet, i dont think it's a fair comparison between web framework such as Strut 2 or Spring MVC.
I suggest using Spring MVC or Struts 2 for 168 & 268 JSR portlet if you want cross portlet-container portability or if you have more complex presentation requirements, you should find a list of the pro and cons of the two framework everywhere .
If you requirement are very simple then go with liferay MVCPortlet or even the JSPPortlet.
I have used 2) and 3) but not 1) - I'm not a fan of Struts.
Spring MVC gives you the power of Spring and plugs seamlessly into a Spring back-end as well as allowing the ability to wire to the Liferay Spring services. Provided you use MVC correctly and separate Controller concerns into separate Action classes then this is an extremely scalable and flexible choice and works well when coupled with Liferay.
Liferay's MVCPortlet provides much less in terms of flexibility but when used properly it is still highly scalable and a very useful choice. It also ties in to the Liferay IDE/Liferay Development Studio which provides benefits during development. If you have access to the Liferay Developer training then there is extensive coverage on Day 2.
Overall Spring has the greater benefits but also comes with the larger learning curve and greater risk of doing things incorrectly and hits you harder when done badly. Liferay's MVCPortlets done badly end up looking like vanilla portlets and as such is the lesser evil. Personally I use MVCPortlets for small tasks and Spring MVC for the larger ones.
In both cases 'doing it well' involves correct use of the framwork and annotations.
Liferay also supports Vaardin and have released the new Mail Portlet using it. I haven't used Vaardin but certainly plan on it and have heard good things so far.
From the ease-of-development point, I think the Vaadin is one of the best. The new Liferay IDE 1.2 already includes the Vaadin support making it very easy to start with it.
The same goes for application maintenance and APIs. With Vaadin the application code is simply Java code and that makes it easy to divide the work, and maintain the existing code (OOP benefits).
Already a good number of "add-ons" for Vaadin that demonstrate how the Java code can be "componentized" and development split across the organization(s).
Only downside comes from the fact that the Vaadin libraries are shared with all the Vaadin- portlets in a portal, which means they should use the same Vaadin version to keep the deployment easier.
Anyway, I'd say quite good match for your needs.
Just about to start a java EE project.(Biz requirement is under change still.)
For the web tier, we looked at various java web frameworks and eliminated component-based ones such as JSF, Wicket. Now it comes to spring mvc 3 or struts 2.
Googled it and found little useful info. Can anyone talk about their pros and cons? Thanks.
I took over a Struts 2 + Guice web app that used the REST plugin to do convention over configuration. It was very easy to work on at first but I ran into a couple of hurdles that were either difficult or impossible to overcome.
One of these was that I needed to have internal dot/period characters in the path of the URI and Struts 2 + REST did not allow this, as it would interpret the dot to indicate a file extension and try to marshall to the appropriate view (e.g. like catching .xml and .json).
So I ended up rewriting the webapp in Spring 3 and was able to fix all those issues I couldn't handle in Struts 2. I've been much happier with Spring 3 and found it just as fast to code in as Struts 2. I've stuck with annotation based configuration as much as possible and tried to use the JSR versions where ever possible (330 #Inject and 303 #Valid, etc), so that if I decide to get rid of Spring I am not stuck with custom Spring annotations.
My vote is Spring 3.
In this other stackoverflow question you have a lot of answers comparing struts and Spring. Though many of them don't mention explicitly the version 3 of Spring the comparison would be similar to the version 2.5.
As many of them say, I'd prefer Spring. It makes things easier when you use annotations. One fact I don't like in Struts 2 in comparison with Spring-mvc is that you have to add getters and setters for every property you want to get in the actions. I think Spring is cleaner in this way.
#Javi
You have various options in Struts2 to avoid these getter and setter one of them id ModelDriven interceptor
Well my vote is for Struts2 since i am working on it from so long but this does not mean Spring MVC is bad i have worked on it also and its equally good..
Choice is all yours and it depends what word you like most Spring or Struts