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.
Related
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.
I am learning Spring 3.x MVC. I now have a regular web page setup with built in css in the html.
My first question - where should I store external css files and link them with the html files and still keep the L18n option available in the future? Should I keep the css in the WEB-INF/resources/css and make the resource directly available? But would it eliminate the L18n option?
My second question - to query a database, I have a query template XML file. I need to load the template into my model and modify a few keywords and send it through the database api. First thing that came to my mind is to put the keywords into something like ${keywords} in the template (like how the views are resolved), but I am not sure where to store the XML file (in the classpath? or in the web-inf?)? and how to set the variable in the template XML from my model?
Thanks,
Jason
It seem like you have two separate questions here.
In regards to CSS location, I'd recommend to try out Spring Roo tool. You can quickly generate a working web application with l18n support and number of other advanced features. This application could serve as a foundation for your own app or you can study its structure to learn many good practices for building Spring web applications.
In regards to your second question it is unclear what you want to substitute and at what time (i.e. deployment time or runtime) and also unclear what SQL templates you are using. I'd recommend to use iBatis/MyBatis framework, which has great integration with Spring and advanced templating support. There you can load your Spring contexts and template xmls from the Java application classpath.
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.
Well let me try to explain what I need: once upon a time I have been contracted by a company to work for six months. The company was using an internal MVC framework, which was really outdated and bloated. Anyway I miss one great thing about it. It had JSP tags that you would fill with a controller name (as configured in xml files) and the "Action" (yeah was struts based), so that the resulting URL would be correctly pointing there (and I didn't have to worry about writing it by hand).
I was wondering if there is something similar in Spring MVC? It would be great
With spring-mvc - no. But grails, which is built ontop of spring-mvc, has this exact functionality:
<g:createLink controller="yourController" action="yourAction" />
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