But the latest snapshot at apache snapshot repo does not have your change Please please, help to push a new snapshot
Thanks On Thu, Mar 7, 2013 at 8:13 AM, Dan Tran <[email protected]> wrote: > It works!!! > > I replace a latest copy of blueprint.core-1.1.1-SNAPSHOT at apache > jenkins and replaced the one at my 2.3.1 karaf ( ie > blueprint.core-1.1.0 ) > > Thanks > > -D > > On Thu, Mar 7, 2013 at 6:27 AM, Guillaume Nodet <[email protected]> wrote: >> Dan, you may want to try building an aries snapshot of blueprint-core and >> see if that helps. >> I've fixed ARIES-1020 and ARIES-1025 which should help with your problems. >> >> >> On Thu, Feb 28, 2013 at 10:44 AM, Dan Tran <[email protected]> wrote: >>> >>> I am able to produce the issue with a couple of simple bundles. >>> >>> However, setting >>> >>> org.apache.aries.blueprint.preemptiveShutdown=false >>> >>> at etc/config.properties >>> >>> does not help. >>> >>> For my case now, I currently swallow the exception. But I still think >>> the blueprint service should not disappear when it not its turn to >>> shutdown yet. >>> >>> Thanks >>> >>> -D >>> >>> On Thu, Feb 28, 2013 at 12:18 AM, Guillaume Nodet <[email protected]> >>> wrote: >>> > Try setting org.apache.aries.blueprint.preemptiveShutdown=false >>> > And in all cases, your bundle should support the service to not be >>> > available. >>> > >>> > >>> > >>> > On Thu, Feb 28, 2013 at 8:46 AM, Dan Tran <[email protected]> wrote: >>> >> >>> >> It my case, i have bundle with higher start level trying to access >>> >> service from lower start level at shutdown time ( ie blueprint >>> >> destroy-method ), it seems like the lower blueprint bundle service get >>> >> removed early, even thou the bundle is not stopped yet. >>> >> >>> >> I will create a couple of simple of bundles to reproduce this issue. >>> >> >>> >> Thank you for looking into this >>> >> >>> >> -Dan >>> >> >>> >> >>> >> >>> >> On Wed, Feb 27, 2013 at 11:30 PM, Guillaume Nodet <[email protected]> >>> >> wrote: >>> >> > Could you build something that we can reproduce ? >>> >> > Ot at least give more details about what happens (services, start >>> >> > level, >>> >> > etc..) ? >>> >> > >>> >> > I've done an enhancement in blueprint so that when the extender >>> >> > detects >>> >> > that >>> >> > the framework is stopping, it will preemptively shutdown all >>> >> > blueprint >>> >> > containers. >>> >> > So is the bundle accessing the service a blueprint one ? If not, then >>> >> > that's >>> >> > somewhat expected. You can disable this behaviour by setting the >>> >> > org.apache.aries.blueprint.preemptiveShutdown=false >>> >> > in etc/config.properties >>> >> > >>> >> > However, if you expect things to just shutdown bundles in the correct >>> >> > order, >>> >> > that's not gonna happen. The framework shut them down in reverse >>> >> > start >>> >> > level order, so services are removed in that way. If a bundle with >>> >> > a >>> >> > low >>> >> > start level uses a service from a bundle with a higher start level, >>> >> > it >>> >> > won't >>> >> > be there. And that means that the bundle is flawed and should >>> >> > support >>> >> > the >>> >> > fact that one of its needed service is gone. >>> >> > >>> >> > >>> >> > >>> >> > On Sun, Feb 17, 2013 at 8:44 AM, Dan Tran <[email protected]> wrote: >>> >> >> >>> >> >> karf-2.3.1-snapshot with felix 4.2.0 does not help either. >>> >> >> >>> >> >> Thanks your for looking into this issue >>> >> >> >>> >> >> -D >>> >> >> >>> >> >> On Sat, Feb 16, 2013 at 11:40 PM, Jean-Baptiste Onofré >>> >> >> <[email protected]> >>> >> >> wrote: >>> >> >> > It sounds like a bug in Aries Blueprint. Let me try to reproduce >>> >> >> > with >>> >> >> > a >>> >> >> > simple test case. >>> >> >> > >>> >> >> > Regards >>> >> >> > JB >>> >> >> > >>> >> >> > >>> >> >> > On 02/17/2013 08:21 AM, Dan Tran wrote: >>> >> >> >> >>> >> >> >> this issue also happens in karaf 2.3.0 but it is very >>> >> >> >> intermittent, >>> >> >> >> I >>> >> >> >> am able to play with start level, and with some luck, the problem >>> >> >> >> went >>> >> >> >> away. >>> >> >> >> >>> >> >> >> Only with 2.3.1-snapshot the issue is very repeatable. >>> >> >> >> >>> >> >> >> I am going to build 2.3.1-snapshot with filix 4.2.0 to see if it >>> >> >> >> helps. >>> >> >> >> >>> >> >> >> for me both 2.3.0 and 2.3.1 is not ready for full production yet >>> >> >> >> and >>> >> >> >> I >>> >> >> >> still have some time to wait as well >>> >> >> >> >>> >> >> >> Thanks >>> >> >> >> >>> >> >> >> -D >>> >> >> >> >>> >> >> >> >>> >> >> >> On Sat, Feb 16, 2013 at 11:15 PM, Jean-Baptiste Onofré >>> >> >> >> <[email protected]> >>> >> >> >> wrote: >>> >> >> >>> >>> >> >> >>> I created a Jira to update to Felix Framework 4.2.0 but only on >>> >> >> >>> trunk >>> >> >> >>> and >>> >> >> >>> for Karaf 2.4.0. >>> >> >> >>> >>> >> >> >>> I'm going to test if it helps for this issue, if so, I will >>> >> >> >>> upgrade >>> >> >> >>> for >>> >> >> >>> Karaf 2.3.1 as well. >>> >> >> >>> >>> >> >> >>> Did you notice this issue with Karaf 2.3.0 as well ? >>> >> >> >>> >>> >> >> >>> Thanks >>> >> >> >>> Regards >>> >> >> >>> JB >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> On 02/17/2013 08:12 AM, Dan Tran wrote: >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> 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 >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> -- >>> >> >> >>> 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 >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > ------------------------ >>> >> > Guillaume Nodet >>> >> > ------------------------ >>> >> > Red Hat, Open Source Integration >>> >> > >>> >> > Email: [email protected] >>> >> > Web: http://fusesource.com >>> >> > Blog: http://gnodet.blogspot.com/ >>> >> > >>> > >>> > >>> > >>> > >>> > -- >>> > ------------------------ >>> > Guillaume Nodet >>> > ------------------------ >>> > Red Hat, Open Source Integration >>> > >>> > Email: [email protected] >>> > Web: http://fusesource.com >>> > Blog: http://gnodet.blogspot.com/ >>> > >> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Red Hat, Open Source Integration >> >> Email: [email protected] >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >>
