[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Service Component circular dependencies

Hmmm. Perhaps I did misspeak. The spec does say calling activate() is the 
final step in activation. When I replied I was thinking of it more as 
notifiying the component that is had been activated. It is rather the last 
step in activation and the component can perfoms actions within the 
activate method which initialize it for use.

However, I don't think SCR should be attempting to create a new instance 
when asked for an instance if it is currently in the process of activating 
the instance (assuming servicefactory=false, etc.).
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
Office: +1 407 849 9117 Mobile: +1 386 848 3788



Roy Paterson/Austin/IBM@IBMUS 
Sent by: equinox-dev-bounces@xxxxxxxxxxx
06/28/2006 02:28 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc

Subject
Re: [equinox-dev] Service Component circular dependencies







BJ, are you sure that a component is considered activated before 
activate() is called?  I'm pretty sure the equinox implementation does not 
consider a component activated until after activate() is called. 

Roy

-----------------------------------------
Roy Paterson
IBM Pervasive Computing
Austin, TX
Phone: (512) 838-8898



BJ Hargrave/Austin/IBM@IBMUS 
Sent by: equinox-dev-bounces@xxxxxxxxxxx 
06/28/2006 01:16 PM 

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> 
cc

Subject
Re: [equinox-dev] Service Component circular dependencies








It sounds like a bug in DS. A component is considered fully activated 
immediately before activate() is called. So, if during the execution of 
A.activate() some one wants A, A should be returned since it is now 
activated. Please open a bug report with a reproduction scenario.

Is A declared as a servicefactory=true? This will result in a unique 
instance of A being created for each bundle which uses A.


BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
Office: +1 407 849 9117 Mobile: +1 386 848 3788



Subbarao Meduri/Durham/IBM@IBMUS 
Sent by: equinox-dev-bounces@xxxxxxxxxxx
06/28/2006 12:46 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc

Subject
[equinox-dev] Service Component circular dependencies






It appears that the Declarative Services runtime can potentially 
instantiate a delayed service component multiple times.

In the scenario I have, a delayed service component A is called on 
activate() method after it is looked up in the service registry, and as 
part of processing the activate code, somewhere deep in the call stack, 
the service for component A is looked up again (using service registry 
APIs). This is clearly a mandatory circular dependency that DS does not 
support. I would have expected an exception thrown at this time indicating 

a potential circular dependency. Instead, it appears that the DS runtime 
tries to instantiate and activate the component again, which seems like a 
bug.

On the other hand, IOC frameworks such as Spring/Pico seem to have a way 
to deal with circular references. would it be possible that DS runtime to 
support mandatory circular references, and not have such restriction ?

Appreciate your thoughts.

Regards,
Subbarao_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev