Page History

The migration strategy of Action Struts 1 developers moving to Action Struts 2 involves four non-exclusive paths:

1. Run the SAF1 application as is - SAF2 will ship with the Action 1.3 JARs, so existing applications can run unchanged. Teams can upgrade to the "latest" version without changing a thing.
2. Dual processor, shared resources - SAF1 and SAF2 Dual processor, shared resources - Add the Struts 2.0 JARs to your exisitng Struts 1.3 application. Configure S2 to handle *.action requests s and let S1 handle *.do requests. 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 SAF1 S1 and SAF2S2, like messages, validation rules, and Tiles configurations, making for an even smoother migration.
3. 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.
4. Use a conversion wizard - It may be possible to create a tool that reads the web.xml and SAF1 S1 configuration files, and generates the corresponding SAF2 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.Study known SAF1 applications, rewritten for SAF2 - Familiar applications such as the Struts Mailreader are being rewritten to demonstrate best practices for SAF2.

Next: Migration Tools

...

This page originally adopted from http://wiki.apache.org/struts/MigrationStrategy.