You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Gay David (Annecy)" <dg...@axway.com> on 2011/06/08 12:07:57 UTC
iPojo and @Modified
Hi all,
While working with iPojo, I found a strange behaviors.
I've attach a small sample to illustrate what's happen.
The strange behaviors I found is on the @Modified callback.
When a new instance is created, the @Modified callback is called just after the @Bind, I think it should not because it's the first time init and not a modification of a already create service. This can be seen on my sample :
-> modified create foo1 foo2
DummyServiceImpl.updated foo1 / foo2
DummyServiceImpl.validate foo1 / foo2
Bind : DoIt -> foo1 / foo2
Modified : DoIt -> foo1 / foo2
DummyServiceImpl.postRegistration foo1 / foo2
As you see the Modified method is call just after the bind.
The other problem is when there is a reconfiguration : the @Modified callback is called twice. This can be seen on my sample :
-> modified update foo10 foo20
Modified : DoIt -> foo10 / foo20
Modified : DoIt -> foo10 / foo20
DummyServiceImpl.updated foo10 / foo20
As you see the Modified method is call twice. Also note that the updated is call at the end, I'm wondering if it's normal or not. If you need to change some internal state in the service when configuration change, it's too late for the ones that uses the service. But maybe it's a normal behavior and in this case, a @PreUpdated callback would be useful.
By looking at the stack trace when the method @Modified is called, it may be the Felix framework that is responsible ?
Modified : DoIt -> foo10 / foo20
at test.ipojo.modified.DummyServiceTester.__modifiedControlService(DummyServiceTester.java:106)
at test.ipojo.modified.DummyServiceTester.modifiedControlService(DummyServiceTester.java)
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.ipojo.util.Callback.call(Callback.java:237)
at org.apache.felix.ipojo.handlers.dependency.DependencyCallback.call(DependencyCallback.java:244)
at org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Dependency.java:312)
at org.apache.felix.ipojo.handlers.dependency.Dependency.callModifyMethod(Dependency.java:337)
at org.apache.felix.ipojo.handlers.dependency.Dependency.onServiceModification(Dependency.java:485)
at org.apache.felix.ipojo.util.DependencyModel.manageModification(DependencyModel.java:615)
at org.apache.felix.ipojo.util.DependencyModel.modifiedService(DependencyModel.java:497)
at org.apache.felix.ipojo.util.Tracker$Tracked.track(Tracker.java:676)
at org.apache.felix.ipojo.util.Tracker$Tracked.serviceChanged(Tracker.java:647)
at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733)
at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3890)
at org.apache.felix.framework.Felix.access$000(Felix.java:79)
at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:728)
at org.apache.felix.framework.ServiceRegistry.servicePropertiesModified(ServiceRegistry.java:480)
at org.apache.felix.framework.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:116)
at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.update(ProvidedService.java:447)
at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__addProperties(ProvidedServiceHandler.java:507)
at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.addProperties(ProvidedServiceHandler.java)
at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.__propagate(ConfigurationHandler.java:479)
at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.propagate(ConfigurationHandler.java)
at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.__reconfigure(ConfigurationHandler.java:396)
at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.reconfigure(ConfigurationHandler.java)
at org.apache.felix.ipojo.InstanceManager.reconfigure(InstanceManager.java:1252)
at test.ipojo.modified.DummyServiceTester.__execute(DummyServiceTester.java:82)
at test.ipojo.modified.DummyServiceTester.execute(DummyServiceTester.java)
at org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:286)
at org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:184)
at java.lang.Thread.run(Thread.java:662)
PS : I use iPojo 1.8.0, but same behavior with iPojo 1.6.x
Thanks for your help
Regards
David
Re: iPojo and @Modified
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 13.06.2011, at 18:20, Gay David (Annecy) wrote:
> Hi Clement,
>
> I understand that @Modified callback is call when a modification is done on :
>
> * a @ServiceProperty
> * and also a @Property, if and only if, the attribute "propagation=true" on the @Component annotation is set : that's why on my test class [DummyServiceImpl] I put it.
@Property are never propagated, only properties from the configuration that does not match any @Property are propagated. If you want to propagate a @Property, just add @ServiceProperty.
Moreover, propagation is now enabled by default.
Regards,
Clement
>
> But, this is what I understand from the iPojo documentation, and I may have misunderstood the "propagation" concept !
> Can you confirm me this behavior ?
>
> Thanks again for you help
>
> Regards,
> David
>
>
> -----Message d'origine-----
> De : Clement Escoffier [mailto:clement.escoffier@gmail.com]
> Envoyé : lundi 13 juin 2011 12:16
> À : users@felix.apache.org
> Objet : Re: iPojo and @Modified
>
> Hi,
>
> The interesting thing is your case it that @Modified should not be called at all, as your properties are not service properties. In fact, I just fixed a bug triggering updates every time the instance is reconfigured regardless there are changes or not (https://issues.apache.org/jira/browse/FELIX-2995). Now, this should not happen anymore, updates are triggered only when the published properties are really changed.
>
> Regards,
>
> Clement
>
> On 08.06.2011, at 12:07, Gay David (Annecy) wrote:
>
>> Hi all,
>>
>> While working with iPojo, I found a strange behaviors.
>> I've attach a small sample to illustrate what's happen.
>>
>> The strange behaviors I found is on the @Modified callback.
>>
>> When a new instance is created, the @Modified callback is called just after the @Bind, I think it should not because it's the first time init and not a modification of a already create service. This can be seen on my sample :
>>
>> -> modified create foo1 foo2
>> DummyServiceImpl.updated foo1 / foo2
>> DummyServiceImpl.validate foo1 / foo2
>> Bind : DoIt -> foo1 / foo2
>> Modified : DoIt -> foo1 / foo2
>> DummyServiceImpl.postRegistration foo1 / foo2
>>
>> As you see the Modified method is call just after the bind.
>>
>> The other problem is when there is a reconfiguration : the @Modified callback is called twice. This can be seen on my sample :
>>
>> -> modified update foo10 foo20
>> Modified : DoIt -> foo10 / foo20
>> Modified : DoIt -> foo10 / foo20
>> DummyServiceImpl.updated foo10 / foo20
>>
>> As you see the Modified method is call twice. Also note that the updated is call at the end, I'm wondering if it's normal or not. If you need to change some internal state in the service when configuration change, it's too late for the ones that uses the service. But maybe it's a normal behavior and in this case, a @PreUpdated callback would be useful.
>>
>> By looking at the stack trace when the method @Modified is called, it may be the Felix framework that is responsible ?
>>
>> Modified : DoIt -> foo10 / foo20
>> at test.ipojo.modified.DummyServiceTester.__modifiedControlService(DummyServiceTester.java:106)
>> at test.ipojo.modified.DummyServiceTester.modifiedControlService(DummyServiceTester.java)
>> 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.ipojo.util.Callback.call(Callback.java:237)
>> at org.apache.felix.ipojo.handlers.dependency.DependencyCallback.call(DependencyCallback.java:244)
>> at org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Dependency.java:312)
>> at org.apache.felix.ipojo.handlers.dependency.Dependency.callModifyMethod(Dependency.java:337)
>> at org.apache.felix.ipojo.handlers.dependency.Dependency.onServiceModification(Dependency.java:485)
>> at org.apache.felix.ipojo.util.DependencyModel.manageModification(DependencyModel.java:615)
>> at org.apache.felix.ipojo.util.DependencyModel.modifiedService(DependencyModel.java:497)
>> at org.apache.felix.ipojo.util.Tracker$Tracked.track(Tracker.java:676)
>> at org.apache.felix.ipojo.util.Tracker$Tracked.serviceChanged(Tracker.java:647)
>> at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871)
>> at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733)
>> at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3890)
>> at org.apache.felix.framework.Felix.access$000(Felix.java:79)
>> at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:728)
>> at org.apache.felix.framework.ServiceRegistry.servicePropertiesModified(ServiceRegistry.java:480)
>> at org.apache.felix.framework.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:116)
>> at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.update(ProvidedService.java:447)
>> at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__addProperties(ProvidedServiceHandler.java:507)
>> at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.addProperties(ProvidedServiceHandler.java)
>> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.__propagate(ConfigurationHandler.java:479)
>> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.propagate(ConfigurationHandler.java)
>> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.__reconfigure(ConfigurationHandler.java:396)
>> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.reconfigure(ConfigurationHandler.java)
>> at org.apache.felix.ipojo.InstanceManager.reconfigure(InstanceManager.java:1252)
>> at test.ipojo.modified.DummyServiceTester.__execute(DummyServiceTester.java:82)
>> at test.ipojo.modified.DummyServiceTester.execute(DummyServiceTester.java)
>> at org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:286)
>> at org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:184)
>> at java.lang.Thread.run(Thread.java:662)
>>
>> PS : I use iPojo 1.8.0, but same behavior with iPojo 1.6.x
>>
>> Thanks for your help
>>
>> Regards
>> David
>>
>>
>>
>> <test.ipojo.modified.zip>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: iPojo and @Modified
Posted by "Gay David (Annecy)" <dg...@axway.com>.
Hi Clement,
I understand that @Modified callback is call when a modification is done on :
* a @ServiceProperty
* and also a @Property, if and only if, the attribute "propagation=true" on the @Component annotation is set : that's why on my test class [DummyServiceImpl] I put it.
But, this is what I understand from the iPojo documentation, and I may have misunderstood the "propagation" concept !
Can you confirm me this behavior ?
Thanks again for you help
Regards,
David
-----Message d'origine-----
De : Clement Escoffier [mailto:clement.escoffier@gmail.com]
Envoyé : lundi 13 juin 2011 12:16
À : users@felix.apache.org
Objet : Re: iPojo and @Modified
Hi,
The interesting thing is your case it that @Modified should not be called at all, as your properties are not service properties. In fact, I just fixed a bug triggering updates every time the instance is reconfigured regardless there are changes or not (https://issues.apache.org/jira/browse/FELIX-2995). Now, this should not happen anymore, updates are triggered only when the published properties are really changed.
Regards,
Clement
On 08.06.2011, at 12:07, Gay David (Annecy) wrote:
> Hi all,
>
> While working with iPojo, I found a strange behaviors.
> I've attach a small sample to illustrate what's happen.
>
> The strange behaviors I found is on the @Modified callback.
>
> When a new instance is created, the @Modified callback is called just after the @Bind, I think it should not because it's the first time init and not a modification of a already create service. This can be seen on my sample :
>
> -> modified create foo1 foo2
> DummyServiceImpl.updated foo1 / foo2
> DummyServiceImpl.validate foo1 / foo2
> Bind : DoIt -> foo1 / foo2
> Modified : DoIt -> foo1 / foo2
> DummyServiceImpl.postRegistration foo1 / foo2
>
> As you see the Modified method is call just after the bind.
>
> The other problem is when there is a reconfiguration : the @Modified callback is called twice. This can be seen on my sample :
>
> -> modified update foo10 foo20
> Modified : DoIt -> foo10 / foo20
> Modified : DoIt -> foo10 / foo20
> DummyServiceImpl.updated foo10 / foo20
>
> As you see the Modified method is call twice. Also note that the updated is call at the end, I'm wondering if it's normal or not. If you need to change some internal state in the service when configuration change, it's too late for the ones that uses the service. But maybe it's a normal behavior and in this case, a @PreUpdated callback would be useful.
>
> By looking at the stack trace when the method @Modified is called, it may be the Felix framework that is responsible ?
>
> Modified : DoIt -> foo10 / foo20
> at test.ipojo.modified.DummyServiceTester.__modifiedControlService(DummyServiceTester.java:106)
> at test.ipojo.modified.DummyServiceTester.modifiedControlService(DummyServiceTester.java)
> 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.ipojo.util.Callback.call(Callback.java:237)
> at org.apache.felix.ipojo.handlers.dependency.DependencyCallback.call(DependencyCallback.java:244)
> at org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Dependency.java:312)
> at org.apache.felix.ipojo.handlers.dependency.Dependency.callModifyMethod(Dependency.java:337)
> at org.apache.felix.ipojo.handlers.dependency.Dependency.onServiceModification(Dependency.java:485)
> at org.apache.felix.ipojo.util.DependencyModel.manageModification(DependencyModel.java:615)
> at org.apache.felix.ipojo.util.DependencyModel.modifiedService(DependencyModel.java:497)
> at org.apache.felix.ipojo.util.Tracker$Tracked.track(Tracker.java:676)
> at org.apache.felix.ipojo.util.Tracker$Tracked.serviceChanged(Tracker.java:647)
> at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871)
> at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733)
> at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3890)
> at org.apache.felix.framework.Felix.access$000(Felix.java:79)
> at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:728)
> at org.apache.felix.framework.ServiceRegistry.servicePropertiesModified(ServiceRegistry.java:480)
> at org.apache.felix.framework.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:116)
> at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.update(ProvidedService.java:447)
> at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__addProperties(ProvidedServiceHandler.java:507)
> at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.addProperties(ProvidedServiceHandler.java)
> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.__propagate(ConfigurationHandler.java:479)
> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.propagate(ConfigurationHandler.java)
> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.__reconfigure(ConfigurationHandler.java:396)
> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.reconfigure(ConfigurationHandler.java)
> at org.apache.felix.ipojo.InstanceManager.reconfigure(InstanceManager.java:1252)
> at test.ipojo.modified.DummyServiceTester.__execute(DummyServiceTester.java:82)
> at test.ipojo.modified.DummyServiceTester.execute(DummyServiceTester.java)
> at org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:286)
> at org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:184)
> at java.lang.Thread.run(Thread.java:662)
>
> PS : I use iPojo 1.8.0, but same behavior with iPojo 1.6.x
>
> Thanks for your help
>
> Regards
> David
>
>
>
> <test.ipojo.modified.zip>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo and @Modified
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
The interesting thing is your case it that @Modified should not be called at all, as your properties are not service properties. In fact, I just fixed a bug triggering updates every time the instance is reconfigured regardless there are changes or not (https://issues.apache.org/jira/browse/FELIX-2995). Now, this should not happen anymore, updates are triggered only when the published properties are really changed.
Regards,
Clement
On 08.06.2011, at 12:07, Gay David (Annecy) wrote:
> Hi all,
>
> While working with iPojo, I found a strange behaviors.
> I’ve attach a small sample to illustrate what’s happen.
>
> The strange behaviors I found is on the @Modified callback.
>
> When a new instance is created, the @Modified callback is called just after the @Bind, I think it should not because it’s the first time init and not a modification of a already create service. This can be seen on my sample :
>
> -> modified create foo1 foo2
> DummyServiceImpl.updated foo1 / foo2
> DummyServiceImpl.validate foo1 / foo2
> Bind : DoIt -> foo1 / foo2
> Modified : DoIt -> foo1 / foo2
> DummyServiceImpl.postRegistration foo1 / foo2
>
> As you see the Modified method is call just after the bind.
>
> The other problem is when there is a reconfiguration : the @Modified callback is called twice. This can be seen on my sample :
>
> -> modified update foo10 foo20
> Modified : DoIt -> foo10 / foo20
> Modified : DoIt -> foo10 / foo20
> DummyServiceImpl.updated foo10 / foo20
>
> As you see the Modified method is call twice. Also note that the updated is call at the end, I’m wondering if it’s normal or not. If you need to change some internal state in the service when configuration change, it’s too late for the ones that uses the service. But maybe it’s a normal behavior and in this case, a @PreUpdated callback would be useful.
>
> By looking at the stack trace when the method @Modified is called, it may be the Felix framework that is responsible ?
>
> Modified : DoIt -> foo10 / foo20
> at test.ipojo.modified.DummyServiceTester.__modifiedControlService(DummyServiceTester.java:106)
> at test.ipojo.modified.DummyServiceTester.modifiedControlService(DummyServiceTester.java)
> 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.ipojo.util.Callback.call(Callback.java:237)
> at org.apache.felix.ipojo.handlers.dependency.DependencyCallback.call(DependencyCallback.java:244)
> at org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Dependency.java:312)
> at org.apache.felix.ipojo.handlers.dependency.Dependency.callModifyMethod(Dependency.java:337)
> at org.apache.felix.ipojo.handlers.dependency.Dependency.onServiceModification(Dependency.java:485)
> at org.apache.felix.ipojo.util.DependencyModel.manageModification(DependencyModel.java:615)
> at org.apache.felix.ipojo.util.DependencyModel.modifiedService(DependencyModel.java:497)
> at org.apache.felix.ipojo.util.Tracker$Tracked.track(Tracker.java:676)
> at org.apache.felix.ipojo.util.Tracker$Tracked.serviceChanged(Tracker.java:647)
> at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871)
> at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733)
> at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3890)
> at org.apache.felix.framework.Felix.access$000(Felix.java:79)
> at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:728)
> at org.apache.felix.framework.ServiceRegistry.servicePropertiesModified(ServiceRegistry.java:480)
> at org.apache.felix.framework.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:116)
> at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.update(ProvidedService.java:447)
> at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__addProperties(ProvidedServiceHandler.java:507)
> at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.addProperties(ProvidedServiceHandler.java)
> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.__propagate(ConfigurationHandler.java:479)
> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.propagate(ConfigurationHandler.java)
> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.__reconfigure(ConfigurationHandler.java:396)
> at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.reconfigure(ConfigurationHandler.java)
> at org.apache.felix.ipojo.InstanceManager.reconfigure(InstanceManager.java:1252)
> at test.ipojo.modified.DummyServiceTester.__execute(DummyServiceTester.java:82)
> at test.ipojo.modified.DummyServiceTester.execute(DummyServiceTester.java)
> at org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:286)
> at org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:184)
> at java.lang.Thread.run(Thread.java:662)
>
> PS : I use iPojo 1.8.0, but same behavior with iPojo 1.6.x
>
> Thanks for your help
>
> Regards
> David
>
>
>
> <test.ipojo.modified.zip>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org