Hey Tomasz As opposed to answering the question at the end of your email, I'll answer your subject, which are subtly different ;)
I migrated a bunch of webapp stuff to Karaf and I spent ages trying to figure out the spring stuff, then I suddenly realised..... don't use it! :) If I chat to people migrating webapps these days I try and steer them away from Spring, don't get me wrong in a non OSGI environment I use spring all the time, but in OSGI CDI and Blueprint have been more than enough for me and the projects I've worked on. Especially since Spring stopped support for OSGI stuff it seems to me to be getting progressively worse, so my own opinion is even if in the short term there is a gain with the synergy and cross over between 2 apps, at the end of the day it mostly provides wiring, which you can get better support for out of Blueprint. My 2 cents. Tom On Fri, Apr 22, 2016 at 2:56 PM, Tomasz Wozniak <tomasz.wozn...@s3group.com> wrote: > 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. > >
