You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Dan Tran <da...@gmail.com> on 2013/06/26 17:55:03 UTC
Concern about https://issues.apache.org/jira/browse/KARAF-2273 - not
backward compatible
This new default behavior introduces backward compatibility specially to
bundles that depend on services from each other.
Can we not apply this behavior to 2.3.x branch?
I am fine with 2.4 where I will have time to do something about it
Thanks
-Dan
Re: Concern about https://issues.apache.org/jira/browse/KARAF-2273 -
not backward compatible
Posted by Dan Tran <da...@gmail.com>.
I have no problem with the work around, however, But expect to see a slew
of complains from 2.3.x install base who, like me, does not take advantage
of OSGi dynamics would run into startup issue.
For may case, I ended up to use reference-listener so resolve the new
startup behavior of this new flag. Still much more thing to do.
-Dan
On Thu, Jun 27, 2013 at 9:24 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> I'm not in favour of this. I would prefer to have a documentation for that.
>
> I tested it without problem, and it fixes a lot of issues (on Cellar, on
> Spring, etc). More over, we have a predictable behaviour.
> If you are able to provide test case describing the issues that you
> encounter, it will help to understand (it's maybe a side effect).
>
> Anyway, in your case, you have a simple workaround: comment the property
> or set it to false ;)
>
> Regards
> JB
>
>
> On 06/27/2013 06:13 PM, Dan Tran wrote:
>
>> Also, multiple deployment files under deploy directory also missed behave
>> (
>> still under investigation ). So I strongly suggest to DISABLE that
>> configuration at 2.3.x branch
>>
>> -D
>>
>>
>> On Wed, Jun 26, 2013 at 9:55 AM, Dan Tran <da...@gmail.com> wrote:
>>
>> Hi JB,
>>>
>>> I tested out 2.3.1 with org.apache.aries.blueprint.**synchronous=true
>>>
>>> A couple of my bundles fail at start up
>>>
>>> Here is scenario ( very high level )
>>>
>>> bundle A component A.1 depends on bundle B service B.1 which depends on
>>> service of bundle C service C.1 which depends on Bundle A
>>>
>>> With out the flag, all of these bundles manage to come up
>>>
>>> With the flag, I got NPE
>>>
>>>
>>> Caused by: java.lang.**IllegalStateException: getService() returned
>>> null for
>>> [com.xxxx.yyyy.ServiceX]
>>> at
>>> org.apache.aries.blueprint.**container.ReferenceRecipe.**
>>> getService(ReferenceRecipe.**java:242)
>>> at
>>> org.apache.aries.blueprint.**container.ReferenceRecipe.**
>>> access$000(ReferenceRecipe.**java:54)
>>> at
>>> org.apache.aries.blueprint.**container.ReferenceRecipe$**
>>> ServiceDispatcher.call(**ReferenceRecipe.java:291)
>>>
>>>
>>> I think I figure out how to get away from cyclic dependencies, I will
>>> take
>>> time.
>>>
>>> I also want to raise this issue early so that other users be aware and
>>> react appropriately ( like disable that flat, at build time or event at
>>> production/customer site, in 2.3.2 which is not desirable )
>>>
>>> -D
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 26, 2013 at 9:08 AM, Jean-Baptiste Onofré <jb@nanthrax.net
>>> >wrote:
>>>
>>> Hi Dan,
>>>>
>>>> It's completely backward compatible normally.
>>>>
>>>> Could you explain your issue ?
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 06/26/2013 05:55 PM, Dan Tran wrote:
>>>>
>>>> This new default behavior introduces backward compatibility specially
>>>>> to
>>>>> bundles that depend on services from each other.
>>>>>
>>>>> Can we not apply this behavior to 2.3.x branch?
>>>>>
>>>>> I am fine with 2.4 where I will have time to do something about it
>>>>>
>>>>> Thanks
>>>>>
>>>>> -Dan
>>>>>
>>>>>
>>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Concern about https://issues.apache.org/jira/browse/KARAF-2273
- not backward compatible
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I'm not in favour of this. I would prefer to have a documentation for that.
I tested it without problem, and it fixes a lot of issues (on Cellar, on
Spring, etc). More over, we have a predictable behaviour.
If you are able to provide test case describing the issues that you
encounter, it will help to understand (it's maybe a side effect).
Anyway, in your case, you have a simple workaround: comment the property
or set it to false ;)
Regards
JB
On 06/27/2013 06:13 PM, Dan Tran wrote:
> Also, multiple deployment files under deploy directory also missed behave (
> still under investigation ). So I strongly suggest to DISABLE that
> configuration at 2.3.x branch
>
> -D
>
>
> On Wed, Jun 26, 2013 at 9:55 AM, Dan Tran <da...@gmail.com> wrote:
>
>> Hi JB,
>>
>> I tested out 2.3.1 with org.apache.aries.blueprint.synchronous=true
>>
>> A couple of my bundles fail at start up
>>
>> Here is scenario ( very high level )
>>
>> bundle A component A.1 depends on bundle B service B.1 which depends on
>> service of bundle C service C.1 which depends on Bundle A
>>
>> With out the flag, all of these bundles manage to come up
>>
>> With the flag, I got NPE
>>
>>
>> Caused by: java.lang.IllegalStateException: getService() returned null for
>> [com.xxxx.yyyy.ServiceX]
>> at
>> org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:242)
>> at
>> org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:54)
>> at
>> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:291)
>>
>>
>> I think I figure out how to get away from cyclic dependencies, I will take
>> time.
>>
>> I also want to raise this issue early so that other users be aware and
>> react appropriately ( like disable that flat, at build time or event at
>> production/customer site, in 2.3.2 which is not desirable )
>>
>> -D
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jun 26, 2013 at 9:08 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>>
>>> Hi Dan,
>>>
>>> It's completely backward compatible normally.
>>>
>>> Could you explain your issue ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 06/26/2013 05:55 PM, Dan Tran wrote:
>>>
>>>> This new default behavior introduces backward compatibility specially to
>>>> bundles that depend on services from each other.
>>>>
>>>> Can we not apply this behavior to 2.3.x branch?
>>>>
>>>> I am fine with 2.4 where I will have time to do something about it
>>>>
>>>> Thanks
>>>>
>>>> -Dan
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Concern about https://issues.apache.org/jira/browse/KARAF-2273 -
not backward compatible
Posted by Dan Tran <da...@gmail.com>.
Also, multiple deployment files under deploy directory also missed behave (
still under investigation ). So I strongly suggest to DISABLE that
configuration at 2.3.x branch
-D
On Wed, Jun 26, 2013 at 9:55 AM, Dan Tran <da...@gmail.com> wrote:
> Hi JB,
>
> I tested out 2.3.1 with org.apache.aries.blueprint.synchronous=true
>
> A couple of my bundles fail at start up
>
> Here is scenario ( very high level )
>
> bundle A component A.1 depends on bundle B service B.1 which depends on
> service of bundle C service C.1 which depends on Bundle A
>
> With out the flag, all of these bundles manage to come up
>
> With the flag, I got NPE
>
>
> Caused by: java.lang.IllegalStateException: getService() returned null for
> [com.xxxx.yyyy.ServiceX]
> at
> org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:242)
> at
> org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:54)
> at
> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:291)
>
>
> I think I figure out how to get away from cyclic dependencies, I will take
> time.
>
> I also want to raise this issue early so that other users be aware and
> react appropriately ( like disable that flat, at build time or event at
> production/customer site, in 2.3.2 which is not desirable )
>
> -D
>
>
>
>
>
>
>
> On Wed, Jun 26, 2013 at 9:08 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>
>> Hi Dan,
>>
>> It's completely backward compatible normally.
>>
>> Could you explain your issue ?
>>
>> Regards
>> JB
>>
>>
>> On 06/26/2013 05:55 PM, Dan Tran wrote:
>>
>>> This new default behavior introduces backward compatibility specially to
>>> bundles that depend on services from each other.
>>>
>>> Can we not apply this behavior to 2.3.x branch?
>>>
>>> I am fine with 2.4 where I will have time to do something about it
>>>
>>> Thanks
>>>
>>> -Dan
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
Re: Concern about https://issues.apache.org/jira/browse/KARAF-2273 -
not backward compatible
Posted by Dan Tran <da...@gmail.com>.
Hi JB,
I tested out 2.3.1 with org.apache.aries.blueprint.synchronous=true
A couple of my bundles fail at start up
Here is scenario ( very high level )
bundle A component A.1 depends on bundle B service B.1 which depends on
service of bundle C service C.1 which depends on Bundle A
With out the flag, all of these bundles manage to come up
With the flag, I got NPE
Caused by: java.lang.IllegalStateException: getService() returned null for
[com.xxxx.yyyy.ServiceX]
at
org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:242)
at
org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:54)
at
org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:291)
I think I figure out how to get away from cyclic dependencies, I will take
time.
I also want to raise this issue early so that other users be aware and
react appropriately ( like disable that flat, at build time or event at
production/customer site, in 2.3.2 which is not desirable )
-D
On Wed, Jun 26, 2013 at 9:08 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> Hi Dan,
>
> It's completely backward compatible normally.
>
> Could you explain your issue ?
>
> Regards
> JB
>
>
> On 06/26/2013 05:55 PM, Dan Tran wrote:
>
>> This new default behavior introduces backward compatibility specially to
>> bundles that depend on services from each other.
>>
>> Can we not apply this behavior to 2.3.x branch?
>>
>> I am fine with 2.4 where I will have time to do something about it
>>
>> Thanks
>>
>> -Dan
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Concern about https://issues.apache.org/jira/browse/KARAF-2273
- not backward compatible
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Dan,
It's completely backward compatible normally.
Could you explain your issue ?
Regards
JB
On 06/26/2013 05:55 PM, Dan Tran wrote:
> This new default behavior introduces backward compatibility specially to
> bundles that depend on services from each other.
>
> Can we not apply this behavior to 2.3.x branch?
>
> I am fine with 2.4 where I will have time to do something about it
>
> Thanks
>
> -Dan
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com