Details
Task
Closed
Major
Description
Currently a number of API support extension mechanism via the OSGi service registry, for example the data access providers are contributed to the platform as OSGi services. This is a simpler approach than the traditional Eclipse extension mechanism because it avoids the need of creation extension schema and Java classes to read from the extension registry.
Within GumTree we use both OSGi-DS and Spring-DM for OSGi service registration. However, when comparing to Eclipse extension poin, both have disadvantage because the contribution items (services) are not visible unless the contributing bundles are active.
Hence, we need to find a way either smart enough to activate those contributing bundles by default, or make those contribution items visible using proxy pattern. Or may be we can use the new OSGi blueprint specification (in Spring-DM 2.0)
References:
- http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf - Whiteboard pattern
- http://www.eclipsezone.com/articles/extensions-vs-services/ - A Comparison of Eclipse Extensions and OSGi Services
- http://stochastyk.blogspot.com/2008/05/spring-dm-and-osgi-service-proxy.html - Spring-DM and OSGi Service Proxy
- http://groups.google.com/group/spring-osgi/browse_thread/thread/49400fb1aeaab8b4/63d681a50ad19f85?#63d681a50ad19f85 - How do I start the Spring-osgi bundle?
- http://groups.google.com/group/spring-osgi/browse_thread/thread/3da3ace5e34829fc - Auto-start bundles?
- http://aniefer.blogspot.com/2009/02/installing-and-running-plugins-in.html - Installing and Running plugins in Eclipse applications
The OSGi blueprint container is not yet in production (Spring-DM 2.0 is still under development), so there are two solutions available for bundle activation:
1. Programmatic activation via OSGi API
2. OSGi-DM
The first method involves using a default activated bundle (eg GumTree runtime) to activate other bundles programmatically. An advantage of this is we can control a list of bundles for activation via system configuration. However, this will cause confusion if a same bundle has various versions installed, which is difficult to select which one should be activated. This also requires extra programming and testing.
The second method uses OSGi DS to load classes into the service registry. By doing this, the bundle which contains those classes will be activated as well (if lazy activation is set). The problem is then we should both Spring DM and OSGi DS looking after service injection, which makes the platform harder to maintain.
Now, a third solution is to utilise the second method, where we use OSGi DS only for bundle activation (via a dummy service) and let Spring DM do all the injection.