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

Reply via email to