Hi Guillaume, Been able to figure out my problem. Did that 2 years ago and finally my memory helps me to find the right implementation. Until now, I keep the interfaces separated (Bundle --> Acme :: OSGI :: Commons Service) from the implementations (bundle --> Acme :: OSGI :: Commons :: v1 AND bundle --> Acme :: OSGI :: Commons :: v2). So when the clients requests the Commons V2, then it gets the proxy object as an interface.
Remark : Will have a look to modification that you suggest ;-) Regards, Charles On Tue, Jun 18, 2013 at 10:07 AM, Guillaume Nodet <[email protected]> wrote: > You're hitting https://issues.apache.org/jira/browse/FELIX-1131, for > which I've just provided a patch. Feel free to test it and report. > > > 2013/6/18 Charles Moulliard <[email protected]> > >> Hi, >> >> I would like to deploy on OSGI platform (Karaf) two different versions >> (but could be more) of an OSGI service (org.acme.common.HelloWorldService - >> v1 & v2). For that purpose I have created 2 Blueprint XML config files, >> packaged the bundles and deploy them on karaf >> >> [ 57] [Active ] [Created ] [ 80] Acme :: OSGI :: Client (1.0.0) >> [ 60] [Active ] [Created ] [ 80] Acme :: OSGI :: Commons :: v1 >> (1.0.0) >> >> Here is an example of blueprint config for Commons V1 >> >> <?xml version="1.0" encoding="UTF-8" standalone="no"?> >> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; >> xmlns:cm=" >> http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0";> >> >> <cm:property-placeholder id="property-placeholder" >> persistent-id="config.v1"/> >> >> <bean id="helloWorldService" >> class="org.acme.common.HelloWorldServiceImpl" >> init-method="init" destroy-method="destroy"> >> <property name="version" value="${version}"/> >> </bean> >> >> <service ref="helloWorldService" >> interface="org.acme.common.HelloWorldService" >> ranking="100"> >> <service-properties> >> <entry key="version" value="v1"/> >> </service-properties> >> </service> >> >> </blueprint> >> >> Now, a bundle, which is a client of a service will consume it. >> >> <?xml version="1.0" encoding="UTF-8" standalone="no"?> >> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";> >> >> <bean id="helloWorldClient" class="org.acme.client.HelloWorldClient" >> init-method="callService"> >> <property name="service" ref="helloWorldService"/> >> </bean> >> >> <reference id="helloWorldService" >> interface="org.acme.common.HelloWorldService" >> filter="(version=v1)"/> >> >> </blueprint> >> >> That works fine. >> >> If now, I would like, that the client uses the latest version of the >> service v2 (and not v1) when we have 2 OSGI Services deployed on OSGI >> Registry, I must specifically specified that it must import the package >> "org.acme.common;version=2.0". >> But when I use a version range to let the bundle to take the latest >> version available, then I get this error >> >> [ 57] [Active ] [Failure ] [ 80] Acme :: OSGI :: Client (1.0.0) >> [ 60] [Active ] [Created ] [ 80] Acme :: OSGI :: Commons :: v1 >> (1.0.0) >> [ 61] [Active ] [Created ] [ 80] Acme :: OSGI :: Commons :: v2 >> (2.0.0) >> >> Caused by: java.lang.ClassCastException: >> org.acme.common.HelloWorldServiceImpl cannot be cast to >> org.acme.common.HelloWorldService >> at Proxy93f66d24_52d9_49b4_9d6c_8c65ce3ef1f1.callService(Unknown Source) >> at >> org.acme.client.HelloWorldClient.callService(HelloWorldClient.java:14) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_45] >> >> Remark : Doing a refresh of the bundle client does not allow the bundle >> to load the latest package version available. >> >> karaf@root> packages:exports 60 >> ID Packages >> 60 org.acme.common; version=1.0.0 >> karaf@root> packages:exports 61 >> ID Packages >> 61 org.acme.common; version=2.0.0 >> >> karaf@root> packages:imports 57 >> Acme :: OSGI :: Commons :: v1 (60): org.acme.common; version=1.0.0 >> >> Is there a workaround to allow a bundle which is a client of an OSGI >> Service (= Proxy object) to use the bundle containing the latest package >> version deployed ? >> >> Regards, >> >> -- >> Charles Moulliard >> Apache Committer / Architect @RedHat >> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com >> >> > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
