May be an upgrade to felix 4.2 is needed?
On Mon, Feb 11, 2013 at 8:56 AM, Dan Tran <[email protected]> wrote: > 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
