StrutsUpgradeNotes11to124

Upgrading Struts 1.1 to Struts 1.2.x
jars
I guess its obvious to say you need to replace the jars, but the one people might forget is the new commons-validator.jar for version 1.1.3 of validator.

Also if you want to start using the new validwhen validation rule, then you will need to deploy the antlr.jar as well.

NOTE If your existing app uses the Struts SSLExt library, you must upgrade it as well:  http://sslext.sourceforge.net/

tlds
Remember to deploy the new versions of the tld files for struts tags. If you don't you won't be able to use the new tag attributes added.

NOTE The uri's in the struts tlds have changed from jakarta.apache.org/struts to struts.apache.org - however this shouldn't have any impact (see below)

Tag libraries can be configured in one of two ways:

A. If you have configured the tag libraries using entries in the web.xml (see  User Guide) then these should continue to work.

B. If you have used the simplified deployment allowed by Servlet 2.3 onwards (see  User Guide) then this should also continue to work as versions of the tld's with the old uri have now been included in the struts.jar (and struts-el.jar). Its recommended that for new development that you use the new uri

Struts 1.1  <%@ taglib uri="http://jakarta.apache.org/struts/tags-html" prefix="html" %> 

Struts 1.2.x  <%@ taglib uri="http://struts.apache.org/tags-html" prefix="html" %> 

validator.xml
Change the dtd declaration at the top to refer to the dtd for validator 1.1.3

<!DOCTYPE form-validation PUBLIC

"-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1.3//EN" " http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd">

validator-rules.xml
Upgrade to the new version of validator-rules.xml.

N.B. One of the changes in the new validator-rules.xml is that the Validation methods' signatures changed from using ActionErrors to ActionMessages. If you have any custom validation methods, remember to change their method signatures to now use ActionMessages.

struts-config.xml
Its not absolutely necessary but you should upgrade to the 1.2 version of the dtd (Note that as well as the version number changing so has the url to struts.apache.org).

<!DOCTYPE struts-config PUBLIC

"-//Apache Software Foundation//DTD Struts Configuration 1.2//EN" " http://struts.apache.org/dtds/struts-config_1_2.dtd">

If you do upgrade to the 1.2 version dtd then there are a couple of attributes which have been removed and you will need to remove them from your struts-config:

debug has been removed from the "controller" element.

dynamic has been removed from the "form-bean" element

Also the contextRelative attribute in the "forward" element is now considered "deprecated" and a new module attribute added.

ActionError(s) and ActionMessage(s)
There is some confusion over ActionError and ActionErrors and whats deprecated.

A. ActionError IS deprecated and should be replaced by ActionMessage.

B. ActionErrors IS NOT deprecated. The Struts committers would have liked to have deprecated ActionErrors but because too much of core API depend on it (such as the ActionForm's validate method) it hasn't been. However it may be in the future and, where possible, you should now use ActionMessages in place of ActionErrors.

Theres more on this topic on StrutsDeprecatedActionErrors.

Custom Tags and Validation
Many methods in org.apache.struts.util.RequestUtils and org.apache.struts.util.ResponseUtils are deprecated. Replace RequestUtils.* and ResponseUtils.* with org.apache.struts.taglib.TagUtils.getInstance().*

Replace org.apache.commons.validator.ValidatorUtil with org.apache.commons.validator.util.ValidatorUtils.

<init-param> web.xml configuration
A number of the of init parameter entries (i.e. <init-param>) in the web.xml were marked as deprecated in the Struts 1.1 release and have been removed in Struts 1.2. A list of the init parameters which have been removed is given below (refer to the  User Guide for more information on Struts configuration):

mapping - see note on configFactory below

debug - replaced by  Commons Logging

bufferSize - moved to <controller> element in the struts-config.xml

content - renamed to contentType and moved to <controller> element in the struts-config.xml

locale - moved to <controller> element in the struts-config.xml

maxFileSize - moved to <controller> element in the struts-config.xml

nocache - moved to <controller> element in the struts-config.xml

multipartClass - moved to <controller> element in the struts-config.xml

tempDir - moved to <controller> element in the struts-config.xml

application - now parameter in the <message-resources> element in the struts-config.xml

factory - moved to <message-resources> element in the struts-config.xml

null - moved to <message-resources> element in the struts-config.xml

N.B. There is a new configFactory init parameter in Struts 1.2 which can be used to set a custom ModuleConfigFactory class. This could be used to initialize default ModuleConfig settings on a struts-wide basis.

<html:form> Tag Attribute Deprecations
The name, scope and type attributes on the <html:form> tag were deprecated in Struts 1.1 and have now been removed in Struts 1.2.

The <html:form> tag was enhanced in Struts 1.1 to automatically create a new ActionForm instance based on the action mapping from the struts-config.xml. However the behaviour associated with the name, scope and type attributes still functioned.

In struts 1.2 you need to remove these attributes from the <html:form> tag in your jsp. If the values for these attributes match what you have in the struts-config.xml for the mapping then just removing them should be the the only action you need to take.

If they are not the same then problems will almost certainly occur when you upgrade to Struts 1.2 and remove the attributes. If, for example, you have pre-filled a form and stored it in a different scope these will no longer be displayed and the form values appear to have been lost. This can be resolved either by changing the scope on the mapping or by storing the form in the correct scope.

MessageResource Bundle Requirement
When the TagUtils class was introduced, it inadvertently added a new minimum requirement for taglib-only uses of Struts (those not using the ActionServlet + struts-config.xml, but only the tag libraries). In several of the Struts tags, the method TagUtils.retrieveMessageResources() is called, which looks for the MessageResource bundle typically configured by the ActionServlet (and placed in application scope). In the case that it cannot be found in any scope, the method attempts to access the moduleConfig object, which for taglib-only users, is null. This leads to a NullPointerException.

To reconcile this issue, it is necessary to create a bundle and put it into one of the scoped variables. This can be done in a custom servlet or in a top level JSP page.

MessageResources bundle = MessageResources.getMessageResources("ApplicationMessages");
pageContext.setAttribute(Globals.MESSAGES_KEY, bundle, PageContext.REQUEST_SCOPE);If done in a custom servlet (and hence application scope) an empty ModuleConfig object must also be created and stuffed in the application scope.

ModuleConfig moduleConfig = new ModuleConfigImpl("");
moduleConfig.freeze();
getServletContext().setAttribute(Globals.MODULE_KEY, moduleConfig);Change Action.perform(...) to Action.execute(...)
In Struts 1.1 the execute(...) method was introduced and perform(...) method deprecated in  Action. In Struts 1.1 the deprecated perform(...) method continues to work.

In Struts 1.2.x the deprecated perform(...) method was removed from  Action and therefore any Action's which still implement perform(...) rather than execute(...) no longer function and should be changed to implement execute(...).