[ 
https://issues.apache.org/jira/browse/FELIX-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055996#comment-14055996
 ] 

Markus Kaufhold commented on FELIX-4417:
----------------------------------------

The problem is located in AbstractComponentManager.activateInternal right at 
the bottom of that method:
            if ( !registerService() )
            {
                //some other thread is activating us, or we got concurrently 
deactivated.
                return;
            }

            if ( ( isImmediate() || getComponentMetadata().isFactory() ) )
            {
                getServiceInternal();
            }
        }
        finally

First all services are registered and then inside getServiceInternal the 
component instance is created, which means that there exists a time slot where 
a ServiceReference is existing without having an actual instance.

So when creating the instance of the immediate component B, it's service b is 
registered, then getServiceInternal is called, and within there a call to 
collectDependencies is executed. That goes to component A for service a, which 
in turn goes back to component B for service b.
Here getServiceInternal is entered again which causes the circular reference 
check to be hit, spitting out the "Circular reference detected, getService 
returning null"

To solve that problem, the registering should be done AFTER the creation of the 
component:
            if ( ( isImmediate() || getComponentMetadata().isFactory() ) )
            {
                getServiceInternal();
            }
            
            registerService();
        }
        finally

With that change the CircularReferenceTest attached to this Jira succeeds (and 
as well all other tests still succeeding).

Note that the eclispe SCR implementation is doing it in exactly this way, first 
create the instance, then register the services
http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/InstanceProcess.java
At line 197 buildComponent is called where the instance is created and its 
activate is called, and at line 213 the services are registered.

> Circular references detected but not resolved if one of the references in the 
> cycle has optional cardinality
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: FELIX-4417
>                 URL: https://issues.apache.org/jira/browse/FELIX-4417
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.8.2
>            Reporter: Victor Antonovich
>         Attachments: CircularReferenceTest-trunk.patch, 
> CircularReferenceTest.zip
>
>
> Looks like current Apache Felix SCR implementation doesn't conform fully to 
> Declarative Services Specification, which says 
> (http://www.osgi.org/download/r4v43/osgi.cmpn-4.3.0.pdf, 112.3.7):
> "Circular references must be detected by SCR when it attempts to satisfy 
> component configurations and SCR must fail to satisfy the references involved 
> in the cycle and log an error message with the Log Service, if present. 
> However, if one of the references in the cycle has optional cardinality SCR 
> must break the cycle. The reference with the optional cardinality can be 
> satisfied and bound to zero target services. Therefore the cycle is broken 
> and the other references may be satisfied."
> In case of two components, A and B, where A is delayed with 1..1 static 
> reference to B, and B is immediate with 0..n dynamic reference to A, Felix 
> SCR should:
> 1) activate B with dynamic reference to A satisfied and bound to zero services
> 2) activate A with satisfied static reference to B
> 3) bind dynamic reference to B in component A
> But it seems current Felix SCR implementation can't handle this kind of 
> circular dependency correctly and is failing with message "Circular reference 
> detected".



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to