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

Reply via email to