Versions Compared

Old Version 2

changes.mady.by.user Donald Brown

Saved on

compared with

New Version Current

changes.mady.by.user Donald Brown

Saved on

Key

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

...

  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. "Immutable APIs" - APIs that don't change, even after major upgrades to Struts

Anchor
scenarios
scenarios

Scenarios

...

Anchor
process
process

Process

  1. App developers with will create bundles, which are simple jar files containing Java classes, templates, and configuration, to be deployed into Struts
  2. Each bundle will declare what version of Struts it is expecting to run against
  3. Struts 2 will take care of the bundle deployment and provide a way to manage installed bundles
  4. App developers will not be required to be OSGi experts as Struts will try to shield the application as much as possible

...

  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

Anchor
thoughts
thoughts

Thoughts

...