Danielle,
What you are trying to do is best accomplished by using services. In my application, we have a database connection and JMS connections that are used by multiple bundles. So, for my database connection (since that's what we're talking about), I created my bundle, and then in the context file that uses the osgi and osgix namespaces, I simple attached the bundle to the service registry. Then any other bundle that needed to consume the database connection was able to grab a reference to the database service from the service registry, and then inject it via the database connections interface. v/r, Mike Van ----- Original Message ----- From: "Daniele Dellafiore" <[email protected]> To: [email protected] Sent: Tuesday, May 10, 2011 11:37:22 AM Subject: Re: A better life: quick webapp deploy On Tue, May 10, 2011 at 3:17 PM, Peter Kriens <[email protected]>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.
