In 2.3.0, this issue is intermittent, I was able to twist start level, and luckily it disappears. In 2.3.1-SNAPSHOT, it consistently happen, In a way this is a good news since It is always reproducible.
-D On Fri, Feb 8, 2013 at 1:52 PM, Dan Tran <[email protected]> wrote: > I am testing with the latest apache-karaf-2.3.1-SNAPSHOT with latest > aries blueprint. and still see this issue > > where one of my blueprint's destroy method needs a service from > another bundle, however, that bundle's service is not longer > available. Is it bug from latest blueprint? Looks like blueprint > remove the service too early? > > > 2013-02-08 13:31:16,067 | ERROR | FelixShutdown | BeanRecipe > | s.blueprint.container.BeanRecipe 873 | 7 - > org.apache.aries.blueprint.core - 1.1.0 | The blueprint bean > fileStreamDataProviderFactory in bundle > xxxxx.data.provider.filestream/1.0.0.SNAPSHOT incorrectly threw an > exception from its destroy method. > org.osgi.service.blueprint.container.ServiceUnavailableException: The > Blueprint container is being or has been destroyed: > (objectClass=xxxxxd.data.provider.core.ConnectionFactory) > at > org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:233) > at > org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:54) > at > org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:291) > at > Proxy292eef6e_56c9_4a23_9717_803ff8d4fb86.deregisterDataProvider(Unknown > Source) > at > xxxxxx.data.provider.filestream.internal.core.DefaultFileStreamDataProviderFactory.cleanup(DefaultFileStreamDataProviderFactory.java:114) > > [....] > > 2013-02-08 13:31:16,159 | INFO | FelixShutdown | BlueprintExtender > | nt.container.BlueprintExtender$3 282 | 7 - > org.apache.aries.blueprint.core - 1.1.0 | Destroying > BlueprintContainer for bundle xxxxx.storage.core > > > The service not available bundle eventually destroyed at the end successfully > > > Thanks > > -D > > On Fri, Jan 18, 2013 at 2:21 PM, Dan Tran <[email protected]> wrote: >> Thanks JB >> >> -D >> >> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré <[email protected]> >> wrote: >>> Hi Dan, >>> >>> yes, we are working on the Aries update (to fix the Blueprint issues). >>> >>> I submitted a patch about to Aries, I gonna check if a new SNAPSHOT has been >>> deployed (at Aries) including the patch. >>> >>> I keep you posted. >>> >>> Regards >>> JB >>> >>> >>> On 01/18/2013 11:17 PM, Dan Tran wrote: >>>> >>>> I now have my apache karaf 2.3.1-snapshot to pickup blueprint-core >>>> 1.1.0-SNAPSHOT and blueprint-cm 1.0.1-SNAPSHOT >>>> >>>> my karaf.bat now hangs at startup >>>> >>>> ERROR: Bundle org.apache.aries.blueprint.cm [8] Error starting >>>> >>>> mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.cm/1.0.1-SNAPSHOT >>>> (org.osgi.framework.BundleException: Unresolved constraint in >>>> bundle org.apache.aries.blueprint.cm [8]: Unable to resolve 8.0: >>>> missing requirement [8.0] osgi.wiring.package; >>>> >>>> (&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.0.0)(!(version>=1.2.0)))) >>>> >>>> org.osgi.framework.BundleException: Unresolved constraint in bundle >>>> org.apache.aries.blueprint.cm [8]: Unable to resolve 8.0: missing >>>> requirement [8.0] osgi.wiring.package; (&(osgi.wiring.package=org. >>>> apache.aries.blueprint)(version>=1.0.0)(!(version>=1.2.0))) >>>> at >>>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) >>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) >>>> at >>>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) >>>> at >>>> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) >>>> at java.lang.Thread.run(Thread.java:722) >>>> >>>> not sure what is the artifact org.apache.aries.blueprint is from >>>> >>>> Thanks >>>> >>>> -D >>>> >>>> On Fri, Jan 18, 2013 at 12:14 PM, Christoph Gritschenberger >>>> <[email protected]> wrote: >>>>> >>>>> You also need blueprint-cm in version 1.0.1-SNAPSHOT. The version-range >>>>> for >>>>> blueprint-core has been increased there. That's all I had to do. >>>>> >>>>> blueprint-core-1.1.0-SNAPSHOT and blueprint-cm-1.0.1-SNAPSHOT >>>>> >>>>> kind regards, >>>>> christoph >>>>> >>>>> >>>>> >>>>> On 2013-01-18 20:34, Dan Tran wrote: >>>>>> >>>>>> >>>>>> I checkout the blueprint-core from trunk, which is currently at >>>>>> 1.1.0-SNAPSHOT, it it right? ) and build with apache-karaf >>>>>> 2.3.1-snapshot >>>>>> >>>>>> upon startup with karaf.bat i got the following stderr >>>>>> >>>>>> ERROR: Bundle org.apache.aries.blueprint.cm [13] Error starting >>>>>> mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.cm/1.0.0 >>>>>> (org.osgi.framework.BundleException: Unresolved constraint in bundle >>>>>> org.apache.aries.blueprint.cm [13]: Unable to resolve 13.0: missing >>>>>> requirement [13.0] osgi.wiring.package; >>>>>> >>>>>> >>>>>> (&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.0.0)(!(version>=1.1.0)))) >>>>>> org.osgi.framework.BundleException: Unresolved constraint in bundle >>>>>> org.apache.aries.blueprint.cm [13]: Unable to resolve 13.0: missing >>>>>> requirement [13.0] osgi.wiring.package; (&(osgi.wiring.package=o >>>>>> rg.apache.aries.blueprint)(version>=1.0.0)(!(version>=1.1.0))) >>>>>> at >>>>>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) >>>>>> at >>>>>> org.apache.felix.framework.Felix.startBundle(Felix.java:1868) >>>>>> at >>>>>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) >>>>>> at >>>>>> >>>>>> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) >>>>>> at java.lang.Thread.run(Thread.java:662) >>>>>> >>>>>> >>>>>> On Fri, Jan 18, 2013 at 10:37 AM, Dan Tran <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> would it be possible to have aries blueprint 1.0.2-snashot deployed? >>>>>>> >>>>>>> apache snapshot at >>>>>>> >>>>>>> >>>>>>> https://repository.apache.org/content/repositories/snapshots/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.0.2-SNAPSHOT/ >>>>>>> is quite old >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -D >>>>>>> >>>>>>> On Fri, Jan 18, 2013 at 9:09 AM, Dan Tran <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> cool, I will try to build my own version of karaf 2.3.1 snapshot to >>>>>>>> aries 1.0.2 >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -Dan >>>>>>>> >>>>>>>> On Fri, Jan 18, 2013 at 12:35 AM, Guillaume Nodet <[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Actually, I've raised and fixed >>>>>>>>> https://issues.apache.org/jira/browse/ARIES-1004 >>>>>>>>> Can you see if the latest snapshots works better for you ? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jan 18, 2013 at 8:26 AM, Guillaume Nodet <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I fix a bunch of problems with blueprint shutting down recently, so >>>>>>>>>> could >>>>>>>>>> you try with a recent blueprint snapshot and see if that helps ? >>>>>>>>>> For now, blueprint bundles are shut down roughly according to their >>>>>>>>>> start >>>>>>>>>> level. THere's something in blueprint which is supposed to better >>>>>>>>>> use the >>>>>>>>>> bundle service usage and shutdown bundles so that the problem you >>>>>>>>>> see >>>>>>>>>> would >>>>>>>>>> not happen, however, this only happen when the blueprint extender >>>>>>>>>> itself is >>>>>>>>>> stopped, which in fact, does not really help because the extender >>>>>>>>>> has >>>>>>>>>> a very >>>>>>>>>> low start level and is thus stopped very late in the process. >>>>>>>>>> Something that could be improved in blueprint is reacting to the >>>>>>>>>> fact >>>>>>>>>> that >>>>>>>>>> a framework shutdown is initiated and do that orderly shutdown >>>>>>>>>> earlier >>>>>>>>>> in >>>>>>>>>> the process. >>>>>>>>>> In all cases, your bundles should be able to deal with cases where >>>>>>>>>> one >>>>>>>>>> dependency is missing and be able to shutdown cleanly anyway. >>>>>>>>>> So I would suggest you try with the latest blueprint snapshots and >>>>>>>>>> see >>>>>>>>>> if >>>>>>>>>> it helps. I can write a patch to see if the modification i >>>>>>>>>> suggested >>>>>>>>>> above >>>>>>>>>> would help (I think it should) if you want to give it a try. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jan 16, 2013 at 9:31 PM, Dan Tran <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi JB, >>>>>>>>>>> >>>>>>>>>>> I only try 2.3, my new work does not work with 2.2 >>>>>>>>>>> >>>>>>>>>>> what is osgi/karaf shutdown sequencing flow? like it would >>>>>>>>>>> shutdown >>>>>>>>>>> all bundles with the same start- level in the order from high to >>>>>>>>>>> low >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> -D >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Jan 16, 2013 at 12:18 PM, Jean-Baptiste Onofré >>>>>>>>>>> <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Dan, >>>>>>>>>>>> >>>>>>>>>>>> did you try both with Karaf 2.2.x and 2.3.x ? >>>>>>>>>>>> did you see differences in the behavior ? >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> JB >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 01/16/2013 09:17 PM, Dan Tran wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi I have a service's PreDestroy method which requires a service >>>>>>>>>>>>> from >>>>>>>>>>>>> other bundle during shutdown. However at shutdown time, blueprint >>>>>>>>>>>>> make >>>>>>>>>>>>> the required service 'unavailable'. Using start level ordering >>>>>>>>>>>>> does >>>>>>>>>>>>> not seem to help. >>>>>>>>>>>>> >>>>>>>>>>>>> What are your experiences dealing with this issue? >>>>>>>>>>>>> >>>>>>>>>>>>> Big thanks ahead. >>>>>>>>>>>>> >>>>>>>>>>>>> -Dan >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Jean-Baptiste Onofré >>>>>>>>>>>> [email protected] >>>>>>>>>>>> http://blog.nanthrax.net >>>>>>>>>>>> Talend - http://www.talend.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------ >>>>>>>>>> Guillaume Nodet >>>>>>>>>> ------------------------ >>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>> ------------------------ >>>>>>>>>> FuseSource, Integration everywhere >>>>>>>>>> http://fusesource.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------ >>>>>>>>> Guillaume Nodet >>>>>>>>> ------------------------ >>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>> ------------------------ >>>>>>>>> FuseSource, Integration everywhere >>>>>>>>> http://fusesource.com >>>>> >>>>> >>>>> >>>>> >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com
