Re: Orderly shutting down services

[chris . gray]

vetalok,

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

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

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

Re: Orderly shutting down services

[vetalok]

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



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

Re: Orderly shutting down services

[Dan Tran]

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
 | 

Re: Orderly shutting down services

[Dan Tran]

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 dant...@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 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. 

Re: Orderly shutting down services

[Dan Tran]

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
   x.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=xd.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)
 

Re: Orderly shutting down services

[Guillaume Nodet]

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
  x.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=xd.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
 
 
 xx.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 x.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 

Re: Orderly shutting down services

[Dan Tran]

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
  x.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=xd.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
 
 
  xx.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 x.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
  

Re: Orderly shutting down services

[Dan Tran]

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
 x.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=xd.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 
 xx.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 x.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
 

Re: Orderly shutting down services

[Jean-Baptiste Onofré]

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
x.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=xd.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 
xx.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 x.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: 

Re: Orderly shutting down services

[Dan Tran]

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
 x.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=xd.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
 xx.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 x.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.

 

Re: Orderly shutting down services

[Jean-Baptiste Onofré]

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
x.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=xd.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
xx.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 x.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

Re: Orderly shutting down services

[Dan Tran]

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
 x.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=xd.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

 xx.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 x.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 

Re: Orderly shutting down services

[Dan Tran]

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
 x.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=xd.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 
 xx.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 x.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
 

Re: Orderly shutting down services

[Dan Tran]

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
x.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=xd.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 
xx.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 x.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)

Re: Orderly shutting down services

[Guillaume Nodet]

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

Re: Orderly shutting down services

[Dan Tran]

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

Re: Orderly shutting down services

[Dan Tran]

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

Re: Orderly shutting down services

[Dan Tran]

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

Re: Orderly shutting down services

[Dan Tran]

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 

Re: Orderly shutting down services

[Jean-Baptiste Onofré]

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 

Re: Orderly shutting down services

[Dan Tran]

also apache jenkens job for aries build also failing

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

-D

On Fri, Jan 18, 2013 at 2:17 PM, Dan Tran dant...@gmail.com wrote:
 I now have my apache karaf 2.3.1-snapshot to pickup blueprint-core
 1.1.0-SNAPSHOT and blueprint-cm 1.0.1-SNAPSHOT

 my karaf.bat now hangs at startup

 ERROR: Bundle org.apache.aries.blueprint.cm [8] Error starting
 mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.cm/1.0.1-SNAPSHOT
 (org.osgi.framework.BundleException: Unresolved constraint in
  bundle org.apache.aries.blueprint.cm [8]: Unable to resolve 8.0:
 missing requirement [8.0] osgi.wiring.package;
 ((osgi.wiring.package=org.apache.aries.blueprint)(version=1.0.0)(!(version=1.2.0

 org.osgi.framework.BundleException: Unresolved constraint in bundle
 org.apache.aries.blueprint.cm [8]: Unable to resolve 8.0: missing
 requirement [8.0] osgi.wiring.package; ((osgi.wiring.package=org.
 apache.aries.blueprint)(version=1.0.0)(!(version=1.2.0)))
 at 
 org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
 at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
 at 
 org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
 at 
 org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
 at java.lang.Thread.run(Thread.java:722)

 not sure what is the artifact org.apache.aries.blueprint is from

 Thanks

 -D

 On Fri, Jan 18, 2013 at 12:14 PM, Christoph Gritschenberger
 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 

Re: Orderly shutting down services

[Dan Tran]

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 

Re: Orderly shutting down services

[Guillaume Nodet]

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

Re: Orderly shutting down services

[Jean-Baptiste Onofré]

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

Re: Orderly shutting down services

[Dan Tran]

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