I think you will really need to use an OSGi-aware DI engine like Declarative Services, Blueprint or even Guice w/ Peaberry.
These OSGi-aware DI engines use Bundle.loadClass to load the implementation classes even though the packages containing the implementation classes are not exported. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Tom Kesling <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2010/04/14 08:26 Subject: [osgi-dev] How to approach injection in OSGI Sent by: [email protected] I have a (non-osgi) application that uses commons-digester to construct/inject runtime objects. I want to adopt OSGI and restructure this application into a set of bundles. It is unclear to me how I can use commons-digester if I break this application up into bundles with only the interfaces exposed as API. Specifically: If digester is being used by one bundle to construct/inject it's runtime objects, I don't see how digester would have access to the implementation classes hidden in other dependent bundles. The only way that I can see this working is if all of the dependent bundles export all of their packages. This way digester should have the access it needs to the target classes. I would prefer to hide all implementation and just export the API packages in my bundles to reduce coupling. Questions: 1. Am I understanding this correctly? 2. How can I balance desire to hide implementation with desire to continue using commons-digester as injection engine? 2. What other options/approaches should be considered? Thanks for any advice. T _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
