Goals
- Ability to deploy new actions/replace actions and pages without a container restart
- Ability to deploy new/replace business-layer services without a container restart
- Ability to run Struts 2 applications on future versions without code modifications
- Ability to evolve Struts2 without fear of breaking an API
- "Immutable APIs" - APIs that don't change, even after major upgrades to Struts
Scenarios
- App developer develops a new Action class with template, then presses a button and deploys the changes without any restart necessary
- App development team creates a new version of a deployed bundle, then uploads the bundle on live application and the module upgrades automatically with no downtime
- App developer wants to upgrade Struts by simply dropping the new release into her application and not change any of their code
- Multiple application bundles, each configured to run against a different version of Struts, work simultaneously against the latest version of Struts
Process
- App developers will create bundles, which are simple jar files containing Java classes, templates, and configuration, to be deployed into Struts
- Each bundle will declare what version of Struts it is expecting to run against
- Struts 2 will take care of the bundle deployment and provide a way to manage installed bundles
- App developers will not be required to be OSGi experts as Struts will try to shield the application as much as possible
| Anchor |
|---|
| implementation |
|---|
| implementation |
|---|
|
Implementation
- Struts 2 core and plugins will remain the way they are today, ensuring legacy applications can run unchanged
- The Struts 2 OSGi plugin will contain:
- An embedded OSGi container, probably Felix or Equinox
- An admin interface - JSON, XML, and HTML versions - that allow bundles to be deployed, removed, and upgraded
- A new API jar/bundle project will be created that contains the public API
- A new implementation jar will implement the API using the underlying Struts framework
- 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
- Application bundles will declare in their manifest what version of the API they require
- 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
- I chose the version 2.5 because it indicates that Struts 2 applications will continue to work, however, the jump in the minor version indicates significant functionality for those that want to take advantage of it.
- My main pain point here is the difficult upgrade process for Struts applications. It should be possible to deploy an application, written against an older version of Struts, on the latest version of the framework. Only OSGi, with its proper version support, can handle running multiple versions of the same interface in the same JVM.
- To elaborate on the last point, I want to ensure Struts 2 is a viable and attractive framework for not just the 6-month project, but the 10 year project as well. In order to be the 10-year app framework of choice, we have to have a way to allow new application features to be written on the latest and greatest Struts framework without requiring rewrites of 5-year-old code. By encouraging applications to be written into discrete bundles, the large, complex app can be broken into functional pieces with their own dependencies and needs. Applications for years have been using the multi-jar approach to complexity, but OSGi takes it to the next level.
References
