aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Question about Blueprint Service and Bundle loading
Date Fri, 20 Apr 2012 14:47:24 GMT
I understand what you mean but I think dynamic import is already a bad 
thing and loading different classes depending on service impl would only 
make it more complex but not really cleaner.

So the question is if your problem could perhaps be solved cleanly with 
the current OSGi features.

Can you influence how the bundles 1 and 2 work? If yes then why let the 
service consumer create the objects? A factory implemented in bundle 1 
and bundle 2 sounds like a much better solution to me. You would then 
not even need the dynamic import. Of course I may completely 
misunderstand what you try to do.

Can you explain in more details how the bundles 1 and 2 work and what 
the client has to do?

Christian


Am 20.04.2012 16:08, schrieb Charles Moulliard:
> Bundle 1 and Bundle 2 export correctly the packages. This is simply 
> the client which is not able to loads the classes according to the 
> interface name only as we have 2 different implementations. When the 
> bundle client starts, its classloader has to load the classes from 
> bundle 1 or bundle 2. As we are using DynamicImport, this is not done 
> at the starting up of the bundle but when the bean is instantiated by 
> blueprint. Nevertheless, we have no possibilities today to tell using 
> DynamicImport that it must loads classes implemented in Bundle 1 or 
> Bundle 2 depending on info provided in the <reference interface="" 
> filter=""/> and the filter. That should be a great improvement of OSGI 
> + Blueprint if we could have that. That will allow us to really design 
> / use OSGI as a modular platform.
>
> On Fri, Apr 20, 2012 at 3:37 PM, Christian Schneider 
> <chris@die-schneider.net <mailto:chris@die-schneider.net>> wrote:
>
>     I don´t think that you can influence this... and honestly I don´t
>     think you should.
>
>     The clean way of loading impl classes for the service would be to
>     offer two impls of a Factory interface as an OSGi service. So you
>     could define the interfaces at one point and let the Factory
>     service in Bundle1 load the classes from bundle 1 and the Factory
>     service in Bundle2 load those in Bundle2.
>
>     Christian
>
>     Am 20.04.2012 13:43, schrieb Charles Moulliard:
>>     Hi,
>>
>>     I would like to know if this is possible for a bundle to know
>>     based on info defined in the OSGI Service registered in the OSGI
>>     Registry that it must loads package by example
>>     com.mycompany.poc.service.Feedback from a bundle A and not bundle
>>     B when its service definition contain a reference to a specific
>>     filter ?
>>
>>     Bundle 1
>>
>>     <service ref="service"
>>     interface="com.mycompany.poc.service.Feedback">
>>     <service-properties>
>>     <entry key="version" value="1"/>
>>     </service-properties>
>>     </service>
>>
>>     Bundle 2
>>
>>     <service ref="service"
>>     interface="com.mycompany.poc.service.Feedback">
>>     <service-properties>
>>     <entry key="version" value="2"/>
>>     </service-properties>
>>     </service>
>>
>>     Bundle 3 = Client consuming service
>>
>>     <bean id="helloBean" class="com.mycompany.poc.client.HelloBean">
>>     <property name="feedbackService">
>>     <reference interface="com.xtrac.poc.service.Feedback"
>>     filter="(version=1)"/>
>>     </property>
>>     </bean>
>>
>>     Here is the definition of the Bundle 3 Manifest
>>
>>     Import-Service =
>>     com.xtrac.poc.service.Feedback
>>
>>     DynamicImport-Package =
>>     com.xtrac.poc.service
>>
>>     This definition tells the bundle that it has do dynamically loads
>>     classes but in this case, the OSGI runtime will load classes from
>>     maybe Bundle A or bundle B.
>>
>>     Regards,
>>
>>     Charles Moulliard
>>
>>     Apache Committer
>>
>>     Blog : http://cmoulliard.blogspot.com
>>     Twitter : http://twitter.com/cmoulliard
>>     Linkedin : http://www.linkedin.com/in/charlesmoulliard
>>     Skype: cmoulliard
>
>
>     -- 
>     Christian Schneider
>     http://www.liquid-reality.de
>
>     Open Source Architect
>     Talend Application Integration Divisionhttp://www.talend.com  
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message