felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Problem using Declarative Service with a multi versioned service
Date Fri, 13 Aug 2010 14:55:36 GMT
Hi,

I did change some argument checking for bind methods shortly before the
1.6.0 release (The 1.6.1-SNAPSHOT is essentially still the same as the
1.6.0 release currently being voted) to get SCR pass the CT.

I cannot exclude the possibility of this introducing a nasty side effect
bug.

Can you test your scenario with the prior 1.4.0 release ? Does it
exhibit the same issue ?

Nevertheless, I would assume this to be a bug, yes.

Regards
Felix

On 13.08.2010 16:42, Pierre De Rop wrote:
> Hi everyone;
> 
> I would like to test a multi versioned service using declarative service
> (I'm using latest SCR from trunk: 1.6.1.SNAPSHOT + fwk 3.0.1.
> So, I have a first bundle service-1.0.0.jar which exports a Service whose
> package is exported using version=1.0.0
> I then have another bundle service-2.0.0.jar which exports the same Service
> (same package), but with version = 2.0.0;
> and the Service interface is incompatible (that's why the version major
> number is different).
> Each bundle have its implementation included in a private package.
> 
> Now, I have a third bundle (client.jar), which imports the Service API,
> using the version range "[1.0.0, 2)"
> and the client is referencing the Service like this:
> 
> <?xml version='1.0' encoding='utf-8'?>
> <component name='com.alcatel_lucent.samples.multiversion.client.Client'
> xmlns='http://www.osgi.org/xmlns/scr/v1.1.0' immediate='true'
> activate='start'>
>   <implementation
> class='com.alcatel_lucent.samples.multiversion.client.Client'/>
>   <reference name='service'
> interface='com.alcatel_lucent.samples.multiversion.Service'
> bind='bindService'/>
> </component>
> 
> The problem is that when I start my two versioned Service bundles (v1.0.0 +
> v2.0.0), the v2.0.0 bundle is started first, and SCR seems to try to inject
> it to my client bundle,
> even if the client bundle imports the v1.0.0 API ...
> So, SCR logs the following exception, when attempting to invoke the
> bindService(Service) method :
> 
> DEBUG: com.alcatel_lucent.samples.multiversion.client1.0.0 (11):
> [com.alcatel_lucent.samples.multiversion.client.Client] invoking bind:
> bindService
> DEBUG: com.alcatel_lucent.samples.multiversion2.0.0 (10):
> [com.alcatel_lucent.samples.multiversion.implv2.ServiceImpl] getting
> activate: activate
> DEBUG: com.alcatel_lucent.samples.multiversion2.0.0 (10):
> [com.alcatel_lucent.samples.multiversion.implv2.ServiceImpl] Locating method
> activate in class com.alcatel_lucent.samples.multiversion.implv2.ServiceImpl
> DEBUG: com.alcatel_lucent.samples.multiversion2.0.0 (10):
> [com.alcatel_lucent.samples.multiversion.implv2.ServiceImpl] Declared Method
> com.alcatel_lucent.samples.multiversion.implv2.ServiceImpl.activate([interface
> org.osgi.service.component.ComponentContext]) not found
> DEBUG: com.alcatel_lucent.samples.multiversion2.0.0 (10):
> [com.alcatel_lucent.samples.multiversion.implv2.ServiceImpl] Locating method
> activate in class java.lang.Object
> DEBUG: com.alcatel_lucent.samples.multiversion2.0.0 (10):
> [com.alcatel_lucent.samples.multiversion.implv2.ServiceImpl] Declared Method
> java.lang.Object.activate([interface
> org.osgi.service.component.ComponentContext]) not found
> DEBUG: com.alcatel_lucent.samples.multiversion2.0.0 (10):
> [com.alcatel_lucent.samples.multiversion.implv2.ServiceImpl] activate method
> [activate] not found, ignoring
> DEBUG: com.alcatel_lucent.samples.multiversion2.0.0 (10):
> [com.alcatel_lucent.samples.multiversion.implv2.ServiceImpl] State
> transition : Registered -> Active
> ERROR: com.alcatel_lucent.samples.multiversion.client1.0.0 (11):
> [com.alcatel_lucent.samples.multiversion.client.Client] The bindService
> method has thrown an exception
> java.lang.IllegalArgumentException: argument type mismatch
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:227)
>         at
> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38)
>         at
> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:591)
>         at
> org.apache.felix.scr.impl.helper.BaseMethod$NotResolved.invoke(BaseMethod.java:548)
>         at
> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:472)
>         at
> org.apache.felix.scr.impl.manager.DependencyManager.invokeBindMethod(DependencyManager.java:1028)
>         at
> org.apache.felix.scr.impl.manager.DependencyManager.bind(DependencyManager.java:944)
>         at
> org.apache.felix.scr.impl.manager.DependencyManager.open(DependencyManager.java:868)
>         at
> org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:200)
>         at
> org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118)
>         at
> org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:997)
>         at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:333)
>         at
> org.apache.felix.scr.impl.manager.DependencyManager.serviceAdded(DependencyManager.java:283)
>         at
> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:170)
>         at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:864)
>         at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
>         at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
> 
> 
> Did I come across I bug ?
> Indeed, so far, I was thinking that SCR does not inject a Service whose
> class loader is not compatible with the requesting client ?
> Am I correct ? or should my two Services be provided with a specific service
> property, in order to distinguish the two versions ?
> I mean: should the client do a Reference with a filter like
> "(serviceVersion=2.0.0)" ?
> 
> 
> Thanks in advance;
> /pierre
> 

Mime
View raw message