Why do I need Spring? Do you mean for the DI wiring, or in general? ;) Lots of our application code/services have been developed with Spring, Spring has been used not only for DI, but for many other things, of course. I, of course, understand that the traditional Spring framework (not Spring-DM) is not for OSGi, and Blueprint is. However, lots of our code (originally developed as part of non-OSGi projects) uses Spring annotations, configuration, and many other Spring libraries, e.g data access support, AOP, REST, etc. Are you suggesting dropping Spring all together if we want to OSGi-enable our applications? Or just not to use it for DI? I understand that I can use Blueprint for DI and still keep using Spring libraries. As a DI framework, Blueprint provides just a subset of the features Spring provides, so I'd have to refactor much of the existing stuff. Most of my individual bundles are self-contained services, so it would be a shame to butcher them just to make the container happy. Don't you think?
Generally, I have only one common bundle that needs to export its definitions to be shared with other bundles. So I am using Blueprint in that bundle to define a number of services that are exported via the OSGi service registry. Then, my other bundles (mostly, the original non-OSGi Spring-wired stuff) need to use these services by importing them using spring-dm. I don't want to have to re-do the whole Spring configuration for these bundles. This approach has worked before, but I am no able to get this to work in Karaf 3 with Spring 4 and spring-dm 1.2.1. Nevertheless, I am open to suggestions, and if the only reliable way is to use Blueprint for bean configuration - in the bundles that import OSGi-shared references, I guess I'd have to consider that. So, my question is: does Karaf NOT guarantee seamless integration/support for Spring/Spring-dm-configured bundles? -- View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033139.html Sent from the Karaf - User mailing list archive at Nabble.com.
