Re: @Requires : ServiceFactory.getService() resulted in a cycle.

[Clement Escoffier]

Hi,
On 23.09.2009, at 21:02, Joel Schuster wrote:

I'm beginning to understand just how much I don't understand.
Is there some documentation on how iPojo works? How factories are  
created and how instances are created? Esp. with how they work with  
FileInstaller? I'm stumped.

Factories and Instance : 
http://felix.apache.org/site/how-to-use-ipojo-factories.html

Well, the is two different layer:
component factories create component instances
component instances contain and manage POJO objects (may be service  
object).

When you use @Component or <component> you declare a component factory  
(component type).
When you use <instance> or .cfg file using a factoryPID you declare a  
component instance.

POJO objects are created either eagerly or lazily:
- if the instance does not provide a service (or if the component  
factory set immediate-true of set a validate callback), the pojo  
object is created when the component instance becomes valid.
- if the instance provides a service, the service object (POJO object)  
is created when required according to the creation strategy  
(singleton : one service object, instance : one service object per  
asking instance ...) [to publish services, the instance is necessary  
valid]


When I use INSTANCE strategy I'm seeing the two instances being  
created from the cfg files but then I'm seeing two new instances  
being created when my KNClient asks for a list, but those don't have  
any configuration in the properties (just the defaults). When I use  
SINGLETON, the list from the @Requires in the KNClient actually  
contains the two instances that were created by the cfg files but  
that's when I get (sometimes) the cycle error.
When I use immediate=true, the instances (object instances) are  
created but can't be seen by the arch command.

When you use the Instance strategy, component instance are created  
normally. But such instances will produce one service object per  
asking instance. If the component instance has already created a pojo  
object, it will NOT be used when your KNClient asks for the service  
(because the created one is not attached to the KNClient instance).  
However, I don't understand why the configuration (given in the  
component instance configuration) is not applied to these objects.

When using immediate, you declare your component instance normally.  
when the instance becomes valid, it will immediately create a pojo  
object (not another component instance). So, you should see only one  
component instance. But if you ask for details, you will see the  
created pojo object.


BTW, in your architecture, I don't see any cycle. So, I guess there is  
an issue when the pojo object is created. Something wrong happens  
during the pojo object creation forcing iPOJO to dispose the component  
instance (then the component instance is no more visible from arch).

Hope this helps,

Regards,

Clement



It's all over the place on how these things work, and none of it  
seems consistent.

I can't find any documentation about when and where instances  
(object or iPojo) are created and what the difference is between  
when/where the constructor on components/services are called verses  
the @Validate methods are called.

Please help me out. Thanks.

- Joel

-----Original Message-----
From: Clement Escoffier [mailto:clement.escoff...@gmail.com]
Sent: Wednesday, September 23, 2009 11:37 AM
To: users@felix.apache.org
Subject: Re: @Requires : ServiceFactory.getService() resulted in a  
cycle.


On 23.09.2009, at 19:33, Joel Schuster wrote:

As a side note... might this be a problem with the @Provides in the
RxTx service? If the default strategy is SINGLETON, how does
multiple cfg files create multiple instances? Or is this just
referring to the factory?

The singleton policy just says that each iPOJO instance will have one
one service object. But you can have several iPOJO instance (each  
with
one service object). However, be care if you use statics (because  
they
are shared.)

Clement


- Joel

-----Original Message-----
From: Joel Schuster [mailto:jo...@navsys.com]
Sent: Wednesday, September 23, 2009 11:03 AM
To: 'users@felix.apache.org'
Subject: RE: @Requires : ServiceFactory.getService() resulted in a
cycle.

Clement,

I have an rxtx bundle. I use cfg files to create one or more ipojo
instances of my rxtx service. These cfg files have stuff like baud,
parity, com port name, etc.

I have another bundle that uses just one of those, I get the list
of all
of them and then pick one based on a property within the rxtx
service also
configured by the cfg files.

So:

KNClient (instance from cfg file)
        |
        V
<uses one of x number based on property set in rxtx cfg file>
        |
        V
SerialRxTx (instances from cfg files)

I tried putting immediate=true on the RxTx service, however the cfg
files
no longer were setting the properties and the arch command no  
longer
showed any instances being created even though the constructor for
the
service was being called. As the KNClient is not a service, just a
component, it is automatically immediate.

Thanks for your help!

- Joel

-----Original Message-----
From: Clement Escoffier [mailto:clement.escoff...@gmail.com]
Sent: Wednesday, September 23, 2009 12:53 AM
To: users@felix.apache.org
Subject: Re: @Requires : ServiceFactory.getService() resulted in a
cycle.

Hi,

It sounds like a cycle during object creation. iPOJO object are
created when needed by default (if your component provides a
service).
To handle that iPOJO uses OSGi service factories.

The problem sounds to be the following:
- a service is going to be used
- iPOJO creates the pojo object (because, we need it)
- this object can also depending on a service, which may use the  
one
of the previous ones.... Cycle

To break the cycle, you can set one component to immediate. In  
that
case, the object will be created eagerly. the big question is :
Which
ones.

If you gives me more detail on your system, I can figure out how  
to
break the cycle.

Regards,

Clement

On 22.09.2009, at 23:21, Joel Schuster wrote:



I hate sending stack traces but I'm running into a real nasty
issue.
I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
tried various forms of the @Requires annotation.

This problem is sometimes reproducible on two systems but not on
the
third so I'm beginning to suspect a race condition of some sort  
as
it only manifests some of the time and is sometimes dependant  
upon
the order of the bundle loading.

I have one bundle that @Requires a collection of instances from
another bundle that implements two different interfaces, also  
each
in their own bundles. I've created a test set of bundles to see  
if
the problem comes from the inheritance model, but I can't  
reproduce
in a smaller example. Yet another reason it feels like a race
condition.

Thoughts?




-> ERROR: EventDispatcher: Error during dispatch.
(java.lang.IllegalStateException: ServiceFactory.getService()
resulted in a cycle.)
java.lang.IllegalStateException: ServiceFactory.getService()
resulted in a cycle.
        at
org
.apache
.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
261)
        at org.apache.felix.framework.Felix.getService(Felix.java:2881)
        at
org
.apache
.felix
.framework.BundleContextImpl.getService(BundleContextImpl.java:
357)
        at
org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
260)
        at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:
434)
        at
org
.apache
.felix
.ipojo.util.DependencyModel.ungetService(DependencyModel.java:
917)
        at
org
.apache
.felix
.ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:
435)
        at
org
.apache
.felix
.ipojo.util.DependencyModel.removedService(DependencyModel.java:
424)
        at org.apache.felix.ipojo.util.Tracker
$Tracked.untrack(Tracker.java:
736)
        at org.apache.felix.ipojo.util.Tracker
$Tracked.serviceChanged(Tracker.java:636)
        at
org
.apache
.felix
.framework
.util
.EventDispatcher
.invokeServiceListenerCallback(EventDispatcher.java:
878)
        at
org
.apache
.felix
.framework
.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:
732)
        at
org
.apache
.felix
.framework
.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
        at
org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
        at org.apache.felix.framework.Felix.access$000(Felix.java:40)
        at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:
624)
        at
org
.apache
.felix
.framework 
.ServiceRegistry.unregisterService(ServiceRegistry.java:
117)
        at
org
.apache
.felix
.framework
.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:
128)
        at
org
.apache
.felix
.ipojo
.handlers
.providedservice
.ProvidedService.unregisterService(ProvidedService.java:298)
        at
org
.apache
.felix
.ipojo
.handlers
.providedservice
.ProvidedServiceHandler 
.__stateChanged(ProvidedServiceHandler.java:
435)
        at
org
.apache
.felix
.ipojo
.handlers
.providedservice
.ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
        at
org
.apache 
.felix.ipojo.InstanceManager.setState(InstanceManager.java:
451)
        at
org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
340)
	at org.apache.felix.ipojo.util.Property.invoke(Property.java: 
502)
        at
org
.apache
.felix
.ipojo
.handlers
.configuration
.ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
        at
org
.apache
.felix
.ipojo
.handlers
.configuration
.ConfigurationHandler.onCreation(ConfigurationHandler.java)
        at
org
.apache
.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:
787)
	at  
org.apache.felix.ipojo.handlers.providedservice.ProvidedService
$SingletonStrategy.getService(ProvidedService.java:438)
        at
org
.apache
.felix
.ipojo
.handlers
.providedservice.ProvidedService.getService(ProvidedService.java:
263)
        at
org
.apache
.felix
.framework
.ServiceRegistrationImpl
.getFactoryUnchecked(ServiceRegistrationImpl.java:293)
        at
org
.apache
.felix
.framework
.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:
207)
        at
org
.apache
.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
307)
        at org.apache.felix.framework.Felix.getService(Felix.java:2881)
        at
org
.apache
.felix
.framework.BundleContextImpl.getService(BundleContextImpl.java:
357)
        at
org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
260)
        at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:
426)
        at
org
.apache
.felix 
.ipojo.util.DependencyModel.getService(DependencyModel.java:
901)
        at
org
.apache
.felix
.ipojo
.handlers
.dependency.Dependency.createServiceObject(Dependency.java:
481)
        at
org
.apache
.felix 
.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:
456)
        at
org 
.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:
944)
        at
com
.navsys 
.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
        at
com 
.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:
49)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
        at
sun
.reflect
.NativeConstructorAccessorImpl
.newInstance(NativeConstructorAccessorImpl.java:39)
        at
sun
.reflect
.DelegatingConstructorAccessorImpl
.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java: 
513)
        at
org
.apache
.felix.ipojo.InstanceManager.createObject(InstanceManager.java: 
600)
        at
org
.apache
.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:
776)
        at
org
.apache
.felix
.ipojo
.handlers
.lifecycle
.callback
.LifecycleCallbackHandler
.__stateChanged(LifecycleCallbackHandler.java:156)
        at
org
.apache
.felix
.ipojo
.handlers
.lifecycle
.callback
.LifecycleCallbackHandler
.stateChanged(LifecycleCallbackHandler.java)
        at
org
.apache 
.felix.ipojo.InstanceManager.setState(InstanceManager.java:
440)
        at
org 
.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:
321)
        at
org
.apache
.felix 
.ipojo.ComponentFactory.createInstance(ComponentFactory.java:
155)
        at
org
.apache
.felix
.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
298)
        at
org
.apache
.felix
.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
235)
        at
org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
        at org.apache.felix.cm.impl.ConfigurationManager
$UpdateConfiguration.run(ConfigurationManager.java:1460)
	at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java: 
88)

---------------------------------------------------------------------
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


---------------------------------------------------------------------
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