You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Guillaume Nodet <gn...@gmail.com> on 2013/03/07 15:27:50 UTC
Re: Orderly shutting down services
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
Posted by 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
Posted by 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
Posted by 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
Posted by 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/
>