Though you can if you want access the XML files with the Bundle API you violate the intended encapsulation. This is similar to using reflection in Java. Extremely useful sometimes but you have to understand the consequences. As stated, OSGi is about collaborating services which are implemented in bundles. Once you find yourself fighting with the barriers that were consciously put in place you have to consider if you're having the right design. Or, of course, if OSGi is the right model for you.
Now for you particular problem there are other solutions. It seems you want to use Spring "templates". With a tool like bnd On 10 mei 2011, at 17:37, Daniele Dellafiore wrote: > On Tue, May 10, 2011 at 3:17 PM, Peter Kriens <peter.kri...@aqute.biz>wrote: > >> In OSGi the idea is that you get a bunch of bundles that collaborate >> through services. The bundle is a module and is therefore supposed to be >> impenetrable. Just like a class has private fields so does a bundle have >> private classes and resources. It would not be very modular if you could use >> the XML from other bundles, this Spring XML is supposed to be an >> implementation detail of the bundle. As long as you do the collaboration >> with services you can use many different techniques: Spring, DS, iPOJO, >> dependency manager, etc. >> > > Another way to say is that I use the XML from other bundles as I use a class > from another bundle, I do not see any violation here. > A spring xml is an implementation detail? For me is like a class, nothing > more, I load it using <import> like instantiate a class with a new. > > Example. > If I've defined some beans that manage storage and search in a bundle A and > want to load them in a bundle B changing just some properties (database > connections and some search tuning), the only way I know now, in OSGI, is to > copy-paste the spring XML into bundle A, cause import classpath*: does not > work. > Copy paste is always bad so I figure out that alternatives are: > > 1. importing beans from bundle A in the context of B, using a sort of > osgi:classpath > 2. exporing those beans as osgi services, but as long that properties are > chosen by bundle B, I need something more sophisticated like > ManagedServiceFactory to get a new instance with the actual parameters. I've > never dig into that but it seems to be the case. This solution, that I do > not find easy, is OSGI specific while I'd like to stay on spring and avoid > to couple with OSGI mechanism > 3. i can raise the level of abstraction. If I need a DatabaseTemplate > configured with some property that definese database connection, i can > export as osgi service a DatabaseTemplateFactory from bundle B and ask the > template to the factory from A. But here I loose advantages of spring IOC: > in my classes I will have an instance of the factory, and I've to ask for a > new class everytime and who keeps the control that the new template instance > is a singleton now? > 4. bundle A do the persistence and that's it. I export a DatabaseTemplate > that can write on different databases, and I tell which one using a > parameter or some more sophisticated mechanism (ThreadLocal? wonder how it > works on OSGI). > > Maybe is not that important but sometime it happens I have a bundle that > offer some classes. In a typical app that use that bundle, one or more > classes are candidate to become spring beans, in every app that will use the > classes. So I provide a ready to use spring xml so that you do not need to > copy-paste the spring definition but you can just import the file as a > resource. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
