The migration strategy of Struts 1 developers moving to Struts 2 involves four non-exclusive paths:
- Dual processor, shared resources - Add the Struts 2.0 JARs to your exisitng Struts 1.3 application. Configure S2 to handle
*.actionrequests s and let S1 handle
*.dorequests. S1 and S2 can run side by side, within the same web application. Teams can implement new features in the latest version, and migrate older pieces as needed. Optionally, some common resources may be shared between S1 and S2, like messages, validation rules, and Tiles configurations, making for an even smoother migration.
- Study known Struts 1 applications, rewritten for Struts 2 - Familiar applications such as the Struts Mailreader are being rewritten to demonstrate best practices for Struts 2.
- Use a conversion wizard - It may be possible to create a tool that reads the
web.xmland S1 configuration files, and generates the corresponding S2 classes, pages, and configuration files. While 100% compatibility is unlikely, we could make a strong effort to convert the application, marking areas that need attention. Comparing the converted files with the originals could also serve as a training tool.
Next: Migration Tools
This page originally adopted from http://wiki.apache.org/struts/MigrationStrategy.