Thor Heinrichs-Wolpert skrev:
Where can I see more on the OSGi / Dependency Injection?
It's something I need to resolve in my work so knowing what a good
direction is would be helpful.
I would recommend to use the OSGi declarative services without any
Spring couplings. Considering that you can depend on such new and
untested technology as the DS of course.
I've been looking at the Spring/OSGi stuff that cocoon is doing with
some interest.
We develop the Spring/OSGi stuff only because we need to support our
legacy. If I where to start from scratch I wouldn't create such a
complicated architecture and only use DS for all dependency injection needs.
If you need Spring/OSGi integration there is some ongoing work within
the Spring community there is some code in their whiteboard (the CVS
seem to be down ATM, so I can't provide any link).
The reason that we develop an own Spring/OSGi bridge in Cocoon is that I
didn't know about the work at Spring when I started and also because we
have the additional complication that our Spring container is extended
to handle Avalon components.
Spring and OSGi has some impedance mismatch in component life cycle, and
component concepts. So it is easier to get correct dynamic service
dependency handling between bundles if you use DS alone.
--- o0o ---
For those interested in the technical details: The Cocoon/Spring bridge
use one Spring factory for each bundle. We use the bean post processor
hook in Spring for register all the Spring managed beans as services
(this requires that all beans are created at the bean factory creation
time, to make the beans available to the rest of the bundles). We also
have a OSGi service/Spring bridge in each bundle that implements
BeanFactory and that do a service lookup for each bean request. This
makes it possible to get beans that are managed in other bundles.
The OSGi service/Spring bridge is used as parent factory for the bean
factory, and make it thus possible to create components that get
dependencies from other bundles injected.
--- o0o ---
All this is ongoing work, and I'm fairly certain about that there are
further complexities that we haven't solved yet :/
/Daniel
