Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox Summit 2007 Results"
(→Component Programming Models) |
|||
Line 4: | Line 4: | ||
== First breakout meeting == | == First breakout meeting == | ||
=== Component Programming Models === | === Component Programming Models === | ||
+ | |||
+ | * Service helper: ideal for one-time use. | ||
+ | |||
+ | * Spring | ||
+ | ** Injection model - no code to acquire the service | ||
+ | ** Client is handed a proxy to the service object | ||
+ | ** Framework manages binding of a real service to the proxy dynamically | ||
+ | ** Distinguish between mandatory service requirements | ||
+ | *** Mandatory: your bundle isn't started until all the mandatory services are available | ||
+ | *** This only guarantees availability at a moment in time: at the moment of startup all mandatory services are available, but they could disappear after that moment. | ||
+ | *** If a mandatory service goes away, the services exported by the bundle needing the service is unregistered. | ||
+ | ** For stateful services, there is a listener model - bind an unbind events occur as service implementations arrive and depart | ||
+ | ** It would be interesting to be able to declare a default service implementation that would be used whenever no real service is available | ||
+ | * Requirements for Spring service support: Spring core, Spring AOP, a few other essential Spring core pieces | ||
+ | * Service Application Toolkit: IBM toolkit for making it easier to work with OSGi services | ||
+ | * How do we reconcile and combine the various component toolkits available: Spring, DS, SAT, extension registry | ||
+ | * Spring initializes the app context asynchronously. Typical Eclipse programming model assumes that all initialization has completed by the time any classes are loaded in that bundle. | ||
+ | * To be scalable, we need a model where service wiring is persisted across sessions, so we don't have the massive ''event storm'' of services being started and bound as the system comes up. | ||
+ | * Most bundles are POJO - how do they specify that they need Spring or some other component system to be available at runtime? Ideally 95% of bundles don't know or care about the active component system - but they need '''some''' component system to be around at runtime to inject the services they need. | ||
+ | * Can we come up with a common syntax where a bundle can specify its service and extension registry imports/exports, and be agnostic about the runtime that will parse it and provide the runtime capabilities. | ||
+ | * Scoping: extension registry / services are global - how can I publish extensions/services that are only available in a particular scope* only particular set of bundles have access to it. In J2EE world, sometimes only want to register/bind services within a particular web app. Scoped registries - local versus global extension registry. | ||
+ | |||
=== p2 Design Deep Dive === | === p2 Design Deep Dive === | ||
=== Tooling === | === Tooling === |
Revision as of 14:25, 25 September 2007
The Equinox Summit 2007 was arranged as a set of lightning talks and a series of breakout sessions. Each session had a number of parallel discussions with self-assigned and self-organizing participants. The groups then reported to a plenary session, summarizing their results and possibly adding more topics to be discussed in further breakouts.
Contents
Day One Results
First breakout meeting
Component Programming Models
- Service helper: ideal for one-time use.
- Spring
- Injection model - no code to acquire the service
- Client is handed a proxy to the service object
- Framework manages binding of a real service to the proxy dynamically
- Distinguish between mandatory service requirements
- Mandatory: your bundle isn't started until all the mandatory services are available
- This only guarantees availability at a moment in time: at the moment of startup all mandatory services are available, but they could disappear after that moment.
- If a mandatory service goes away, the services exported by the bundle needing the service is unregistered.
- For stateful services, there is a listener model - bind an unbind events occur as service implementations arrive and depart
- It would be interesting to be able to declare a default service implementation that would be used whenever no real service is available
- Requirements for Spring service support: Spring core, Spring AOP, a few other essential Spring core pieces
- Service Application Toolkit: IBM toolkit for making it easier to work with OSGi services
- How do we reconcile and combine the various component toolkits available: Spring, DS, SAT, extension registry
- Spring initializes the app context asynchronously. Typical Eclipse programming model assumes that all initialization has completed by the time any classes are loaded in that bundle.
- To be scalable, we need a model where service wiring is persisted across sessions, so we don't have the massive event storm of services being started and bound as the system comes up.
- Most bundles are POJO - how do they specify that they need Spring or some other component system to be available at runtime? Ideally 95% of bundles don't know or care about the active component system - but they need some component system to be around at runtime to inject the services they need.
- Can we come up with a common syntax where a bundle can specify its service and extension registry imports/exports, and be agnostic about the runtime that will parse it and provide the runtime capabilities.
- Scoping: extension registry / services are global - how can I publish extensions/services that are only available in a particular scope* only particular set of bundles have access to it. In J2EE world, sometimes only want to register/bind services within a particular web app. Scoped registries - local versus global extension registry.