Page History

...

1. Ability to deploy new actions/replace actions and pages without a container restart
2. Ability to deploy new/replace business-layer services without a container restart
3. Ability to run Struts 2 applications on future versions without code modifications
   1. Ability to evolve Struts2 without fear of breaking an API; highly desirable
   2. APIs that don't change

...

1. Struts 2 core and plugins will remain the way they are today, ensuring legacy applications can run unchanged
2. The Struts 2 OSGi plugin will contain:
   1. An embedded OSGi container, probably Felix or Equinox
   2. An admin interface - JSON, XML, and HTML versions - that allow bundles to be deployed, removed, and upgraded
3. A new API jar/bundle project will be created that contains the public API
4. A new implementation jar will implement the API using the underlying Struts framework
5. Each successive version of the API will have its own implementation jar, with all versions and implementations available at runtime in an instance of Struts
6. Application bundles will declare in their manifest what version of the API they require
7. Struts will continue to require only a 2.4 or greater servlet container

Alternatives

Alternative implementations that were rejected

Namespaced API packages with hotswap deployment

• + Allows multiple versions of the API to run in the same JVM
• + Hotswap can update classes as long as its signature doesn't change
• - Requires application code changes to change APIs
• - Hotswap can't update classes with new, modified or removed methods or fields
• - Hotswap only useful for development

Thoughts

...