RE: iPojo inner class instrumentation
Hi Clément, We tried to execute your sample in our environment: it produced the same error described below. We just modified a little your sources to make them run: we add a C4 Bundle that contains an iPojo instance that calls C3 getFilter() method in its validate callback. We created one OSGi Bundle per component. You can find these 4 OSGi Bundles in attachments. Can you try to do following: - start the 4 Bundles (C4 validate callback is correctly called) - My filter ... called is produced in standard output - stop C1 and C2 Bundles - restart C1 and C2 Bundles - validate callback is not correctly called - only My filter ... is produced in standard output and the stacktrace below is produced Thanks Olivier -Message d'origine- De : Clement Escoffier [mailto:clement.escoff...@gmail.com] Envoyé : vendredi 28 janvier 2011 17:28 À : Apache Felix - Users Mailing List Objet : Re: iPojo inner class instrumentation Hi, Invalid Bundle Context means that the bundle is stopping or already stopped, and so is not able to access the service registry anymore. Is it your case? Regards, Clement On 28.01.11 17:11, Bigard Olivier obig...@axway.com wrote: Hi Clément, Sorry to answer so late, but we just test your proposal. We tried to disable proxy on C2 as suggested below, but no positive effect. After that we tried to test our use-case with last 1.8.0 iPojo version. We still had an exception, but with more information. Here it is: java.lang.IllegalStateException: Cannot create the Nullable object, an unexpected error occurs: Invalid BundleContext. at org.apache.felix.ipojo.handlers.dependency.Dependency.createNullableObject (Dependency.java:377) at org.apache.felix.ipojo.handlers.dependency.Dependency.createServiceObject( Dependency.java:656) at org.apache.felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.jav a:632) at org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:1035) at c4z.usecase.consumer.UseCaseConsumer.__getprovider(UseCaseConsumer.java) at c4z.usecase.consumer.UseCaseConsumer.__authenticate(UseCaseConsumer.java:3 7) at c4z.usecase.consumer.UseCaseConsumer.authenticate(UseCaseConsumer.java) at c4z.usecase.rest.RestApiProviderKO$1.authenticate(RestApiProviderKO.java:6 7) at c4z.usecase.rest.MyRestApiListener.__addApi(MyRestApiListener.java:49) at c4z.usecase.rest.MyRestApiListener.addApi(MyRestApiListener.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.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(Depende ncyCallback.java:237) at org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Depen dency.java:312) at org.apache.felix.ipojo.handlers.dependency.Dependency.callBindMethod(Depen dency.java:354) at org.apache.felix.ipojo.handlers.dependency.Dependency.onServiceArrival(Dep endency.java:475) at org.apache.felix.ipojo.util.DependencyModel.manageArrival(DependencyModel. java:392) at org.apache.felix.ipojo.util.DependencyModel.addedService(DependencyModel.j ava:335) at org.apache.felix.ipojo.util.Tracker$Tracked.trackAdding(Tracker.java:725) at org.apache.felix.ipojo.util.Tracker$Tracked.track(Tracker.java:686) at org.apache.felix.ipojo.util.Tracker$Tracked.serviceChanged(Tracker.java:64 7) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallb ack(EventDispatcher.java:864) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Event Dispatcher.java:732) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDisp atcher.java:662) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3726) at org.apache.felix.framework.Felix.access$000(Felix.java:80) at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:717) at org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry .java:107) at org.apache.felix.framework.Felix.registerService(Felix.java:2847) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContext Impl.java:251) at org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:338
RE: iPojo inner class instrumentation
Sorry, here are the attachments... http://old.nabble.com/file/p30806605/ipojo.testcase.C1-0.0.1-SNAPSHOT.jar ipojo.testcase.C1-0.0.1-SNAPSHOT.jar http://old.nabble.com/file/p30806605/ipojo.testcase.C2-0.0.1-SNAPSHOT.jar ipojo.testcase.C2-0.0.1-SNAPSHOT.jar http://old.nabble.com/file/p30806605/ipojo.testcase.C3-0.0.1-SNAPSHOT.jar ipojo.testcase.C3-0.0.1-SNAPSHOT.jar http://old.nabble.com/file/p30806605/ipojo.testcase.C4-0.0.1-SNAPSHOT.jar ipojo.testcase.C4-0.0.1-SNAPSHOT.jar Olivier Bigard wrote: Hi Clément, We tried to execute your sample in our environment: it produced the same error described below. We just modified a little your sources to make them run: we add a C4 Bundle that contains an iPojo instance that calls C3 getFilter() method in its validate callback. We created one OSGi Bundle per component. You can find these 4 OSGi Bundles in attachments. Can you try to do following: - start the 4 Bundles (C4 validate callback is correctly called) - My filter ... called is produced in standard output - stop C1 and C2 Bundles - restart C1 and C2 Bundles - validate callback is not correctly called - only My filter ... is produced in standard output and the stacktrace below is produced Thanks Olivier -Message d'origine- De : Clement Escoffier [mailto:clement.escoff...@gmail.com] Envoyé : vendredi 28 janvier 2011 17:28 À : Apache Felix - Users Mailing List Objet : Re: iPojo inner class instrumentation Hi, Invalid Bundle Context means that the bundle is stopping or already stopped, and so is not able to access the service registry anymore. Is it your case? Regards, Clement On 28.01.11 17:11, Bigard Olivier obig...@axway.com wrote: Hi Clément, Sorry to answer so late, but we just test your proposal. We tried to disable proxy on C2 as suggested below, but no positive effect. After that we tried to test our use-case with last 1.8.0 iPojo version. We still had an exception, but with more information. Here it is: java.lang.IllegalStateException: Cannot create the Nullable object, an unexpected error occurs: Invalid BundleContext. at org.apache.felix.ipojo.handlers.dependency.Dependency.createNullableObject (Dependency.java:377) at org.apache.felix.ipojo.handlers.dependency.Dependency.createServiceObject( Dependency.java:656) at org.apache.felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.jav a:632) at org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:1035) at c4z.usecase.consumer.UseCaseConsumer.__getprovider(UseCaseConsumer.java) at c4z.usecase.consumer.UseCaseConsumer.__authenticate(UseCaseConsumer.java:3 7) at c4z.usecase.consumer.UseCaseConsumer.authenticate(UseCaseConsumer.java) at c4z.usecase.rest.RestApiProviderKO$1.authenticate(RestApiProviderKO.java:6 7) at c4z.usecase.rest.MyRestApiListener.__addApi(MyRestApiListener.java:49) at c4z.usecase.rest.MyRestApiListener.addApi(MyRestApiListener.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.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(Depende ncyCallback.java:237) at org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Depen dency.java:312) at org.apache.felix.ipojo.handlers.dependency.Dependency.callBindMethod(Depen dency.java:354) at org.apache.felix.ipojo.handlers.dependency.Dependency.onServiceArrival(Dep endency.java:475) at org.apache.felix.ipojo.util.DependencyModel.manageArrival(DependencyModel. java:392) at org.apache.felix.ipojo.util.DependencyModel.addedService(DependencyModel.j ava:335) at org.apache.felix.ipojo.util.Tracker$Tracked.trackAdding(Tracker.java:725) at org.apache.felix.ipojo.util.Tracker$Tracked.track(Tracker.java:686) at org.apache.felix.ipojo.util.Tracker$Tracked.serviceChanged(Tracker.java:64 7) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallb ack(EventDispatcher.java:864) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Event Dispatcher.java:732) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDisp atcher.java:662) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3726) at org.apache.felix.framework.Felix.access$000
RE: iPojo inner class instrumentation
)
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:494)
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
at
org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:471)
at
org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:353)
at
org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:166)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:301)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:238)
at
org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:634)
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1460)
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
Maybe the Invalid BundleContext is the cause of our problem?
We will test the use-case you mentioned below in our environment to check if
it's working.
Thanks,
Olivier
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 16:38
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hi,
I've tried to reproduce your scenario in:
http://svn.apache.org/viewvc?view=revisionrevision=1045175
However, it works for me. I just remove C4 and directly call C3. Could you
highlight the differences ?
Regards,
Clement
On 13.12.10 16:07, Bigard Olivier obig...@axway.com wrote:
Ok, I'll check with disabled proxy on C2.
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 15:57
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hi,
Just a quick check,
Could you try to disable 'proxy' on c2
@Requires(proxy=false)
C2 c2;
Regards,
Clement
On 13.12.10 15:43, Bigard Olivier obig...@axway.com wrote:
Hi Clement,
We are using iPojo Core 1.6.4 (with Annotations).
We are also using the Maven plugin version 1.4.2. Maybe this version is
too old and there is a compatibility problem. I'll check with an earlier
version...
Regards,
Olivier
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 14:52
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hello,
On 13.12.10 11:41, Bigard Olivier obig...@axway.com wrote:
Hello,
We have an interrogation regarding iPojo instrumentation. We read
somewhere in the forum that iPopo can instrument inner classes, but we
are facing a problem when using them in our project.
Here is our use case:
A first component C1 provides a service with a method callMe().
Another component C2 requires this service.
Class C2
{
@Requires
Private C1 c1;
public boolean authenticate()
{
c1.callMe();
return true;
}
}
A third component C3 requires the component C2. This component C2 is
used inside an inner class MyFilter.
Class C3
{
@Requires
private C2 c2;
@Override
public MyFilter getFilter()
{
return new MyFilter()
{
@Override
public boolean authenticate()
{
return c2.authenticate();
}
};
}
}
At last, a component C4 listens for arrival and removal of C3 component
instances with @Bind/@Unbind methods.
Class C4
{
@Requires(id = apis, optional = true)
C3[] apis;
@Bind(id = apis)
public void addApi(ServiceReference ref)
{
C3 api = (C3) bundleCtxt.getService(ref);
filter = api.getFilter();
filter.authenticate();
}
}
Everything works perfectly the first time all the components are
started. But when we stop and restart the C1 and C2 instances, a
NullPointerException occurs when calling the method authenticate() of
the C2 component, because c1 is null. All the iPojo are present and
valid after the restart, but it seems c1 reference is not updated in c2.
We manage to make it work by modifiying a little bit the getFilter()
implementation in the C3 component:
Class C3
{
public MyFilter getFilter()
{
return new MyFilterImpl(c2);
}
}
where MyFilterImpl is an implementation of the MyFilter interface.
Does it trouble iPojo instrumentation when we instantiate inner classes
like we do or are we misusing iPojo in another way ?
Normally this should work, but I will test it because it looks pretty
strange.
Which version of iPOJO and of the manipulator are you using?
Regards,
Clement
Thanks
Olivier
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail
Re: iPojo inner class instrumentation
)
at
org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:338)
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedService.registerSe
rvice(ProvidedService.java:345)
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__s
tateChanged(ProvidedServiceHandler.java:494)
at
org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.sta
teChanged(ProvidedServiceHandler.java)
at
org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:471)
at
org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:353)
at
org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.ja
va:166)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.j
ava:301)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.j
ava:238)
at
org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:634)
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(Conf
igurationManager.java:1460)
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
Maybe the Invalid BundleContext is the cause of our problem?
We will test the use-case you mentioned below in our environment to check
if it's working.
Thanks,
Olivier
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 16:38
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hi,
I've tried to reproduce your scenario in:
http://svn.apache.org/viewvc?view=revisionrevision=1045175
However, it works for me. I just remove C4 and directly call C3. Could you
highlight the differences ?
Regards,
Clement
On 13.12.10 16:07, Bigard Olivier obig...@axway.com wrote:
Ok, I'll check with disabled proxy on C2.
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 15:57
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hi,
Just a quick check,
Could you try to disable 'proxy' on c2
@Requires(proxy=false)
C2 c2;
Regards,
Clement
On 13.12.10 15:43, Bigard Olivier obig...@axway.com wrote:
Hi Clement,
We are using iPojo Core 1.6.4 (with Annotations).
We are also using the Maven plugin version 1.4.2. Maybe this version is
too old and there is a compatibility problem. I'll check with an earlier
version...
Regards,
Olivier
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 14:52
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hello,
On 13.12.10 11:41, Bigard Olivier obig...@axway.com wrote:
Hello,
We have an interrogation regarding iPojo instrumentation. We read
somewhere in the forum that iPopo can instrument inner classes, but we
are facing a problem when using them in our project.
Here is our use case:
A first component C1 provides a service with a method callMe().
Another component C2 requires this service.
Class C2
{
@Requires
Private C1 c1;
public boolean authenticate()
{
c1.callMe();
return true;
}
}
A third component C3 requires the component C2. This component C2 is
used inside an inner class MyFilter.
Class C3
{
@Requires
private C2 c2;
@Override
public MyFilter getFilter()
{
return new MyFilter()
{
@Override
public boolean authenticate()
{
return c2.authenticate();
}
};
}
}
At last, a component C4 listens for arrival and removal of C3 component
instances with @Bind/@Unbind methods.
Class C4
{
@Requires(id = apis, optional = true)
C3[] apis;
@Bind(id = apis)
public void addApi(ServiceReference ref)
{
C3 api = (C3) bundleCtxt.getService(ref);
filter = api.getFilter();
filter.authenticate();
}
}
Everything works perfectly the first time all the components are
started. But when we stop and restart the C1 and C2 instances, a
NullPointerException occurs when calling the method authenticate() of
the C2 component, because c1 is null. All the iPojo are present and
valid after the restart, but it seems c1 reference is not updated in
c2.
We manage to make it work by modifiying a little bit the getFilter()
implementation in the C3 component:
Class C3
{
public MyFilter getFilter()
{
return new MyFilterImpl(c2);
}
}
where MyFilterImpl is an implementation of the MyFilter interface.
Does it trouble iPojo instrumentation when we instantiate inner classes
like we do or are we misusing iPojo in another way ?
Normally this should work, but I will test it because it looks pretty
strange.
Which version of iPOJO and of the manipulator are you using
RE: iPojo inner class instrumentation
We just checked: the Bundle is correctly and fully started when have the error... One more information: we also have the following WARNING trace in standard output: [WARNING] : [UseCaseConsumer.fdff9a89-3437-4b28-90ff-64f7a51ce77e] The dependency is not optional, however no service object can be injected in provider - c4z.usecase.provider.UseCaseProviderApi -Message d'origine- De : Clement Escoffier [mailto:clement.escoff...@gmail.com] Envoyé : vendredi 28 janvier 2011 17:28 À : Apache Felix - Users Mailing List Objet : Re: iPojo inner class instrumentation Hi, Invalid Bundle Context means that the bundle is stopping or already stopped, and so is not able to access the service registry anymore. Is it your case? Regards, Clement On 28.01.11 17:11, Bigard Olivier obig...@axway.com wrote: Hi Clément, Sorry to answer so late, but we just test your proposal. We tried to disable proxy on C2 as suggested below, but no positive effect. After that we tried to test our use-case with last 1.8.0 iPojo version. We still had an exception, but with more information. Here it is: java.lang.IllegalStateException: Cannot create the Nullable object, an unexpected error occurs: Invalid BundleContext. at org.apache.felix.ipojo.handlers.dependency.Dependency.createNullableObject (Dependency.java:377) at org.apache.felix.ipojo.handlers.dependency.Dependency.createServiceObject( Dependency.java:656) at org.apache.felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.jav a:632) at org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:1035) at c4z.usecase.consumer.UseCaseConsumer.__getprovider(UseCaseConsumer.java) at c4z.usecase.consumer.UseCaseConsumer.__authenticate(UseCaseConsumer.java:3 7) at c4z.usecase.consumer.UseCaseConsumer.authenticate(UseCaseConsumer.java) at c4z.usecase.rest.RestApiProviderKO$1.authenticate(RestApiProviderKO.java:6 7) at c4z.usecase.rest.MyRestApiListener.__addApi(MyRestApiListener.java:49) at c4z.usecase.rest.MyRestApiListener.addApi(MyRestApiListener.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.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(Depende ncyCallback.java:237) at org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Depen dency.java:312) at org.apache.felix.ipojo.handlers.dependency.Dependency.callBindMethod(Depen dency.java:354) at org.apache.felix.ipojo.handlers.dependency.Dependency.onServiceArrival(Dep endency.java:475) at org.apache.felix.ipojo.util.DependencyModel.manageArrival(DependencyModel. java:392) at org.apache.felix.ipojo.util.DependencyModel.addedService(DependencyModel.j ava:335) at org.apache.felix.ipojo.util.Tracker$Tracked.trackAdding(Tracker.java:725) at org.apache.felix.ipojo.util.Tracker$Tracked.track(Tracker.java:686) at org.apache.felix.ipojo.util.Tracker$Tracked.serviceChanged(Tracker.java:64 7) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallb ack(EventDispatcher.java:864) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Event Dispatcher.java:732) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDisp atcher.java:662) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3726) at org.apache.felix.framework.Felix.access$000(Felix.java:80) at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:717) at org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry .java:107) at org.apache.felix.framework.Felix.registerService(Felix.java:2847) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContext Impl.java:251) at org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:338) at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.registerSe rvice(ProvidedService.java:345) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__s tateChanged(ProvidedServiceHandler.java:494) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.sta teChanged(ProvidedServiceHandler.java
Re: iPojo inner class instrumentation
Hello,
On 13.12.10 11:41, Bigard Olivier obig...@axway.com wrote:
Hello,
We have an interrogation regarding iPojo instrumentation. We read
somewhere in the forum that iPopo can instrument inner classes, but we
are facing a problem when using them in our project.
Here is our use case:
A first component C1 provides a service with a method callMe().
Another component C2 requires this service.
Class C2
{
@Requires
Private C1 c1;
public boolean authenticate()
{
c1.callMe();
return true;
}
}
A third component C3 requires the component C2. This component C2 is
used inside an inner class MyFilter.
Class C3
{
@Requires
private C2 c2;
@Override
public MyFilter getFilter()
{
return new MyFilter()
{
@Override
public boolean authenticate()
{
return c2.authenticate();
}
};
}
}
At last, a component C4 listens for arrival and removal of C3 component
instances with @Bind/@Unbind methods.
Class C4
{
@Requires(id = apis, optional = true)
C3[] apis;
@Bind(id = apis)
public void addApi(ServiceReference ref)
{
C3 api = (C3) bundleCtxt.getService(ref);
filter = api.getFilter();
filter.authenticate();
}
}
Everything works perfectly the first time all the components are
started. But when we stop and restart the C1 and C2 instances, a
NullPointerException occurs when calling the method authenticate() of
the C2 component, because c1 is null. All the iPojo are present and
valid after the restart, but it seems c1 reference is not updated in c2.
We manage to make it work by modifiying a little bit the getFilter()
implementation in the C3 component:
Class C3
{
public MyFilter getFilter()
{
return new MyFilterImpl(c2);
}
}
where MyFilterImpl is an implementation of the MyFilter interface.
Does it trouble iPojo instrumentation when we instantiate inner classes
like we do or are we misusing iPojo in another way ?
Normally this should work, but I will test it because it looks pretty
strange.
Which version of iPOJO and of the manipulator are you using?
Regards,
Clement
Thanks
Olivier
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
RE: iPojo inner class instrumentation
Hi Clement,
We are using iPojo Core 1.6.4 (with Annotations).
We are also using the Maven plugin version 1.4.2. Maybe this version is too old
and there is a compatibility problem. I'll check with an earlier version...
Regards,
Olivier
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 14:52
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hello,
On 13.12.10 11:41, Bigard Olivier obig...@axway.com wrote:
Hello,
We have an interrogation regarding iPojo instrumentation. We read
somewhere in the forum that iPopo can instrument inner classes, but we
are facing a problem when using them in our project.
Here is our use case:
A first component C1 provides a service with a method callMe().
Another component C2 requires this service.
Class C2
{
@Requires
Private C1 c1;
public boolean authenticate()
{
c1.callMe();
return true;
}
}
A third component C3 requires the component C2. This component C2 is
used inside an inner class MyFilter.
Class C3
{
@Requires
private C2 c2;
@Override
public MyFilter getFilter()
{
return new MyFilter()
{
@Override
public boolean authenticate()
{
return c2.authenticate();
}
};
}
}
At last, a component C4 listens for arrival and removal of C3 component
instances with @Bind/@Unbind methods.
Class C4
{
@Requires(id = apis, optional = true)
C3[] apis;
@Bind(id = apis)
public void addApi(ServiceReference ref)
{
C3 api = (C3) bundleCtxt.getService(ref);
filter = api.getFilter();
filter.authenticate();
}
}
Everything works perfectly the first time all the components are
started. But when we stop and restart the C1 and C2 instances, a
NullPointerException occurs when calling the method authenticate() of
the C2 component, because c1 is null. All the iPojo are present and
valid after the restart, but it seems c1 reference is not updated in c2.
We manage to make it work by modifiying a little bit the getFilter()
implementation in the C3 component:
Class C3
{
public MyFilter getFilter()
{
return new MyFilterImpl(c2);
}
}
where MyFilterImpl is an implementation of the MyFilter interface.
Does it trouble iPojo instrumentation when we instantiate inner classes
like we do or are we misusing iPojo in another way ?
Normally this should work, but I will test it because it looks pretty
strange.
Which version of iPOJO and of the manipulator are you using?
Regards,
Clement
Thanks
Olivier
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: iPojo inner class instrumentation
Hi,
Just a quick check,
Could you try to disable 'proxy' on c2
@Requires(proxy=false)
C2 c2;
Regards,
Clement
On 13.12.10 15:43, Bigard Olivier obig...@axway.com wrote:
Hi Clement,
We are using iPojo Core 1.6.4 (with Annotations).
We are also using the Maven plugin version 1.4.2. Maybe this version is
too old and there is a compatibility problem. I'll check with an earlier
version...
Regards,
Olivier
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 14:52
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hello,
On 13.12.10 11:41, Bigard Olivier obig...@axway.com wrote:
Hello,
We have an interrogation regarding iPojo instrumentation. We read
somewhere in the forum that iPopo can instrument inner classes, but we
are facing a problem when using them in our project.
Here is our use case:
A first component C1 provides a service with a method callMe().
Another component C2 requires this service.
Class C2
{
@Requires
Private C1 c1;
public boolean authenticate()
{
c1.callMe();
return true;
}
}
A third component C3 requires the component C2. This component C2 is
used inside an inner class MyFilter.
Class C3
{
@Requires
private C2 c2;
@Override
public MyFilter getFilter()
{
return new MyFilter()
{
@Override
public boolean authenticate()
{
return c2.authenticate();
}
};
}
}
At last, a component C4 listens for arrival and removal of C3 component
instances with @Bind/@Unbind methods.
Class C4
{
@Requires(id = apis, optional = true)
C3[] apis;
@Bind(id = apis)
public void addApi(ServiceReference ref)
{
C3 api = (C3) bundleCtxt.getService(ref);
filter = api.getFilter();
filter.authenticate();
}
}
Everything works perfectly the first time all the components are
started. But when we stop and restart the C1 and C2 instances, a
NullPointerException occurs when calling the method authenticate() of
the C2 component, because c1 is null. All the iPojo are present and
valid after the restart, but it seems c1 reference is not updated in c2.
We manage to make it work by modifiying a little bit the getFilter()
implementation in the C3 component:
Class C3
{
public MyFilter getFilter()
{
return new MyFilterImpl(c2);
}
}
where MyFilterImpl is an implementation of the MyFilter interface.
Does it trouble iPojo instrumentation when we instantiate inner classes
like we do or are we misusing iPojo in another way ?
Normally this should work, but I will test it because it looks pretty
strange.
Which version of iPOJO and of the manipulator are you using?
Regards,
Clement
Thanks
Olivier
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
RE: iPojo inner class instrumentation
Ok, I'll check with disabled proxy on C2.
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 15:57
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hi,
Just a quick check,
Could you try to disable 'proxy' on c2
@Requires(proxy=false)
C2 c2;
Regards,
Clement
On 13.12.10 15:43, Bigard Olivier obig...@axway.com wrote:
Hi Clement,
We are using iPojo Core 1.6.4 (with Annotations).
We are also using the Maven plugin version 1.4.2. Maybe this version is
too old and there is a compatibility problem. I'll check with an earlier
version...
Regards,
Olivier
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 14:52
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hello,
On 13.12.10 11:41, Bigard Olivier obig...@axway.com wrote:
Hello,
We have an interrogation regarding iPojo instrumentation. We read
somewhere in the forum that iPopo can instrument inner classes, but we
are facing a problem when using them in our project.
Here is our use case:
A first component C1 provides a service with a method callMe().
Another component C2 requires this service.
Class C2
{
@Requires
Private C1 c1;
public boolean authenticate()
{
c1.callMe();
return true;
}
}
A third component C3 requires the component C2. This component C2 is
used inside an inner class MyFilter.
Class C3
{
@Requires
private C2 c2;
@Override
public MyFilter getFilter()
{
return new MyFilter()
{
@Override
public boolean authenticate()
{
return c2.authenticate();
}
};
}
}
At last, a component C4 listens for arrival and removal of C3 component
instances with @Bind/@Unbind methods.
Class C4
{
@Requires(id = apis, optional = true)
C3[] apis;
@Bind(id = apis)
public void addApi(ServiceReference ref)
{
C3 api = (C3) bundleCtxt.getService(ref);
filter = api.getFilter();
filter.authenticate();
}
}
Everything works perfectly the first time all the components are
started. But when we stop and restart the C1 and C2 instances, a
NullPointerException occurs when calling the method authenticate() of
the C2 component, because c1 is null. All the iPojo are present and
valid after the restart, but it seems c1 reference is not updated in c2.
We manage to make it work by modifiying a little bit the getFilter()
implementation in the C3 component:
Class C3
{
public MyFilter getFilter()
{
return new MyFilterImpl(c2);
}
}
where MyFilterImpl is an implementation of the MyFilter interface.
Does it trouble iPojo instrumentation when we instantiate inner classes
like we do or are we misusing iPojo in another way ?
Normally this should work, but I will test it because it looks pretty
strange.
Which version of iPOJO and of the manipulator are you using?
Regards,
Clement
Thanks
Olivier
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: iPojo inner class instrumentation
Hi,
I've tried to reproduce your scenario in:
http://svn.apache.org/viewvc?view=revisionrevision=1045175
However, it works for me. I just remove C4 and directly call C3. Could you
highlight the differences ?
Regards,
Clement
On 13.12.10 16:07, Bigard Olivier obig...@axway.com wrote:
Ok, I'll check with disabled proxy on C2.
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 15:57
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hi,
Just a quick check,
Could you try to disable 'proxy' on c2
@Requires(proxy=false)
C2 c2;
Regards,
Clement
On 13.12.10 15:43, Bigard Olivier obig...@axway.com wrote:
Hi Clement,
We are using iPojo Core 1.6.4 (with Annotations).
We are also using the Maven plugin version 1.4.2. Maybe this version is
too old and there is a compatibility problem. I'll check with an earlier
version...
Regards,
Olivier
-Message d'origine-
De : Clement Escoffier [mailto:clement.escoff...@gmail.com]
Envoyé : lundi 13 décembre 2010 14:52
À : users@felix.apache.org
Objet : Re: iPojo inner class instrumentation
Hello,
On 13.12.10 11:41, Bigard Olivier obig...@axway.com wrote:
Hello,
We have an interrogation regarding iPojo instrumentation. We read
somewhere in the forum that iPopo can instrument inner classes, but we
are facing a problem when using them in our project.
Here is our use case:
A first component C1 provides a service with a method callMe().
Another component C2 requires this service.
Class C2
{
@Requires
Private C1 c1;
public boolean authenticate()
{
c1.callMe();
return true;
}
}
A third component C3 requires the component C2. This component C2 is
used inside an inner class MyFilter.
Class C3
{
@Requires
private C2 c2;
@Override
public MyFilter getFilter()
{
return new MyFilter()
{
@Override
public boolean authenticate()
{
return c2.authenticate();
}
};
}
}
At last, a component C4 listens for arrival and removal of C3 component
instances with @Bind/@Unbind methods.
Class C4
{
@Requires(id = apis, optional = true)
C3[] apis;
@Bind(id = apis)
public void addApi(ServiceReference ref)
{
C3 api = (C3) bundleCtxt.getService(ref);
filter = api.getFilter();
filter.authenticate();
}
}
Everything works perfectly the first time all the components are
started. But when we stop and restart the C1 and C2 instances, a
NullPointerException occurs when calling the method authenticate() of
the C2 component, because c1 is null. All the iPojo are present and
valid after the restart, but it seems c1 reference is not updated in c2.
We manage to make it work by modifiying a little bit the getFilter()
implementation in the C3 component:
Class C3
{
public MyFilter getFilter()
{
return new MyFilterImpl(c2);
}
}
where MyFilterImpl is an implementation of the MyFilter interface.
Does it trouble iPojo instrumentation when we instantiate inner classes
like we do or are we misusing iPojo in another way ?
Normally this should work, but I will test it because it looks pretty
strange.
Which version of iPOJO and of the manipulator are you using?
Regards,
Clement
Thanks
Olivier
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
