i did this for several of our applications a while ago...all went smoothly. it took me 1/2 day for the first app and 1/2 hour each for the next 4 (mid-size apps). the risks depend on what features of 1.1 you've used, especially with validation and messaging. the whole ActionErrors and related classes deprecation can be pains in the ass. here are some points to remember (i'll send you a bill later), especially if you want to get rid of deprecations:
1. validation.xml needs doc-type declaration 2. validation-rules.xml - replace all ActionErrors with ActionMessages 3. do the same for all your action classes 4. if you have custom validations, replace Resources.getActionError() with Resources.getActionMessage() 5. v1.1 ValidatorUtil. methods must be replaced by org.apache.commons.validator.util.ValidatorUtils
you need to also be conscious of where you have stored your errors and messages. the contants are now in the Globals class.
if you use JSTL to display struts errors, you'll need to do step 2 above.
-/a<br />certified slacker...yes, my last name is 'do' - <a href="http://www.luckycouple.com" target="_blank" rel="nofollow">luckycouple.com</a>
Joined: Jul 19, 2003
Hi Alan, Thanks for the response. I am not using Validator..but I will have to change the ActionError to ActionMessage though. I had another question on the controller interface. It currently has two methods "execute" and "perform", but the "perform" is deprecated. So if I am extending Controller class i need to implement both the methods...
Joined: Apr 14, 2005
ohhhh...that sucks. the way around it is to have a CustomController which implements the perform() and execute() of the Controller interface and do nothing. all the rest of the Controllers then would extend this CustomController and override ONLY the execute() method. this fits the rule of java interface inheritance right? anyone? or is the subclasses of the parent class that implements the interface also need to implement all the methods? i am too lazy to do a quick test.