Migrating to Struts 2, Part 2; First Struts 2 Dev Build Released

by Floyd Marinescu on Oct 18, 2006 |
Part 2 of Migrating to Struts 2 has been published on InfoQ, and on Oct 10th, the first public release of Struts 2, the first development build (2.0.1) was made available. Struts 2 was originally known as WebWork 2. After working independently for several years, the WebWork and Struts communities joined forces to create Struts 2. This new version of Struts is designed to be simpler to use and closer to how Struts was always meant to be.

In the first part of the article series, Ian explained (for Struts developers) the high level architecture, basic request workflow, configuration semantics and differences in the action framework in the new Struts 2 (formerly WebWork) and Struts 1.  In this part of the Struts 2 migration series, Struts committer Ian Roughely looks at a real application and compares the Struts and Struts 2 implementations, identifies how to convert actions, configuration changes, and what parts of the codebase don't need to be converted.

Read Migrating to Struts 2, Part II, published today.

According to the Struts 2.0.1 release announcement, some key changes are:
  • Smarter!
    • Improved Design - All Struts 2 classes are based on interfaces. Core interfaces are HTTP independent.
    • Intelligent Defaults - Most configuration elements have a default value that we can set and forget.
    • Enhanced Results - Unlike ActionForwards, Struts 2 Results can actually help prepare the response.
    • Enhanced Tags - Struts 2 tags don't just output data, but provide stylesheet-driven markup, so that we can create consistent pages with less code.
    • First-class AJAX support - The AJAX theme gives interactive applications a significant boost.
    • Stateful Checkboxes - Struts 2 checkboxes do not require special handling for false values.
    • QuickStart - Many changes can be made on the fly without restarting a web container.
  • Easier!
    • Easy-to-test Actions - Struts 2 Actions are HTTP independent and can be tested without resorting to mock objects.
    • Easy-to-customize controller - Struts 1 lets us customize the request processor per module, Struts 2 lets us customize the request handling per action, if desired.
    • Easy-to-tweak tags - Struts 2 tag markup can be altered by changing an underlying stylesheet. Individual tag markup can be changed by editing a FreeMarker template. No need to grok the taglib API! Both JSP and FreeMarker tags are fully supported.
    • Easy cancel handling - The Struts 2 Cancel button can go directly to a different action.
    • Easy Spring integration - Struts 2 Actions are Spring-aware. Just add Spring beans!
    • Easy plugins - Struts 2 extensions can be added by dropping in a JAR. No manual configuration required!
  • POJO-ier!
    • POJO forms - No more ActionForms! We can use any JavaBean we like or put properties directly on our Action classes. No need to use all String properties!
    • POJO Actions - Any class can be used as an Action class. We don't even have to implement an interface!

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Version Numbers by Corby Page

Not sure that I understand the numbering scheme.

What will be the version number for the first Production quality release of Struts 2?

Re: Version Numbers by Don Brown

Struts uses the Tomcat naming system, so numbered releases are created first, then after a week or so, they are voted on to determine their quality. In this case, 2.0.1 has been created, but the vote for its quality hasn't happened yet. My vote will probably be for beta due to some broken showcase examples, although we are really close to GA.

A bit confused... by Alex Wibowo

Hi,

Firstly, thanks for writing the article. I enjoy reading through it.


I have a question regarding what you wrote in this 2nd tutorial, in particular about the "ModelDriven" interface. From the sample code, it seems that this interface specifies the "getModel()" method. When does this method gets called (which presumably by the framework itself - i think)?

"Now, instead of finding a setter on the action, the model is first retrieved and checked to see whether it has a setter matching the attribute name. If there is no such setter on the model object, but there is on the action, then the value will be set on the action."
--> Isnt the model null initially? The framework wants to call setId().. and it
tries to do so on the model first. But the model gets initialized on the prepare() method. But looking at your prepare() method, it needs the "blogId", which is initialized on the setId() method. So by that time, "blogId" is null, and hence.. everything does not work. I'm sure I'm missing an important point here. It would be great if you can enlighten me :)

XML by Dorel Vaida

Still didn't find a way to get rid of all that XML ? AFAIK that was one of the main drawbacks people have complained about over the years (not considering those heavy OOP-ists who thought forms are BS :-) )... Eventually some code-by-convention + annotations (I know it's arguable but 99% of the devs will use struts as a WEB framework so it isn't such a shame to place configuration like form, success view etc. in action classes) overriden from XML if somebody really wants it ?

Re: XML by Ian Roughley

Yes - there is definately a lot of XML in the configurations presented. The good news is that there is a large effort being put forward to move configurations to a common convention (so no specification is required) as well as providing annotation.

As this article was about converting application, it made sense to provide the XML configurations - as this is what most people using Struts would be farmiliar with.

Re: A bit confused... by Ian Roughley

Sure - no problem. The trick is in the interceptor stack.

The interceptor stack for the action in question is the "paramsPrepareParamsStack". The interceptors for this stack go like this... (1) params - to apply parameters to the action (so the id is set on the action), (2) prepare - to call the prepare() method using the id that has been previously set, and then (3) params again to set the values on the model.

Please note that there is a little redundancy here, as the action and possibly the model will not have the setters for the parameters that are trying to be set against them.

PS - Sorry for the delay in answering, I have been on vacation.

Re: A bit confused... by Subhash Murthy

Please let me know how to configure/write action class such that the form input values are populated directly into variables in the action class. (as in struts 1 form bean) without using Maps (which can be done using ParameterAware Interceptor).
I tried by implementing ModelDriven intercpetor as in struts2 tutorial but in vain to get them into the action class.
Please help me.
-Subhash

source code missing classes. by Man Moon

com.fdar.articles.infoq.conversion.Blog
com.fdar.articles.infoq.conversion.BlogService

Re: source code missing classes. by Dhiraj P

hi....i tried to download the source codes from the links: www.infoq.com/resource/articles/migrating-strut... and www.infoq.com/resource/articles/migrating-strut... but couldnt download....are the links still alive?
Thanking you,
Dhiraj

Re: A bit confused... by Ian Roughley

You need to name the form parameters the same as the names in the model. You might want to try the Struts mailing list for this type of question.

Dumb Question by David PIchard

So, after reading several papers on converting a struts 1 app to struts 2 can someone please restate the obvious for me: In converting my app I am going to have to rewrite the tag info in all my JSPs as well as modify all my classes to some degree? I had read an article or two leading me to believe struts 1 and 2 could peacefully co-exist and all new features of the app could be written to use struts2... leaving existing functionality in place... Any input would be greatly appreciated...

- David

Forward to the action in Struts 2 by jan Vondr

Good article Thanks
But in article is this solution for forwarding to list.action

<result type="redirect">list.action</result>

I think in struts 2 is better to write

<result type="redirect-action">list</result>

Re: source code missing classes. by Rong Wang

Did you find the two missing classes? Thanks.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy