Bundle 1 and Bundle 2 contain a different implementation of the interface
which is exposed as OSGI service
Bundle 1
<bean id="service"
class="com.mycompany.poc.service.impl.FeedbackTeamWS"/>
<service ref="service" interface="com.mycompany.poc.service.Feedback">
<service-properties>
<entry key="version" value="1"/>
</service-properties>
</service>
Bundle 2
<bean id="service" class="com. mycompany.poc.service.impl.FeedbackTeam
DB"/>
<service ref="service" interface="com.mycompany.poc.service.Feedback">
<service-properties>
<entry key="version" value="2"/>
</service-properties>
</service>
So the bundle C do an OSGI lookup to retrieve using as key the interface
name "com.mycompany.poc.service.Feedback", the class implemented in bundle
1 or bundle 2.
What would be great is that the bundle C when the following bean is
instantiated loads the class from the bundle 1 as the filter of the
reference to be found corresponds to it
<property name="feedbackService">
<reference interface="com.mycompany.poc.service.Feedback"
filter="(version=1)"/>
</property>
Intrinsically we know that the class implementing this interface belongs to
bundle 1 as filter = 1 = OSGI service exposed by bundle 1 = class =
com.mycompany.poc.service.impl.FeedbackTeamWS
On Fri, Apr 20, 2012 at 4:47 PM, Christian Schneider <
[email protected]> wrote:
> 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 <
> [email protected]> 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 Schneiderhttp://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>
> --
> Christian Schneiderhttp://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
