Hi We've selected OSGi to modularize our system, it is obvious. Our technological background is JEE with spring framework. As we were satisfied with spring, JEE servers are hard to reconfigure, so we took on the table Karaf and we felt some confusion related to programing model. On the forum there were some discussions which recommended Spring DM or Blueprint but karaf provides also spring framework bundles which dosen't work in OSGi out of the box in our opinion. We met two major problems: 1. ClassLoaders, You can set up class loader for spring application context, but some classes in spring uses org.springframework.util.ClassUtil which return ContextClassLoader and every method is static so there is no option to override it 2. We weren't able to load spring schema definitions from spring bundles (eg. tx, mvc, context)
So the question is if there is some OSGi library which solves those problems or the only option is to use blueprint? Moreover OSGi is a novelty for us and we would like to have a cheap fallback solution to technology which we know -> spring + JEE servers, we decided to write own library which will allows us to use newest spring version in OSGi in a transparent manner. I would like to share idea behind that library to get opinions from more advanced OSGi users, maybe there is a similar solution on the market which we've missed. We looked at Spring DM, Blueprint and Peaberry they are designed around the same idea -> OSGi services are connected based on the information given in the annotations and this approach ties code to OSGi environment. We decided to operate on connected ServiceFactories which produces for user required service graph, such approach removes from code OSGi specific annotations actually we have two layers, ServiceFactory layer which know that operate in OSGi environment, and service layer which is OSGi free. In Spring ServiceFactory it is a Bean Factory or Application Context which extends Bean Factory so we are putting them to OSGi servise registry. Spring Application Contexts are connected by ParentBeanFactory which searches in OSGi service registry for required Spring Application Contexts by given bundle base on some additional OSGi headers. Which such configuration bundle application context produces spring beans/services for implementation which comes from that bundle or delegates creation to wired Spring Application Contexts by parent bean factory. Maybe in point how it works: 1. Each bundle with implementation has its own Spring Context published in OSGi service registry 2. Spring context are wired via parent bean factory, for that purpose we introduced two types of bundles, a. one which contains beans interfaces called API bundle b. second type which contains implementation and thus containing spring context, that bundle is saying in OSGi headers which API is implementing and which API is using. Based on that information Spring bean factories are connected in dependency graph on the factory level 3. Recommended scope for spring beans is session, request or prototype thanks to that we can have hot deployment for implementation. We can install new implementation bundle and its bean factory will be used by new user sessions, old user sessions will be using previously installed implementation. With singleton scope we are unable to use newly uploaded implementation as singleton beans are wired during first request. 4. Ongoing user session is unchanged by deployment of new implementation bundle, it uses the old one. It was important for us as we developing medical device and such change during user session can be unpredictable How it is implemented 1. Library provides SpringActivator which starts spring application contexts and configure for it ParentBeanFactory which is able to wire other required Spring Application Context based on additional OSGi headers 2. SpringActivator provides also OSGi tracker functionality -> application context is started when there is at least one implementation bundle for each used API bundle if there is more than one, the newest one is used. If we uninstall the last implementation bundle for given API bundle, all dependent application context are stopped. 3. Spring Context depends also on services which represents some physical resource like data source, cache, persistent unit. Such services are registered in service registry mostly by blueprint configuration, application context is started when all such services are available. It is taken into account by trackers. Application context obtains them from OSGi service registry by spring ObjectFactory configured in spring xml configuration so the single dependency on OSGi is in the xml configuration 4. For each implementation bundle there is a registered Spring property source which takes properties from ConfigAdmin with pid equal to bundle name so we can use OSGi properties in spring beans 5. Library solves class loaders problem. It setup proper Classloader for spring application context and replace spring framework classes which uses ClassUtils class 6. SpringActivator also configures application context with Entity Resolver and Namespace Handler Resolver implementation to be able load schema definitions from spring bundles 7. We provided karaf commands to observe application context state and to list spring beans ( yes, karaf is a cool tool) What we achieved 1. So we have spring 4.1.7.RELEASE_2 with almost full functionality: bean injections, transactions, security, mvc. What is not working? Some annotations like @EnableSomething are using ClassUtill class but we substituted it with xml tags 2. We have service dependency management on a higher level, Spring Context represents group of related services -> module and we specify dependencies between them. It keeps the number of entries in OSGi registry on reasonable level we will have around 40 modules but number of services will go in hundreds as in typical JEE system 3. Developer needs to enter additional headers and the rest of the work is a just java code based on spring library 4. We have cheap fallback to JEE servers -> can run our system as monolith in JEE server by providing new spring xml configuration which will take data source or persistent unit from JNDI tree 5. We are able to deploy only part of the system what is cool in development and significantly reduces development time 6. We enjoy with all karaf feature (shell, jar wrapping, features, possibility to write own commands) So thanks for the karaf and what do You think about our approach to sping in OSGi? For sure it is not recommended by OSGi standard but it reduce risk and hesitation for newcomers Regards Tomasz ----- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
