Hi,

I'm gonna try to give you a quick response and will get back to this mail
later with a bit more time.
First of all I'm not suggesting to drop spring, you've been referring to
camel at one point that's where I've got the impression that you might only
need blueprint.
But it might help already if you could give us an overview of the
architecture, or the way you've cut the bundles and the purposes.

For example if you have camel routes that reference your spring beans as
OSGi services you should consider to split this apart. Use camel with
blueprint and register your services via spring DM.

Regards, Achim

sent from mobile device
Am 16.05.2014 16:21 schrieb "constv" <cvasil...@healthedge.com>:

> 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.
>

Reply via email to