...
- 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; highly desirable
- APIs that don't change
Anchor | ||||
---|---|---|---|---|
|
...
- 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
Anchor | ||||
---|---|---|---|---|
|
Thoughts
...