Affects Version/s: None
Fix Version/s: 7.0.0 M6
A few parts of our current infrastructure is built on top of the Spring framework: transaction management, AOP infrastructure, dependency injection, ....
Our Service Builder based apps require an specific Spring application context where we put some extra functionality. The current, and first approach, was to build the new infrastructure on top of Eclipse Gemini Blueprint, however is has some drawbacks:
- The current version we are using is an snapshot. Nobody is taking care of the project and it is not evolving at all.
- As we are doing more work on top of it, we find it quite inestable when doing redeployments of modules based on this infrastructure.
- The OSGi Spec has no lead, and nobody seems to be interested in taking the leadership.
- The startup of this modules is based on an "active waiting" approach so a bunch of threads are blocked while waiting for all the required dependencies.
- We are revamping the Upgrade Infrastructure and we need a better control of the lifecycle of this apps
Based on all of these we are going to replace the current infrastructure with a Declarative Service based approach. Some highlights (more technical details will be included on every subtask):
- We are not removing Spring from the Service Builder apps. We are just using a completely different approach.
- We are going to deal with the Spring Context as a single static unit. We don't plan to add dynamism to Spring (this is what Blueprint tries to do) but we are just going to deal with the contexts as a whole.
- You will be able to specify references to OSGi services from your Spring Context, but if one of this references is gone, the whole application context will be gone (this is what "as a single static unit" means)
- Startup of the apps will be done based on Declarative Services + Dependency Manager so we won't need an "active waiting" any longer.