On Tue, May 10, 2011 at 11:37 AM, Daniele Dellafiore <dani...@dellafiore.net> 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.
Maybe I'm missing something, but what's stopping you from exporting the package containing these XML files from one bundle and importing them in another? > 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
