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é <[email protected]>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 <[email protected]> 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é <[email protected] >>> >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é >>>> [email protected] >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> >>> >>> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
