Getting and error: Circular reference detected, getService returning null

[Christian Schneider]

Does anyone have an idea why I get this error and if I can fix it?

These are the two scr components involved:
https://github.com/cschneider/osgi-chat/blob/master/api/src/main/java/net/lr/demo/chat/service/ChatBroker.java
https://github.com/cschneider/osgi-chat/blob/master/irc/src/main/java/tinkerchat/IRCConnector.java

Christian

---
g! [main] ERROR net.lr.demo.chat.irc - [connector.irc(0)] Circular
reference detected, getService returning null
[FelixDispatchQueue] ERROR net.lr.demo.chat.api - FrameworkEvent ERROR -
net.lr.demo.chat.api
org.osgi.framework.ServiceException: Service factory returned null.
(Component: connector.irc (0))
at
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:380)
at
org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247)
at
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:344)
at org.apache.felix.framework.Felix.getService(Felix.java:3699)
at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)
at
org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72)

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[Neil Bartlett]

Well… IRCConnector has a mandatory, static reference to ChatBroker. ChatBroker has a mandatory, static, multiple reference to ChatListener(s), of which IRCConnector is an instance. So it’s a clear cycle.

To break the cycle you need at least one leg to be optional and dynamic (and I recommend also greedy).

Neil

> --
> You received this message because you are subscribed to the Google Groups "bndtools-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Neil Bartlett]

Sorry small mistake… the MULTIPLE ref from ChatBroker to ChatListener is indeed optional (0..n), but you also should make it dynamic/greedy.

Neil

[Christian Schneider]

I thought ReferenceCardinality.MULTIPLE would already mean optional as
the multiplicity is 0..n.

I now tried with @Reference(cardinality = ReferenceCardinality.MULTIPLE,
policyOption=ReferencePolicyOption.GREEDY, policy=ReferencePolicy.DYNAMIC)
but still the same.

What I want to achieve is that IRCConnector always gets a ChatBroker.
ChatBroker should always start and dynamically work with the listeners
that are currently available.

Christian

[Neil Bartlett]

Well, this should work so maybe it’s something to raise against SCR.

What you want is perfectly reasonable and I do it all the time. You need the optional/dynamic so that ChatBroker can be started zero bindings initially and then have those bindings added dynamically after activation.

Neil

[Christian Schneider]

I think I got it working now. I added immediate=true to ChatBroker and
removed immediate=true in LCDChatListener which also refers to ChatBroker.
Now it starts up fine.

Thanks

Christian

[Peter Kriens]

I am fairly sure that if you use ‘volatile List…’ @References then you automatically get DYNAMIC and 0..n.

Kind regards,

Peter Kriens

[Ferry Huberts]

On 13/06/16 14:14, Christian Schneider wrote:
> Does anyone have an idea why I get this error and if I can fix it?
>

This is a known bug in Felix SCR

> These are the two scr components involved:
> https://github.com/cschneider/osgi-chat/blob/master/api/src/main/java/net/lr/demo/chat/service/ChatBroker.java
>
> https://github.com/cschneider/osgi-chat/blob/master/irc/src/main/java/tinkerchat/IRCConnector.java
>
>
> Christian
>
> ---
> g! [main] ERROR net.lr.demo.chat.irc - [connector.irc(0)] Circular
> reference detected, getService returning null
> [FelixDispatchQueue] ERROR net.lr.demo.chat.api - FrameworkEvent ERROR -
> net.lr.demo.chat.api
> org.osgi.framework.ServiceException: Service factory returned null.
> (Component: connector.irc (0))
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:380)
>
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247)
>
> at
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:344)
>
> at org.apache.felix.framework.Felix.getService(Felix.java:3699)
> at
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)
>
> at
> org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72)
>
>

--

Ferry Huberts

[Christian Schneider]

I just tried with
    @Reference
    volatile List<ChatListener> listeners;

and get this exception:
g! [main] ERROR net.lr.demo.chat.api - [net.lr.demo.chat.service.ChatBroker] Cannot register Component
org.osgi.service.component.ComponentException: Component net.lr.demo.chat.service.ChatBroker validation failed: Field value type must not be set for unary field references.

When I add cardinality=ReferenceCardinality.MULTIPLE it works. So it seems the List is not recognized.

Christian

[Christian Schneider]

Can you point me to the issue number?

I now get the exception even when setting all the options like
described. Interestingly it still work.
I assume that maybe this depends on which component is processed first.

Christian

On 13.06.2016 14:57, Ferry Huberts wrote:
>
>
> On 13/06/16 14:14, Christian Schneider wrote:
>> Does anyone have an idea why I get this error and if I can fix it?
>>
>
>
> This is a known bug in Felix SCR
>

[Peter Kriens]

According to the spec:

• For a field, the defaults for the Reference annotation are:

• The name of the bind method or field is used for the name of the reference.
• 1:1 cardinality if the field is not a collection. 0..n cardinality if the field is a collection.
• Static reluctant policy if the field is not declared volatile. Dynamic reluctant policy if the field is declared volatile.

I’ve used this successfully in the OSGi enRoute Examples https://github.com/osgi/osgi.enroute.examples/blob/master/osgi.enroute.examples.plugin.application/src/osgi/enroute/examples/plugin/application/OrderApplication.java

@Reference
volatile List<SupplierPlugin> suppliers;

Which generates:

<reference name="suppliers" cardinality="0..n" policy="dynamic" interface="osgi.enroute.examples.plugin.api.SupplierPlugin" field="suppliers" field-collection-type="service"/>

So I think there is something else amiss on your side.

Kind regards,

Peter Kriens

[BJ Hargrave]

What version of bnd are you processing the DS annotations with?

--

--
BJ

[Christian Schneider]

I am using the maven-bundle-plugin in version 3.0.1 and scr in version 2.0.2.
Not sure which bnd version it uses.

I experimented a bit and found the volatile indeed determines if dynamic is used but the List does not seem to be recoginzed as providing MULTIPLE.
I will try to use the bnd-maven-plugin as a next step.

Christian

On 13.06.2016 15:45, BJ Hargrave wrote:

What version of bnd are you processing the DS annotations with?

On Mon, Jun 13, 2016 at 9:07 AM Christian Schneider <ch...@die-schneider.net> wrote:

I just tried with
    @Reference
    volatile List<ChatListener> listeners;

and get this exception:
g! [main] ERROR net.lr.demo.chat.api - [net.lr.demo.chat.service.ChatBroker] Cannot register Component
org.osgi.service.component.ComponentException: Component net.lr.demo.chat.service.ChatBroker validation failed: Field value type must not be set for unary field references.

When I add cardinality=ReferenceCardinality.MULTIPLE it works. So it seems the List is not recognized.

Christian

[Ferry Huberts]

https://issues.apache.org/jira/browse/FELIX-4417
https://issues.apache.org/jira/browse/FELIX-5197

On 13/06/16 15:38, Christian Schneider wrote:
> Can you point me to the issue number?
>
> I now get the exception even when setting all the options like
> described. Interestingly it still work.
> I assume that maybe this depends on which component is processed first.
>
> Christian
>
> On 13.06.2016 14:57, Ferry Huberts wrote:
>>
>>
>> On 13/06/16 14:14, Christian Schneider wrote:
>>> Does anyone have an idea why I get this error and if I can fix it?
>>>
>>
>>
>> This is a known bug in Felix SCR
>>
>

--

Ferry Huberts

[BJ Hargrave]

maven-bundle-plugin uses bndlib 3.0 (http://search.maven.org/#artifactdetails%7Corg.apache.felix%7Cmaven-bundle-plugin%7C3.0.1%7Cmaven-plugin) which is pretty old and I am sure has DS 1.3 annotation processing bugs we fixed for bnd 3.1. You need to update to a maven plugin which uses a more modern version of bnd such as bnd-maven-plugin.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
BJ

[Christian Schneider]

I just upgraded the project to use the bnd-maven-plugin and now a plain

    @Reference
    volatile List<ChatListener> listeners;

works.

I still get the exception when scr starts up but this seems to be the issue Ferry mentioned.
https://issues.apache.org/jira/browse/FELIX-5197

So all seems to work fine now.

Thanks

Christian

[David Jencks]

FWIW as far as I can tell both of these issues are invalid.

One of them is complaining about framework logging which isn’t even something DS can do anything about.

I have recently improved the circular reference logging to try to tell you what the components in the cycle are, so you might try DS trunk.

david jencks

[Christian Schneider]

Hi David,

in my case there is(should be) no cycle.

Component IRC (exported as ChatListener) has a mandatory reference to ChatBroker.
ChatBroker has a 0..n reference to ChatListener.

The intent here is that ChatBroker always comes up. So there should be no cycle. Still I get the exception.
This is the line produced by the build:
<reference name="listeners" cardinality="0..n" policy="dynamic" interface="net.lr.demo.chat.service.ChatListener" field="listeners" field-collection-type="service"/>

I think this should be treated as an optional reference that breaks a loop. Does that make sense?

Christian

[David Jencks]

Well, you definitely have a cycle. One of the links is optional and dynamic so I’d expect that DS would eventually set all the references in the cycle.  As noted in FELIX-5197, that particular error  message comes from the frameworks ServiceRegistry which is required to emit errors when a thread loops around and tries to get a service that is already being gotten.  I suppose DS could check the thread-local list of service references each time before it tries to get a service to avoid even trying the getService call that emits this error.  I’m a bit reluctant to implement this since IMO the best conclusion from all this is, “DON”T HAVE CYCLES!”.  At best there’s going to be a delay between all the components being activated and the final link established, as this has to occur on a separate thread; it turned out that FELIX-4417 was the test missing a “delay()” so there was time to reliably establish the link.   So I very strongly recommend reexamining your design and eliminating all the cycles.

thanks

david jencks

[Ferry Huberts]

On 13/06/16 18:08, David Jencks wrote:
> Well, you definitely have a cycle. One of the links is optional and
> dynamic so I’d expect that DS would eventually set all the references in
> the cycle. As noted in FELIX-5197, that particular error message comes
> from the frameworks ServiceRegistry which is required to emit errors
> when a thread loops around and tries to get a service that is already
> being gotten. I suppose DS could check the thread-local list of service
> references each time before it tries to get a service to avoid even
> trying the getService call that emits this error. I’m a bit reluctant
> to implement this since IMO the best conclusion from all this is, “DON”T
> HAVE CYCLES!”. At best there’s going to be a delay between all the
> components being activated and the final link established, as this has
> to occur on a separate thread; it turned out that FELIX-4417 was the
> test missing a “delay()” so there was time to reliably establish the
> link. So I very strongly recommend reexamining your design and
> eliminating all the cycles.

You could also just split it in 2 phases:
1- first you process all mandatory refs,
2- then you process all optional refs (which includes dynamic refs)

>
> thanks
> david jencks
>
>> On Jun 13, 2016, at 8:34 AM, Christian Schneider

>> <ch...@die-schneider.net <mailto:ch...@die-schneider.net>> wrote:
>>
>> Hi David,
>>
>> in my case there is(should be) no cycle.
>>
>> Component IRC (exported as ChatListener) has a mandatory reference to
>> ChatBroker.
>> ChatBroker has a 0..n reference to ChatListener.
>>
>> The intent here is that ChatBroker always comes up. So there should be
>> no cycle. Still I get the exception.
>> This is the line produced by the build:
>> <reference name="listeners" cardinality="0..n" policy="dynamic"
>> interface="net.lr.demo.chat.service.ChatListener" field="listeners"
>> field-collection-type="service"/>
>>
>> I think this should be treated as an optional reference that breaks a
>> loop. Does that make sense?
>>
>> Christian
>>
>>
>>
>> On 13.06.2016 17:25, David Jencks wrote:
>>> FWIW as far as I can tell both of these issues are invalid.
>>>
>>> One of them is complaining about framework logging which isn’t even
>>> something DS can do anything about.
>>>
>>> I have recently improved the circular reference logging to try to
>>> tell you what the components in the cycle are, so you might try DS trunk.
>>>
>>> david jencks
>>>
>>>> On Jun 13, 2016, at 7:00 AM, Ferry Huberts <mail...@hupie.com

>>>> <mailto:mail...@hupie.com>> wrote:
>>>>
>>>>
>>>>
>>>> https://issues.apache.org/jira/browse/FELIX-4417
>>>> https://issues.apache.org/jira/browse/FELIX-5197
>>>>
>>>> On 13/06/16 15:38, Christian Schneider wrote:
>>>>> Can you point me to the issue number?
>>>>>
>>>>> I now get the exception even when setting all the options like
>>>>> described. Interestingly it still work.
>>>>> I assume that maybe this depends on which component is processed first.
>>>>>
>>>>> Christian
>>>>>
>>>>> On 13.06.2016 14:57, Ferry Huberts wrote:
>>>>>>
>>>>>>
>>>>>> On 13/06/16 14:14, Christian Schneider wrote:
>>>>>>> Does anyone have an idea why I get this error and if I can fix it?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> This is a known bug in Felix SCR
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Ferry Huberts
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "bndtools-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>> send an email

>>>> to <mailto:bndtools-user...@googlegroups.com>bndtools-user...@googlegroups.com.
>>>> For more options,
>>>> visit <https://groups.google.com/d/optout>https://groups.google.com/d/optout.

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "bndtools-users" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to bndtools-user...@googlegroups.com

>>> <mailto:bndtools-user...@googlegroups.com>.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "bndtools-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to bndtools-user...@googlegroups.com

>> <mailto:bndtools-user...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "bndtools-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bndtools-user...@googlegroups.com

> <mailto:bndtools-user...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--

Ferry Huberts

[David Jencks]

Are you saying

1. get the services for mandatory refs and call setters/set fields, for all components

2. call activate on all components

3. get the services for optional refs and call setters/set fields, for all components.

?

How is DS supposed to define “all components”? 

This would violate my expectation that any reference is going to be set to the available set of services.  If I have any clue about what you mean, I think your proposal would result in enormous churn for most use cases.

FWIW, if you define “all components” as those in a particular cycle, the current implementation basically does what you suggest, except step 1 is “process all possible references” and step 2 is “try to process the other one in a different thread”.

david jencks

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Neil Bartlett]

David,

I disagree with this advice. It's perfectly acceptable to have a cycle so long as one leg is optional-dynamic.

This is a common use case where you want to be the client of a service and also listen with a service-specific listener interface, whiteboard style.

Neil

[David Jencks]

Well, as long as you are willing to either accept that it’s unreliable (time gaps where not all the references are established)  or assure that the components start in the correct order by explicitly enabling them in that order, ok.  My conclusion is that it’s worth a lot of effort to eliminate cycles.  Having your components work simply and reliably without hard to understand tweaking is worth a lot.

david jencks

[Christian Schneider]

I also think this is a quite natural case. Scr could simply create a service tracker for the optional, dynamic side and let it react on service changes while returning instantly. This should avoid a lock.

Would that work?

Christian

[Peter Kriens]

This use case is a more than perfect example for the PushStream … you’re creating a bi-directional link. This almost always implies a cycle. Push Streams would make it a very natural solution.

I do agree with David that you want to pay quite a high price to prevent cycles but in this case it is just hard to avoid and we clearly specified that this is allowed as long as there is an optional link.

Kind regards,

Peter Kriens

[David Jencks]

No, if it is any different from what it already does, which involves a “service tracker” modified to deal with SCR requirements which are more extensive than ordinary service tracker requirements.  Have you read and understood the comments about why I adopted the solution I did?  There are rakes to step on with just about every possible choice. My conclusion that it’s worth a couple weeks of redesign time to avoid cycles is from trying to deal with this over several years.

With all this argument I’m really tempted to follow the letter of the spec and never try to establish the optional link…. to me that is what the spec actually calls for.

david jencks

[Ferry Huberts]

On 13/06/16 18:54, David Jencks wrote:
> Well, as long as you are willing to either accept that it’s unreliable
> (time gaps where not all the references are established) or assure that

That is kind of the point of DYNAMIC, isn't it?

> the components start in the correct order by explicitly enabling them in
> that order, ok. My conclusion is that it’s worth a lot of effort to
> eliminate cycles. Having your components work simply and reliably
> without hard to understand tweaking is worth a lot.
>
> david jencks
>
>> On Jun 13, 2016, at 9:27 AM, Neil Bartlett <njbar...@gmail.com

>> <mailto:njbar...@gmail.com>> wrote:
>>
>> David,
>>
>> I disagree with this advice. It's perfectly acceptable to have a cycle
>> so long as one leg is optional-dynamic.
>>
>> This is a common use case where you want to be the client of a service
>> and also listen with a service-specific listener interface, whiteboard
>> style.
>>
>> Neil
>>
>> On 13 Jun 2016 5:08 p.m., "David Jencks" <david.a...@gmail.com

>> <mailto:david.a...@gmail.com>> wrote:
>>
>> Well, you definitely have a cycle. One of the links is optional
>> and dynamic so I’d expect that DS would eventually set all the
>> references in the cycle. As noted in FELIX-5197, that particular
>> error message comes from the frameworks ServiceRegistry which is
>> required to emit errors when a thread loops around and tries to
>> get a service that is already being gotten. I suppose DS could
>> check the thread-local list of service references each time before
>> it tries to get a service to avoid even trying the getService call
>> that emits this error. I’m a bit reluctant to implement this
>> since IMO the best conclusion from all this is, “DON”T HAVE
>> CYCLES!”. At best there’s going to be a delay between all the
>> components being activated and the final link established, as this
>> has to occur on a separate thread; it turned out that FELIX-4417
>> was the test missing a “delay()” so there was time to reliably
>> establish the link. So I very strongly recommend reexamining
>> your design and eliminating all the cycles.
>>
>> thanks
>> david jencks
>>
>>> On Jun 13, 2016, at 8:34 AM, Christian Schneider

>>> <ch...@die-schneider.net <mailto:ch...@die-schneider.net>> wrote:
>>>
>>> Hi David,
>>>
>>> in my case there is(should be) no cycle.
>>>
>>> Component IRC (exported as ChatListener) has a mandatory
>>> reference to ChatBroker.
>>> ChatBroker has a 0..n reference to ChatListener.
>>>
>>> The intent here is that ChatBroker always comes up. So there
>>> should be no cycle. Still I get the exception.
>>> This is the line produced by the build:
>>> <reference name="listeners" cardinality="0..n" policy="dynamic"
>>> interface="net.lr.demo.chat.service.ChatListener"
>>> field="listeners" field-collection-type="service"/>
>>>
>>> I think this should be treated as an optional reference that
>>> breaks a loop. Does that make sense?
>>>
>>> Christian
>>>
>>>
>>>
>>> On 13.06.2016 17:25, David Jencks wrote:
>>>> FWIW as far as I can tell both of these issues are invalid.
>>>>
>>>> One of them is complaining about framework logging which isn’t
>>>> even something DS can do anything about.
>>>>
>>>> I have recently improved the circular reference logging to try
>>>> to tell you what the components in the cycle are, so you might
>>>> try DS trunk.
>>>>
>>>> david jencks
>>>>
>>>>> On Jun 13, 2016, at 7:00 AM, Ferry Huberts <mail...@hupie.com

>>>>> <mailto:mail...@hupie.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/browse/FELIX-4417
>>>>> https://issues.apache.org/jira/browse/FELIX-5197
>>>>>
>>>>> On 13/06/16 15:38, Christian Schneider wrote:
>>>>>> Can you point me to the issue number?
>>>>>>
>>>>>> I now get the exception even when setting all the options like
>>>>>> described. Interestingly it still work.
>>>>>> I assume that maybe this depends on which component is
>>>>>> processed first.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> On 13.06.2016 14:57, Ferry Huberts wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 13/06/16 14:14, Christian Schneider wrote:
>>>>>>>> Does anyone have an idea why I get this error and if I can
>>>>>>>> fix it?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is a known bug in Felix SCR
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Ferry Huberts
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the
>>>>> Google Groups "bndtools-users" group.
>>>>> To unsubscribe from this group and stop receiving emails from
>>>>> it, send an email

>>>>> to <mailto:bndtools-user...@googlegroups.com>bndtools-user...@googlegroups.com
>>>>> <mailto:bndtools-user...@googlegroups.com>.
>>>>> For more options,
>>>>> visit <https://groups.google.com/d/optout>https://groups.google.com/d/optout.

>>>>
>>>> --
>>>> You received this message because you are subscribed to the
>>>> Google Groups "bndtools-users" group.
>>>> To unsubscribe from this group and stop receiving emails from
>>>> it, send an email to bndtools-user...@googlegroups.com

>>>> <mailto:bndtools-user...@googlegroups.com>.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> Christian Schneider

>>> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>>>
>>> Open Source Architect
>>> http://www.talend.com <http://www.talend.com/>

>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "bndtools-users" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to bndtools-user...@googlegroups.com

>>> <mailto:bndtools-user...@googlegroups.com>.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "bndtools-users" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to bndtools-user...@googlegroups.com

>> <mailto:bndtools-user...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "bndtools-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to bndtools-user...@googlegroups.com

>> <mailto:bndtools-user...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "bndtools-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bndtools-user...@googlegroups.com

> <mailto:bndtools-user...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--

Ferry Huberts

[David Jencks]

> On Jun 13, 2016, at 11:21 AM, Ferry Huberts <mail...@hupie.com> wrote:
>
>
>
> On 13/06/16 18:54, David Jencks wrote:
>> Well, as long as you are willing to either accept that it’s unreliable
>> (time gaps where not all the references are established) or assure that
>
> That is kind of the point of DYNAMIC, isn't it?

I normally expect that any service reference that is available before activation will be bound before activation. That doesn’t happen here.

david jencks

> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

[Simon Chemouil]

Hi,

I agree with Neil; optional/mandatory <-> static unary is a common and useful pattern.

The question is: is it always possible to come up with another design? Is it even desirable?

Let's take a standard OSGi spec: EventAdmin. It is a whiteboard pattern where EventHandlers are a 0..n dynamic reference for the EventAdmin. Some EventHandlers may only be interested in consuming events, but others need to post events by themselves. They introduce a cycle (with an optional/dynamic reference on the EventAdmin implementation's side).

What are the alternatives for getting rid of that cycle? An EventAdmin which lets custom listeners be registered will always require, either directly or indirectly, a list of listeners. So let us say it should be forbidden from an EventHandler to get an EventAdmin reference. That means all services must either choose between consuming and posting events. 

I think we're all trying to avoid cycles (at least mandatory/non-dynamic+greedy cycles :-)), but sometimes the better design implies this kind of cycle. Now, the way this discussion is happening, I am not sure whether SCR does every thing it could to make specific this use-case easy, or if it could go further. I don't really care about the cycle log message ; the fact is SCR is in my experience extra-sensitive with this pattern, and that previously I made it work reliably using plain OSGi APIs.

Simon

[Neil Bartlett]

On 13 Jun 2016, at 19:37, David Jencks <david.a...@gmail.com> wrote:

On Jun 13, 2016, at 11:21 AM, Ferry Huberts <mail...@hupie.com> wrote:



On 13/06/16 18:54, David Jencks wrote:

Well, as long as you are willing to either accept that it’s unreliable
(time gaps where not all the references are established)  or assure that

That is kind of the point of DYNAMIC, isn't it?

I normally expect that any service reference that is available before activation will be bound before activation.  That doesn’t happen here.

Which is explicitly not a problem. Let’s break this down: A depends on B (mandatory/static); B depends on A (optional/multiple/dynamic).

A cannot start first because there is no B.

B can start because although there is no A, it’s optional so who cares. Now a service reference for B exists, and so A can start. And now a service reference for A exists, so it can be dynamically added to B.

[Ferry Huberts]

On 13/06/16 20:37, David Jencks wrote:
>
>> On Jun 13, 2016, at 11:21 AM, Ferry Huberts <mail...@hupie.com> wrote:
>>
>>
>>
>> On 13/06/16 18:54, David Jencks wrote:
>>> Well, as long as you are willing to either accept that it’s unreliable
>>> (time gaps where not all the references are established) or assure that
>>
>> That is kind of the point of DYNAMIC, isn't it?
> I normally expect that any service reference that is available before activation will be bound before activation. That doesn’t happen here.
>

Normally yes.

However, in the presence of cycles there is no need to maintain that
expectancy since the DYNAMIC policy is specified, which does NOT have
any such expectancies or make any such assurances.

I think it is totally acceptable to 'break' your expected behaviour to
avoid the cycle. DYNAMIC explicitly allows binding at any time,
including later than activation.

And I too use this pattern in places. It is very useful for some
situations. And frankly, the situations in which I use it would be a
total pain in the ... to do differently.

--
Ferry Huberts

[Ferry Huberts]

On 13/06/16 18:18, David Jencks wrote:
> Are you saying
> 1. get the services for mandatory refs and call setters/set fields, for
> all components
> 2. call activate on all components
> 3. get the services for optional refs and call setters/set fields, for
> all components.
> ?
>
> How is DS supposed to define “all components”?

Don't know what you mean here.

What I meant was that when you detect any such 'cycles' you put the
optional side of it in a set/amp/whatever and continue processing. Once
you finish processing, you check the set for contents, and if there is
any you process those as well.

A 2-step process / delayed binding.

> This would violate my expectation that any reference is going to be set
> to the available set of services. If I have any clue about what you
> mean, I think your proposal would result in enormous churn for most use
> cases.
>
> FWIW, if you define “all components” as those in a particular cycle, the
> current implementation basically does what you suggest, except step 1 is
> “process all possible references” and step 2 is “try to process the
> other one in a different thread”.
>
> david jencks
>
>> On Jun 13, 2016, at 9:11 AM, Ferry Huberts <mail...@hupie.com

>> <mailto:mail...@hupie.com>> wrote:
>>
>>
>>
>> On 13/06/16 18:08, David Jencks wrote:
>>> Well, you definitely have a cycle. One of the links is optional and
>>> dynamic so I’d expect that DS would eventually set all the references in
>>> the cycle. As noted in FELIX-5197, that particular error message comes
>>> from the frameworks ServiceRegistry which is required to emit errors
>>> when a thread loops around and tries to get a service that is already
>>> being gotten. I suppose DS could check the thread-local list of service
>>> references each time before it tries to get a service to avoid even
>>> trying the getService call that emits this error. I’m a bit reluctant
>>> to implement this since IMO the best conclusion from all this is, “DON”T
>>> HAVE CYCLES!”. At best there’s going to be a delay between all the
>>> components being activated and the final link established, as this has
>>> to occur on a separate thread; it turned out that FELIX-4417 was the
>>> test missing a “delay()” so there was time to reliably establish the
>>> link. So I very strongly recommend reexamining your design and
>>> eliminating all the cycles.
>>
>>
>> You could also just split it in 2 phases:
>> 1- first you process all mandatory refs,
>> 2- then you process all optional refs (which includes dynamic refs)
>>
>>
>>>
>>> thanks
>>> david jencks
>>>
>>>> On Jun 13, 2016, at 8:34 AM, Christian Schneider
>>>> <ch...@die-schneider.net

>>>> <mailto:ch...@die-schneider.net> <mailto:ch...@die-schneider.net>>

>>>>>> <mailto:bndtools-user...@googlegroups.com>bndtools-user...@googlegroups.com

>>>>>> <mailto:bndtools-user...@googlegroups.com>.
>>>>>> For more options,
>>>>>> visit
>>>>>> <https://groups.google.com/d/optout>https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "bndtools-users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>> send an email to bndtools-user...@googlegroups.com
>>>>> <mailto:bndtools-user...@googlegroups.com>
>>>>> <mailto:bndtools-user...@googlegroups.com>.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> Christian Schneider

>>>> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com <http://www.talend.com/>

>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "bndtools-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to bndtools-user...@googlegroups.com
>>>> <mailto:bndtools-user...@googlegroups.com>

>>>> <mailto:bndtools-user...@googlegroups.com>.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "bndtools-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to bndtools-user...@googlegroups.com
>>> <mailto:bndtools-user...@googlegroups.com>
>>> <mailto:bndtools-user...@googlegroups.com>.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> Ferry Huberts
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "bndtools-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send

>> an email to bndtools-user...@googlegroups.com

[David Jencks]

That’s what I do. If you try it you will quickly find that the second step has to happen on a separate thread, which is what I do.

david jencks

> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

[David Jencks]

the problem is that to make this work smoothly you have to have A start first.  The only way to be sure this happens is to make start with B disabled and only enable B after A is activated.  Otherwise, you are at least sometimes going to get the circular dependency warning.  If something tries to get the B service first, you get into knots, and there’s a short interval where the cycle is not actually established.  As everyone seems to be saying this is correct behavior but I think it is apt to be very unexpected for those who have not experienced personally it in the last couple of weeks. (i.e. I forget this happens quite quickly).

david jencks

[Neil Bartlett]

On 14 Jun 2016, at 02:36, David Jencks <david.a...@gmail.com> wrote:

the problem is that to make this work smoothly you have to have A start first.

Why is that?

The only way to be sure this happens is to make start with B disabled and only enable B after A is activated.

Isn’t this the wrong way around? A has unsatisfied references, so it should be initially disabled and its service registration not yet published.

Otherwise, you are at least sometimes going to get the circular dependency warning.  If something tries to get the B service first, you get into knots, and there’s a short interval where the cycle is not actually established.  As everyone seems to be saying this is correct behavior but I think it is apt to be very unexpected for those who have not experienced personally it in the last couple of weeks. (i.e. I forget this happens quite quickly).

I certainly don’t want to downplay the difficulties facing an SCR implementer, but I think as this thread proves, dynamic cycles are useful and in some cases even unavoidable for users. Simon’s EventAdmin use-case is a great example. It’s difficult to follow your explanation of why the implementation is so challenging because I’m not working in that code every day.

Regarding new user expectations… I’ve done many OSGi training courses and the idea that you can break a cycle simply by making one leg dynamic-optional is quickly grasped.

Neil