|Home > Guides > Migration Guide > Struts 1 Solutions|
This page is meant to be a list of issues and solutions that users ave encountered while migrating existing Struts 1 application to Struts 2, or developing new Webwork-based applications. If you have a solution to the issue that will of course be most helpful, but even if you don't it is worth noting what you encountered none the less in the hopes that someone else can come along and answer it for you, and the rest of us.
Struts 2 uses a different approach to loading the configuration. The initial struts.xml is loaded from the root of the classpath. The easiest way to set that up is to put the struts.xml under the classes folder.
If maintaining the struts.xml under classes doesn't work for you, then use the "bootstrap" struts.xml to include whatever other struts.xml's you'd like.
Or, chuck it all and use Zero Configuration
In Struts 2, checkboxes are stateful, and we don't need to do that anymore.
Just treat the checkbox like any other tag. The framework will notice if a checkbox is "missing" from a request and inject a false value for that checkbox.
The default Action class (ActionSupport) returns SUCCESS by default, and SUCCESS is the default result. Using an action to forward directly to a page is easy:
Rather than tag the action as being the default, the default action is set by name using default-action-ref element.
By using an element, rather than an attribute, packages can inherit the default action name.
Starting in Struts 1.3, we can use the "extends" attribute in our Struts configuration Action mapping to have it inherit properties from a base mapping. In Struts 2, that technique is no longer necessary because we have packages. We can create a package, then set for that package the default Result type, Interceptor chain, and global results. This leaves very little information to actually be included in an action element.
Here is an example of declaring a custom package:
In fact, packages themselves can extend other packages, as the "chat" package extends "struts-default" in the above example.
Sure, but first, ask "Do we want to use DynaBeans at all?"
Typically, DynaBeans are used to emulate a plain old JavaBean that is utilized by the business logic. If that is the case, then we can just use the plain old JavaBean directly. Struts 2 will happily cope with rich properties, like date fields. We don't have to reduce everything to a String anymore.
Otherwise, DynaBeans can be treated as a regular Java object, if the particular implementation contains a getMap() method. This method lets OGNL, the Struts 2 expression language, know how to access and set data. DynaBean variants like the LazyDynaBean can create themselves on-the-fly, where other more static types might need to be created in your Action's constructor before being used.
In Struts 2, there shouldn't be any token code in an Action class at all. The Interceptors are designed to do all the work. There are three flavors, the Token Interceptor, the Token Session Interceptor, and the Execute and Wait Interceptor.
The Token Interceptor is most like the Struts 1 approach, except that we don't have to change the Action class to add a lot of busy code. The trade off is that we do have to include the token tag in the form, to bootstrap the process. In Struts 1, we set the token in the Action, and the form tag detected it. In Struts 2, we set the token in the page, and the Interceptor detects it.
If the Interceptor does detect a duplicate submit, then it automatically returns an "invalid.token" result code, which can be handled via the action mapping.
The Token Session Interceptor tries to be even more automatic by attempting to display the same response that the original, valid action invocation would have displayed if no multiple requests were submitted in the first place.
The Execute and Wait Interceptor embraces long-running taks by presenting a progress meter as the Action runs in the background.
This material originally adopted from: http://wiki.apache.org/struts/IssuesAndSolutions.