Hi, On 13.08.2010 17:11, Pierre De Rop wrote: > Hi Felix, > > Thanks for your quick response. > I tested also with scr 1.2.0 (and 1.4.0), and it seems that I still have the
Bad- but somewhat glad its not a new issue. > same problem: > > 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 could not be called > 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:213) > 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:542) > at > org.apache.felix.scr.impl.helper.BaseMethod$NotResolved.invoke(BaseMethod.java:500) > at > org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434) > at > org.apache.felix.scr.impl.manager.DependencyManager.invokeBindMethod(DependencyManager.java:948) > at > org.apache.felix.scr.impl.manager.DependencyManager.bind(DependencyManager.java:884) > at > org.apache.felix.scr.impl.manager.DependencyManager.open(DependencyManager.java:808) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:199) > > > > May I post a jira issue in order to attach my sample code ? In this way you > could then have a look at what I am testing ? Yes, that would be nice. Thanks. Regards Felix > > thanks > > > > On Fri, Aug 13, 2010 at 4:55 PM, Felix Meschberger <fmesc...@gmail.com>wrote: > >> 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 >>> >> >
