The "hack" way around this is to use Dynamic-ImportPackage. Another possibility is to implement your own ClassLoader that magically knows how to look for classes not only in your API bundle but also in all registered API bundles and give that ClassLoader to commons-digester. This can be done using either the Bundle Extender pattern or, more fine grained-like, the ServiceTracker pattern.
________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of BJ Hargrave Sent: 2010, April, 14 9:12 AM To: OSGi Developer Mail List Subject: Re: [osgi-dev] How to approach injection in OSGI 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 <http://www.osgi.org/> [email protected] <mailto:[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 <https://mail.osgi.org/mailman/listinfo/osgi-dev> ________________________________________ This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately. This E-Mail (including any attachments) has been scanned for viruses. It is believed to be free of any virus or other defect that might affect any computer system into which it is received and opened. However, it is the responsibility of the recipient to ensure that it is virus free. The sender accepts no responsibility for any loss or damage arising in any way from its use. E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory personnel. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information. IRS CIRCULAR 230 NOTICE: TO COMPLY WITH U.S. TREASURY REGULATIONS, WE ADVISE YOU THAT ANY U.S. FEDERAL TAX ADVICE INCLUDED IN THIS COMMUNICATION IS NOT INTENDED OR WRITTEN TO BE USED, AND CANNOT BE USED, TO AVOID ANY U.S. FEDERAL TAX PENALTIES OR TO PROMOTE, MARKET, OR RECOMMEND TO ANOTHER PARTY ANY TRANSACTION OR MATTER.
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
