Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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

Re: Orderly shutting down services

[ch...@kiffer.ltd.uk]

vetalok,

> Can one bundle that fails trigger whole framework to stop?

If it fails hard enough, yes.  In fact even if it calls System.exit() ...

Suggest you first investigate this as a general Java-application-crashes
problem, e.g. collect and analyse heap dumps (hprof files), run whole
process in debugger if feasible, etc. ...

Re: Orderly shutting down services

[vetalok <ve...@gmail.com>]

Guys, 
Could you please help me to resolve problem with unexpected Karaf shutdown?
I was asked this question  here
<http://stackoverflow.com/questions/35288889/karaf-stops-unexpectedly>   but
it still not answered. Here is the question:
After upgrading Karaf from 2.2.11 to 4.0.3 with log4j2 support and running
load tests of our Karaf based application, Karaf unexpectedly starts
shutdown process. 
We increased most of memory options but it did not help. 
No info in logs - just "Stopping blueprint extender" and "Unregistering
bundles...". Above these messages there was debug info from my bundles. In
manifest files of our bundles old OSGI container is used
(org.osgi.framework;version="1.3.0"). This occurs only with load tests, for
single threaded scenarios there are no problems. 
Can one bundle that fails trigger whole framework to stop? 
Any ideas why Karaf 4.0.3 is not stable and where we need to investigate?



--
View this message in context: http://karaf.922171.n3.nabble.com/Orderly-shutting-down-services-tp4027336p4045447.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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 <da...@gmail.com> 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 <gn...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>> >> 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 <da...@gmail.com> 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é
>>> >> >> <jb...@nanthrax.net>
>>> >> >> 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é
>>> >> >> >> <jb...@nanthrax.net>
>>> >> >> >> 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 <da...@gmail.com>
>>> >> >> >>>> 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 <da...@gmail.com>
>>> >> >> >>>>> 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 <da...@gmail.com>
>>> >> >> >>>>>> wrote:
>>> >> >> >>>>>>>
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> Thanks JB
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> -D
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré
>>> >> >> >>>>>>> <jb...@nanthrax.net>
>>> >> >> >>>>>>> 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
>>> >> >> >>>>>>>>> <ch...@gmail.com> 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
>>> >> >> >>>>>>>>>>> <da...@gmail.com>
>>> >> >> >>>>>>>>>>> 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
>>> >> >> >>>>>>>>>>>> <da...@gmail.com>
>>> >> >> >>>>>>>>>>>> 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
>>> >> >> >>>>>>>>>>>>> <gn...@gmail.com>
>>> >> >> >>>>>>>>>>>>> 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
>>> >> >> >>>>>>>>>>>>>> <gn...@gmail.com>
>>> >> >> >>>>>>>>>>>>>> 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
>>> >> >> >>>>>>>>>>>>>>> <da...@gmail.com>
>>> >> >> >>>>>>>>>>>>>>> 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é
>>> >> >> >>>>>>>>>>>>>>>> <jb...@nanthrax.net>
>>> >> >> >>>>>>>>>>>>>>>> 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é
>>> >> >> >>>>>>>>>>>>>>>>> jbonofre@apache.org
>>> >> >> >>>>>>>>>>>>>>>>> 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é
>>> >> >> >>>>>>>> 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
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Jean-Baptiste Onofré
>>> >> >> > jbonofre@apache.org
>>> >> >> > http://blog.nanthrax.net
>>> >> >> > Talend - http://www.talend.com
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > ------------------------
>>> >> > Guillaume Nodet
>>> >> > ------------------------
>>> >> > Red Hat, Open Source Integration
>>> >> >
>>> >> > Email: gnodet@redhat.com
>>> >> > Web: http://fusesource.com
>>> >> > Blog: http://gnodet.blogspot.com/
>>> >> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > ------------------------
>>> > Guillaume Nodet
>>> > ------------------------
>>> > Red Hat, Open Source Integration
>>> >
>>> > Email: gnodet@redhat.com
>>> > Web: http://fusesource.com
>>> > Blog: http://gnodet.blogspot.com/
>>> >
>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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 <gn...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>> >> 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 <da...@gmail.com> 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é
>> >> >> <jb...@nanthrax.net>
>> >> >> 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é
>> >> >> >> <jb...@nanthrax.net>
>> >> >> >> 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 <da...@gmail.com>
>> >> >> >>>> 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 <da...@gmail.com>
>> >> >> >>>>> 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 <da...@gmail.com>
>> >> >> >>>>>> wrote:
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>> Thanks JB
>> >> >> >>>>>>>
>> >> >> >>>>>>> -D
>> >> >> >>>>>>>
>> >> >> >>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré
>> >> >> >>>>>>> <jb...@nanthrax.net>
>> >> >> >>>>>>> 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
>> >> >> >>>>>>>>> <ch...@gmail.com> 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
>> >> >> >>>>>>>>>>> <da...@gmail.com>
>> >> >> >>>>>>>>>>> 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
>> >> >> >>>>>>>>>>>> <da...@gmail.com>
>> >> >> >>>>>>>>>>>> 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
>> >> >> >>>>>>>>>>>>> <gn...@gmail.com>
>> >> >> >>>>>>>>>>>>> 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
>> >> >> >>>>>>>>>>>>>> <gn...@gmail.com>
>> >> >> >>>>>>>>>>>>>> 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
>> >> >> >>>>>>>>>>>>>>> <da...@gmail.com>
>> >> >> >>>>>>>>>>>>>>> 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é
>> >> >> >>>>>>>>>>>>>>>> <jb...@nanthrax.net>
>> >> >> >>>>>>>>>>>>>>>> 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é
>> >> >> >>>>>>>>>>>>>>>>> jbonofre@apache.org
>> >> >> >>>>>>>>>>>>>>>>> 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é
>> >> >> >>>>>>>> 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
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Jean-Baptiste Onofré
>> >> >> > jbonofre@apache.org
>> >> >> > http://blog.nanthrax.net
>> >> >> > Talend - http://www.talend.com
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > ------------------------
>> >> > Guillaume Nodet
>> >> > ------------------------
>> >> > Red Hat, Open Source Integration
>> >> >
>> >> > Email: gnodet@redhat.com
>> >> > Web: http://fusesource.com
>> >> > Blog: http://gnodet.blogspot.com/
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> > ------------------------
>> > Red Hat, Open Source Integration
>> >
>> > Email: gnodet@redhat.com
>> > Web: http://fusesource.com
>> > Blog: http://gnodet.blogspot.com/
>> >
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Re: Orderly shutting down services

[Guillaume Nodet <gn...@gmail.com>]

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 <da...@gmail.com> 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 <gn...@gmail.com>
> 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 <da...@gmail.com> 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 <gn...@gmail.com>
> >> 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 <da...@gmail.com> 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é
> >> >> <jb...@nanthrax.net>
> >> >> 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é
> >> >> >> <jb...@nanthrax.net>
> >> >> >> 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 <da...@gmail.com>
> >> >> >>>> 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 <da...@gmail.com>
> >> >> >>>>> 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 <da...@gmail.com>
> >> >> >>>>>> wrote:
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> Thanks JB
> >> >> >>>>>>>
> >> >> >>>>>>> -D
> >> >> >>>>>>>
> >> >> >>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré
> >> >> >>>>>>> <jb...@nanthrax.net>
> >> >> >>>>>>> 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
> >> >> >>>>>>>>> <ch...@gmail.com> 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
> >> >> >>>>>>>>>>> <da...@gmail.com>
> >> >> >>>>>>>>>>> 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
> >> >> >>>>>>>>>>>> <da...@gmail.com>
> >> >> >>>>>>>>>>>> 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
> >> >> >>>>>>>>>>>>> <gn...@gmail.com>
> >> >> >>>>>>>>>>>>> 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
> >> >> >>>>>>>>>>>>>> <gn...@gmail.com>
> >> >> >>>>>>>>>>>>>> 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
> >> >> >>>>>>>>>>>>>>> <da...@gmail.com>
> >> >> >>>>>>>>>>>>>>> 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é
> >> >> >>>>>>>>>>>>>>>> <jb...@nanthrax.net>
> >> >> >>>>>>>>>>>>>>>> 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é
> >> >> >>>>>>>>>>>>>>>>> jbonofre@apache.org
> >> >> >>>>>>>>>>>>>>>>> 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é
> >> >> >>>>>>>> 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
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Jean-Baptiste Onofré
> >> >> > jbonofre@apache.org
> >> >> > http://blog.nanthrax.net
> >> >> > Talend - http://www.talend.com
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > ------------------------
> >> > Guillaume Nodet
> >> > ------------------------
> >> > Red Hat, Open Source Integration
> >> >
> >> > Email: gnodet@redhat.com
> >> > Web: http://fusesource.com
> >> > Blog: http://gnodet.blogspot.com/
> >> >
> >
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: gnodet@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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 <gn...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>> 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 <da...@gmail.com> 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é
>> >> <jb...@nanthrax.net>
>> >> 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é
>> >> >> <jb...@nanthrax.net>
>> >> >> 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 <da...@gmail.com>
>> >> >>>> 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 <da...@gmail.com>
>> >> >>>>> 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 <da...@gmail.com>
>> >> >>>>>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> Thanks JB
>> >> >>>>>>>
>> >> >>>>>>> -D
>> >> >>>>>>>
>> >> >>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré
>> >> >>>>>>> <jb...@nanthrax.net>
>> >> >>>>>>> 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
>> >> >>>>>>>>> <ch...@gmail.com> 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
>> >> >>>>>>>>>>> <da...@gmail.com>
>> >> >>>>>>>>>>> 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
>> >> >>>>>>>>>>>> <da...@gmail.com>
>> >> >>>>>>>>>>>> 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
>> >> >>>>>>>>>>>>> <gn...@gmail.com>
>> >> >>>>>>>>>>>>> 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
>> >> >>>>>>>>>>>>>> <gn...@gmail.com>
>> >> >>>>>>>>>>>>>> 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
>> >> >>>>>>>>>>>>>>> <da...@gmail.com>
>> >> >>>>>>>>>>>>>>> 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é
>> >> >>>>>>>>>>>>>>>> <jb...@nanthrax.net>
>> >> >>>>>>>>>>>>>>>> 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é
>> >> >>>>>>>>>>>>>>>>> jbonofre@apache.org
>> >> >>>>>>>>>>>>>>>>> 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é
>> >> >>>>>>>> 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
>> >> >
>> >> >
>> >> > --
>> >> > Jean-Baptiste Onofré
>> >> > jbonofre@apache.org
>> >> > http://blog.nanthrax.net
>> >> > Talend - http://www.talend.com
>> >
>> >
>> >
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> > ------------------------
>> > Red Hat, Open Source Integration
>> >
>> > Email: gnodet@redhat.com
>> > Web: http://fusesource.com
>> > Blog: http://gnodet.blogspot.com/
>> >
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Re: Orderly shutting down services

[Guillaume Nodet <gn...@gmail.com>]

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 <da...@gmail.com> 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 <gn...@gmail.com>
> 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 <da...@gmail.com> 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é <jb@nanthrax.net
> >
> >> 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é
> >> >> <jb...@nanthrax.net>
> >> >> 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 <da...@gmail.com>
> 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 <da...@gmail.com>
> 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 <da...@gmail.com>
> >> >>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> Thanks JB
> >> >>>>>>>
> >> >>>>>>> -D
> >> >>>>>>>
> >> >>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré
> >> >>>>>>> <jb...@nanthrax.net>
> >> >>>>>>> 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
> >> >>>>>>>>> <ch...@gmail.com> 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 <
> dantran@gmail.com>
> >> >>>>>>>>>>> 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 <
> dantran@gmail.com>
> >> >>>>>>>>>>>> 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
> >> >>>>>>>>>>>>> <gn...@gmail.com>
> >> >>>>>>>>>>>>> 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
> >> >>>>>>>>>>>>>> <gn...@gmail.com>
> >> >>>>>>>>>>>>>> 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
> >> >>>>>>>>>>>>>>> <da...@gmail.com>
> >> >>>>>>>>>>>>>>> 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é
> >> >>>>>>>>>>>>>>>> <jb...@nanthrax.net>
> >> >>>>>>>>>>>>>>>> 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é
> >> >>>>>>>>>>>>>>>>> jbonofre@apache.org
> >> >>>>>>>>>>>>>>>>> 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é
> >> >>>>>>>> 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
> >> >
> >> >
> >> > --
> >> > Jean-Baptiste Onofré
> >> > jbonofre@apache.org
> >> > http://blog.nanthrax.net
> >> > Talend - http://www.talend.com
> >
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: gnodet@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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 <gn...@gmail.com> 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 <da...@gmail.com> 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é <jb...@nanthrax.net>
>> 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é
>> >> <jb...@nanthrax.net>
>> >> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Thanks JB
>> >>>>>>>
>> >>>>>>> -D
>> >>>>>>>
>> >>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré
>> >>>>>>> <jb...@nanthrax.net>
>> >>>>>>> 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
>> >>>>>>>>> <ch...@gmail.com> 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 <da...@gmail.com>
>> >>>>>>>>>>> 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 <da...@gmail.com>
>> >>>>>>>>>>>> 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
>> >>>>>>>>>>>>> <gn...@gmail.com>
>> >>>>>>>>>>>>> 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
>> >>>>>>>>>>>>>> <gn...@gmail.com>
>> >>>>>>>>>>>>>> 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
>> >>>>>>>>>>>>>>> <da...@gmail.com>
>> >>>>>>>>>>>>>>> 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é
>> >>>>>>>>>>>>>>>> <jb...@nanthrax.net>
>> >>>>>>>>>>>>>>>> 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é
>> >>>>>>>>>>>>>>>>> jbonofre@apache.org
>> >>>>>>>>>>>>>>>>> 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é
>> >>>>>>>> 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
>> >
>> >
>> > --
>> > Jean-Baptiste Onofré
>> > jbonofre@apache.org
>> > http://blog.nanthrax.net
>> > Talend - http://www.talend.com
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Re: Orderly shutting down services

[Guillaume Nodet <gn...@gmail.com>]

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 <da...@gmail.com> 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é <jb...@nanthrax.net>
> 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é <jb@nanthrax.net
> >
> >> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks JB
> >>>>>>>
> >>>>>>> -D
> >>>>>>>
> >>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré
> >>>>>>> <jb...@nanthrax.net>
> >>>>>>> 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
> >>>>>>>>> <ch...@gmail.com> 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 <da...@gmail.com>
> >>>>>>>>>>> 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 <da...@gmail.com>
> >>>>>>>>>>>> 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
> >>>>>>>>>>>>> <gn...@gmail.com>
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>>>> <gn...@gmail.com>
> >>>>>>>>>>>>>> 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 <
> dantran@gmail.com>
> >>>>>>>>>>>>>>> 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é
> >>>>>>>>>>>>>>>> <jb...@nanthrax.net>
> >>>>>>>>>>>>>>>> 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é
> >>>>>>>>>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>>>>>>>>> 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é
> >>>>>>>> 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
> >
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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é <jb...@nanthrax.net> 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é <jb...@nanthrax.net>
>> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Thanks JB
>>>>>>>
>>>>>>> -D
>>>>>>>
>>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré
>>>>>>> <jb...@nanthrax.net>
>>>>>>> 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
>>>>>>>>> <ch...@gmail.com> 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 <da...@gmail.com>
>>>>>>>>>>> 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 <da...@gmail.com>
>>>>>>>>>>>> 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
>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>> 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 <da...@gmail.com>
>>>>>>>>>>>>>>> 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é
>>>>>>>>>>>>>>>> <jb...@nanthrax.net>
>>>>>>>>>>>>>>>> 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é
>>>>>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>>>>>> 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é
>>>>>>>> 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
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Orderly shutting down services

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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é <jb...@nanthrax.net> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> wrote:
>>>>>>
>>>>>> Thanks JB
>>>>>>
>>>>>> -D
>>>>>>
>>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>>> 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
>>>>>>>> <ch...@gmail.com> 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 <da...@gmail.com>
>>>>>>>>>> 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 <da...@gmail.com>
>>>>>>>>>>> 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
>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>> 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
>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>> 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 <da...@gmail.com>
>>>>>>>>>>>>>> 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é
>>>>>>>>>>>>>>> <jb...@nanthrax.net>
>>>>>>>>>>>>>>> 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é
>>>>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>>>>> 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é
>>>>>>> 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

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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é <jb...@nanthrax.net> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> wrote:
>>>>>
>>>>> Thanks JB
>>>>>
>>>>> -D
>>>>>
>>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>>> 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
>>>>>>> <ch...@gmail.com> 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 <da...@gmail.com>
>>>>>>>>> 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 <da...@gmail.com>
>>>>>>>>>> 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
>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>> 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
>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>> 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 <da...@gmail.com>
>>>>>>>>>>>>> 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é
>>>>>>>>>>>>>> <jb...@nanthrax.net>
>>>>>>>>>>>>>> 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é
>>>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>>>> 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é
>>>>>> 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: Orderly shutting down services

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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 <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> wrote:
>>>> Thanks JB
>>>>
>>>> -D
>>>>
>>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> 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
>>>>>> <ch...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>>>>>>>>> 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 <gn...@gmail.com>
>>>>>>>>>>> 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 <da...@gmail.com> 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é
>>>>>>>>>>>>> <jb...@nanthrax.net>
>>>>>>>>>>>>> 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é
>>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>>> 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é
>>>>> 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: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

May be an upgrade to felix 4.2 is needed?

On Mon, Feb 11, 2013 at 8:56 AM, Dan Tran <da...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> wrote:
>>> Thanks JB
>>>
>>> -D
>>>
>>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> 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
>>>>> <ch...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>>>>>>>> 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 <gn...@gmail.com>
>>>>>>>>>> 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 <da...@gmail.com> 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é
>>>>>>>>>>>> <jb...@nanthrax.net>
>>>>>>>>>>>> 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é
>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>> 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é
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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 <da...@gmail.com> 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 <da...@gmail.com> wrote:
>> Thanks JB
>>
>> -D
>>
>> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> 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
>>>> <ch...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>>>>>>> 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 <gn...@gmail.com>
>>>>>>>>> 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 <da...@gmail.com> 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é
>>>>>>>>>>> <jb...@nanthrax.net>
>>>>>>>>>>> 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é
>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>> 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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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 <da...@gmail.com> wrote:
> Thanks JB
>
> -D
>
> On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> 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
>>> <ch...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>>>>>> 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 <gn...@gmail.com>
>>>>>>>> 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 <da...@gmail.com> 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é
>>>>>>>>>> <jb...@nanthrax.net>
>>>>>>>>>> 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é
>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>> 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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

Thanks JB

-D

On Fri, Jan 18, 2013 at 2:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> 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
>> <ch...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>>>>> 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 <gn...@gmail.com>
>>>>>>> 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 <da...@gmail.com> 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é
>>>>>>>>> <jb...@nanthrax.net>
>>>>>>>>> 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é
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> 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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Orderly shutting down services

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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
> <ch...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>>>> 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 <gn...@gmail.com>
>>>>>> 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 <da...@gmail.com> 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é
>>>>>>>> <jb...@nanthrax.net>
>>>>>>>> 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é
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> 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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

also apache jenkens job for aries build also failing

https://builds.apache.org/job/AriesWithSnapshotDependencies/339/console

-D

On Fri, Jan 18, 2013 at 2:17 PM, Dan Tran <da...@gmail.com> 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
> <ch...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>>>> 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 <gn...@gmail.com>
>>>>>> 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 <da...@gmail.com> 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é
>>>>>>>> <jb...@nanthrax.net>
>>>>>>>> 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é
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> 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
>>
>>
>>

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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
<ch...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com>
>>>> 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 <gn...@gmail.com>
>>>>> 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 <da...@gmail.com> 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é
>>>>>>> <jb...@nanthrax.net>
>>>>>>> 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é
>>>>>>>> jbonofre@apache.org
>>>>>>>> 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
>
>
>

Re: Orderly shutting down services

[Christoph Gritschenberger <ch...@gmail.com>]

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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <da...@gmail.com> 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é <jb...@nanthrax.net>
>>>>>> 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é
>>>>>>> jbonofre@apache.org
>>>>>>> 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

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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 <da...@gmail.com> 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 <da...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <da...@gmail.com> 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é <jb...@nanthrax.net>
>>>>> 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é
>>>>> > jbonofre@apache.org
>>>>> > 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

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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 <da...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <da...@gmail.com> 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é <jb...@nanthrax.net>
>>>> 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é
>>>> > jbonofre@apache.org
>>>> > 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

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <da...@gmail.com> 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é <jb...@nanthrax.net>
>>> 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é
>>> > jbonofre@apache.org
>>> > 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

Re: Orderly shutting down services

[Guillaume Nodet <gn...@gmail.com>]

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 <gn...@gmail.com> 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 <da...@gmail.com> 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é <jb...@nanthrax.net>
>> 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é
>> > jbonofre@apache.org
>> > 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

Re: Orderly shutting down services

[Guillaume Nodet <gn...@gmail.com>]

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 <da...@gmail.com> 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é <jb...@nanthrax.net>
> 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é
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: Orderly shutting down services

[Dan Tran <da...@gmail.com>]

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é <jb...@nanthrax.net> 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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Orderly shutting down services

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com