Migration Strategies

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

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

  1. 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 S1 and S2, like messages, validation rules, and Tiles configurations, making for an even smoother migration.
  2. 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.
  3. Use a conversion wizard - It may be possible to create a tool that reads the web.xml and 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.