felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject Re: A better life: quick webapp deploy
Date Fri, 13 May 2011 15:41:56 GMT
right ... that is the way to go ... modularize and share via the service registry.

Kind regards,

	Peter Kriens

On 10 mei 2011, at 18:26, mvangeertruy@comcast.net wrote:

> 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" <daniele@dellafiore.net> 
> To: users@felix.apache.org 
> 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 <peter.kriens@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message