Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Gyrex/Concepts/Http Application Extensions"

(Created page with "Gyrex provides a concept for defining HTTP applications. This article discusses an approach for providing extensions to those applications in a generic way. == Goals == * Al...")
 
(Design)
 
(One intermediate revision by the same user not shown)
Line 10: Line 10:
 
== Design ==
 
== Design ==
 
* Opt-in model
 
* Opt-in model
** define #initializeExtensions method in Application class which must be called by participating applications
+
** define #activateExtensions method in Application class which must be called by participating applications (eg., during doInit)
 
+
** define #deactivateExtensions method in Application class which will be called automatically by Application#destroy; may also be called by Application subclasses if there lifecycle is different
 +
* ApplicationExtension need to be provided as OSGi service (whiteboard pattern)
 +
* Application scans for available ApplicationExtension services at initialization time
 +
** iterates over all available ApplicationExtension;
 +
** may have optional filter hook in Application class (isAllowedToUseExtension or so)
 +
** calls ApplicationExtension#activate(Application, IApplicationContext)
 +
** installs service listener/hook to be notified when extension goes away; calls ApplicationExtension#deactivate(Application, IApplicationContext) when unregistered
 +
** continues to listen for new extensions while initialized; dynamically activates and deactivates extensions as they come and go
 +
* Security
 +
** Track registrations by each extensions and only allow extension to unregister aliases it registered
  
 
== Open Questions ==
 
== Open Questions ==

Latest revision as of 07:53, 28 November 2013

Gyrex provides a concept for defining HTTP applications. This article discusses an approach for providing extensions to those applications in a generic way.


Goals

  • Allow to contribute static resources, JAX-RS resources, WebSockets, etc. to an already defined application.
  • Ability to add security/authentication filters to already defined applications.
  • Backwards compatibility with existing applications.


Design

  • Opt-in model
    • define #activateExtensions method in Application class which must be called by participating applications (eg., during doInit)
    • define #deactivateExtensions method in Application class which will be called automatically by Application#destroy; may also be called by Application subclasses if there lifecycle is different
  • ApplicationExtension need to be provided as OSGi service (whiteboard pattern)
  • Application scans for available ApplicationExtension services at initialization time
    • iterates over all available ApplicationExtension;
    • may have optional filter hook in Application class (isAllowedToUseExtension or so)
    • calls ApplicationExtension#activate(Application, IApplicationContext)
    • installs service listener/hook to be notified when extension goes away; calls ApplicationExtension#deactivate(Application, IApplicationContext) when unregistered
    • continues to listen for new extensions while initialized; dynamically activates and deactivates extensions as they come and go
  • Security
    • Track registrations by each extensions and only allow extension to unregister aliases it registered

Open Questions

Back to the top