You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by "KARR, DAVID" <dk...@att.com> on 2017/09/29 17:30:17 UTC
What kind of things would prevent a set of bundles from going
Active?
I'm still working with the legacy app using Karaf 3.0.1, which I don't have very good overall documentation for.
I've been able to execute my "feature:install" command in the karaf console, which appeared to complete successfully, but at that point it's apparently expected that all of my bundles are in an "Active" state. However, for some reason most of them are not. Some are, but some of the application-specific bundles are "Installed", or even "Grace Period".
I've checked the karaf.log, and there are no obvious red flags.
When I try to hit my REST service at localhost:8181, it just times out, which is not surprising, as the bundle in question probably is not active.
I also tried installing the web console. I just did "feature:install webconsole" and then went to "http://localhost:8181/system/console" in my browser. This timed out.
What should I be looking at to diagnose this?
Re: What kind of things would prevent a set of bundles from going
Active?
Posted by David Jencks <da...@gmail.com>.
You could look into ldap filter syntax for a complete explanation. Roughly speaking, there are simple clauses such as a=b, logical operations & | ! and enough parentheses to make everything unambiguous.
david jencks
> On Oct 2, 2017, at 4:37 PM, KARR, DAVID <dk...@att.com> wrote:
>
>> -----Original Message-----
>> From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net <ma...@nanthrax.net>]
>> Sent: Friday, September 29, 2017 10:49 PM
>> To: user@karaf.apache.org <ma...@karaf.apache.org>
>> Subject: Re: What kind of things would prevent a set of bundles from
>> going Active?
>>
>> Hi,
>>
>> When a bundle is resolved, it means that the constraints resolution is
>> OK.
>> Basically, Import packages & requirements are satisfied.
>>
>> So, a bundle stays in Installed state if it can go to Resolved due to a
>> unsatisfied resolution constraint (for instance an imported package is
>> not present).
>>
>> When a bundle is in Resolved state, it's possible to start it. Basically
>> it means calling the start method of the activator. If the start method
>> works and didn't throw an exception, then, the bundle becomes active.
>>
>> In the case of blueprint, the activator is managed by blueprint. Grace-
>> Period means that blueprint is looking for a dependency service at
>> startup and it doesn't find it. So, he's waiting for the service.
>>
>> bundle:diag or log gives you detail about the service not present.
>
> Thanks for the reply. This is helping.
>
> Running "bundle:diag" did give me some useful output. Running "log" just returned to the prompt.
>
> An excerpt from the "bundle:diag" output is here:
> ------------------
> apis-base (82)
> --------------
> Status: Installed
> Unsatisfied Requirements:
> [82.0] osgi.wiring.package; (&(osgi.wiring.package=org.apache.commons.io <http://org.apache.commons.io/>)(version>=1.4.0)(!(version>=2.0.0)))
> [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz)
> [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz.impl)
>
> onemap-impl (89)
> ----------------
> Status: Installed
> Unsatisfied Requirements:
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=com.att.ecom.base.util)(version>=1.1.0)(!(version>=2.0.0)))
> [89.0] osgi.wiring.package; (osgi.wiring.package=com.att.ecom.onemap.api.constants)
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.ehcache)(version>=2.5.0)(!(version>=3.0.0)))
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.ehcache.config)(version>=2.5.0)(!(version>=3.0.0)))
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.ehcache.store)(version>=2.5.0)(!(version>=3.0.0)))
> [89.0] osgi.wiring.package; (osgi.wiring.package=org.springframework.dao)
> [89.0] osgi.wiring.package; (osgi.wiring.package=org.springframework.jdbc.core)
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=org.springframework.xml.xpath)(version>=2.0.0)(!(version>=3.0.0)))
> ------------------
>
> In the past, I've tried to find a guide for fully interpreting these error messages, but I've always ended up just blundering through it. Is there a clear guide for how to interpret these somewhere? I could guess that the first bundle needs commons-io and quartz, and the second needs ehcache, some spring artifacts, and a couple of application-specific artifacts, and I can interpret some of those version expressions, but I don't understand why it sometimes has the "&()" wrapper (is that always when there's a version expression?).
>
>> On 09/29/2017 07:30 PM, KARR, DAVID wrote:
>>> I'm still working with the legacy app using Karaf 3.0.1, which I don't
>> have very good overall documentation for.
>>>
>>> I've been able to execute my "feature:install" command in the karaf
>> console, which appeared to complete successfully, but at that point it's
>> apparently expected that all of my bundles are in an "Active" state.
>> However, for some reason most of them are not. Some are, but some of
>> the application-specific bundles are "Installed", or even "Grace
>> Period".
>>>
>>> I've checked the karaf.log, and there are no obvious red flags.
>>>
>>> When I try to hit my REST service at localhost:8181, it just times
>> out, which is not surprising, as the bundle in question probably is not
>> active.
>>>
>>> I also tried installing the web console. I just did "feature:install
>> webconsole" and then went to "http://localhost:8181/system/console <http://localhost:8181/system/console>" in
>> my browser. This timed out.
>>>
>>> What should I be looking at to diagnose this?
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> https://urldefense.proofpoint.com/v2/url?u=http- <https://urldefense.proofpoint.com/v2/url?u=http->
>> 3A__blog.nanthrax.net&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
>> xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=jl9mLMBBmRS
>> FeUETzUN7l8dHAQbh5CGPlgZd6fqUSJI&e=
>> Talend - https://urldefense.proofpoint.com/v2/url?u=http- <https://urldefense.proofpoint.com/v2/url?u=http->
>> 3A__www.talend.com&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
>> xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=ZcPGU_vMwhY
>> t2Zoc_2TdHZKrZ1Z-wyM2owPWlY6nFM0&e=
Re: What kind of things would prevent a set of bundles from going Active?
Posted by Guillaume Nodet <gn...@apache.org>.
Fwiw, the commands works for me on 4.1.x and 4.2.x
*karaf*@root()> bundle:headers > headers.txt
*karaf*@root()> exec ls
LICENSE
NOTICE
README
RELEASE-NOTES
bin
data
deploy
etc
headers.txt
instances
karaf.pid
lib
lock
system
2017-10-06 0:13 GMT+02:00 KARR, DAVID <dk...@att.com>:
> > -----Original Message-----
> > From: KARR, DAVID
> > Sent: Thursday, October 05, 2017 2:14 PM
> > To: user@karaf.apache.org
> > Subject: RE: What kind of things would prevent a set of bundles from
> > going Active?
> >
> > > -----Original Message-----
> > > From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> > > Sent: Wednesday, October 04, 2017 9:58 PM
> > > To: user@karaf.apache.org
> > > Subject: Re: What kind of things would prevent a set of bundles from
> > > going Active?
> > >
> > > You can actually check the packages available with the packages:*
> > > commands.
> >
> > Running either "packages:exports" or "packages:imports" gives "Command
> > not found".
> >
> > > bundle:headers also gives you details about the wiring.
> >
> > Sort of a side question, but how can I write the output of a command to
> > a file, and peruse the output outside of the console?
> >
> > I tried "bundle:headers > headers.txt", which behaved as if it was
> > writing the output to the file, but then I couldn't find the file
> > anywhere on my box.
>
> I figured out the very non-obvious use of "command | tac -f filename".
>
> > I wouldn't have to do this if I was able to ssh into the console, my
> > problems with which are described in a note on this list from a few days
> > ago.
> >
> > > On 10/04/2017 07:54 PM, KARR, DAVID wrote:
> > > > What’s confusing about this is that those packages appear to be
> > > > present, but perhaps they’re not being presented properly, and the
> > > > requested version ranges are strange.
> > > >
> > > > I find the quartz artifact in my .m2/repository, version 2.1.5 as
> > > > specified in our properties files. I also find the relevant Spring
> > > > artifacts, but version 3.2.4.RELEASE (also as specified in
> > > > properties). That version expression says that it is looking for a
> > > version less than 3.0.0. I don’t understand why that is.
> > > >
> > > > *From:* cschneider111@gmail.com [mailto:cschneider111@gmail.com] *On
> > > > Behalf Of *Christian Schneider
> > > > *Sent:* Tuesday, October 03, 2017 10:15 PM
> > > > *To:* user@karaf.apache.org
> > > > *Subject:* Re: What kind of things would prevent a set of bundles
> > > > from
> > > going Active?
> > > >
> > > > For each bundle that can not be resolved diag shows the dependency
> > > > tree of the requirement the resolver failed on.
> > > >
> > > > Typically you look at the line at the bottom. This is what is really
> > > > missing. In your case it means:
> > > >
> > > > The package org.quartz.impl is missing.
> > > >
> > > > The package org.springframework.xml.xpath with a version
> > > > [2.0.0,3.0.0)
> > > ias missing.
> > > >
> > > > The strings are in polish notation which make them unambiguous like
> > > > David wrote but also hard to read if you are not used to it.
> > > >
> > > > Christian
> > > >
> > > > 2017-10-03 1:37 GMT+02:00 KARR, DAVID <dk068x@att.com
> > > <ma...@att.com>>:
> > > >
> > > > > -----Original Message-----
> > > > > From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net
> > > <ma...@nanthrax.net>]
> > > > > Sent: Friday, September 29, 2017 10:49 PM
> > > > > To: user@karaf.apache.org <ma...@karaf.apache.org>
> > > > > Subject: Re: What kind of things would prevent a set of
> > > > bundles
> > > from
> > > > > going Active?
> > > > >
> > > > > Hi,
> > > > >
> > > > > When a bundle is resolved, it means that the constraints
> > > resolution is
> > > > > OK.
> > > > > Basically, Import packages & requirements are satisfied.
> > > > >
> > > > > So, a bundle stays in Installed state if it can go to
> > > > Resolved
> > > due to a
> > > > > unsatisfied resolution constraint (for instance an imported
> > > package is
> > > > > not present).
> > > > >
> > > > > When a bundle is in Resolved state, it's possible to start
> > it.
> > > Basically
> > > > > it means calling the start method of the activator. If the
> > > start method
> > > > > works and didn't throw an exception, then, the bundle becomes
> > > active.
> > > > >
> > > > > In the case of blueprint, the activator is managed by
> > > blueprint. Grace-
> > > > > Period means that blueprint is looking for a dependency
> > > > service
> > > at
> > > > > startup and it doesn't find it. So, he's waiting for the
> > > service.
> > > > >
> > > > > bundle:diag or log gives you detail about the service not
> > > present.
> > > >
> > > > Thanks for the reply. This is helping.
> > > >
> > > > Running "bundle:diag" did give me some useful output. Running
> > > "log" just
> > > > returned to the prompt.
> > > >
> > > > An excerpt from the "bundle:diag" output is here:
> > > > ------------------
> > > > apis-base (82)
> > > > --------------
> > > > Status: Installed
> > > > Unsatisfied Requirements:
> > > > [82.0] osgi.wiring.package;
> > > (&(osgi.wiring.package=org.apache.commons.io
> > > > <https://urldefense.proofpoint.com/v2/url?u=http-
> > > 3A__org.apache.commons.io&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXE
> > > n-
> > > xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=Sroqq0ikL
> > > qB
> > > Cw2IqT1qc-
> > > ukvJqIodJsi3hH1qILBihM&e=>)(version>=1.4.0)(!(version>=2.0.0)))
> > > > [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz)
> > > > [82.0] osgi.wiring.package;
> > > > (osgi.wiring.package=org.quartz.impl)
> > > >
> > > > onemap-impl (89)
> > > > ----------------
> > > > Status: Installed
> > > > Unsatisfied Requirements:
> > > > [89.0] osgi.wiring.package;
> > > >
> > > (&(osgi.wiring.package=com.att.ecom.base.util)(version>=1.1.0)(!(versi
> > > on
> > > >=2.0.0)))
> > > > [89.0] osgi.wiring.package;
> > > > (osgi.wiring.package=com.att.ecom.onemap.api.constants)
> > > > [89.0] osgi.wiring.package;
> > > >
> > > (&(osgi.wiring.package=net.sf.ehcache)(version>=2.5.0)(!(version>=3.0.
> > > 0)
> > > ))
> > > > [89.0] osgi.wiring.package;
> > > >
> > > (&(osgi.wiring.package=net.sf.ehcache.config)(version>=2.5.0)(!(versio
> > > n>
> > > =3.0.0)))
> > > > [89.0] osgi.wiring.package;
> > > >
> > > (&(osgi.wiring.package=net.sf.ehcache.store)(version>=2.5.0)(!(version
> > > >=
> > > 3.0.0)))
> > > > [89.0] osgi.wiring.package;
> > > (osgi.wiring.package=org.springframework.dao)
> > > > [89.0] osgi.wiring.package;
> > > (osgi.wiring.package=org.springframework.jdbc.core)
> > > > [89.0] osgi.wiring.package;
> > > >
> > > (&(osgi.wiring.package=org.springframework.xml.xpath)(version>=2.0.0)(
> > > !(
> > > version>=3.0.0)))
> > > > ------------------
> > > >
> > > > In the past, I've tried to find a guide for fully interpreting
> > > these error
> > > > messages, but I've always ended up just blundering through it.
> > > > Is
> > > there a
> > > > clear guide for how to interpret these somewhere? I could guess
> > > that the
> > > > first bundle needs commons-io and quartz, and the second needs
> > > ehcache, some
> > > > spring artifacts, and a couple of application-specific
> > > > artifacts,
> > > and I can
> > > > interpret some of those version expressions, but I don't
> > > understand why it
> > > > sometimes has the "&()" wrapper (is that always when there's a
> > > version
> > > > expression?).
> > > >
> > > > > On 09/29/2017 07:30 PM, KARR, DAVID wrote:
> > > > > > I'm still working with the legacy app using Karaf 3.0.1,
> > > which I don't
> > > > > have very good overall documentation for.
> > > > > >
> > > > > > I've been able to execute my "feature:install" command in
> > > > the
> > > karaf
> > > > > console, which appeared to complete successfully, but at that
> > > point it's
> > > > > apparently expected that all of my bundles are in an "Active"
> > > state.
> > > > > However, for some reason most of them are not. Some are, but
> > > some of
> > > > > the application-specific bundles are "Installed", or even
> > > "Grace
> > > > > Period".
> > > > > >
> > > > > > I've checked the karaf.log, and there are no obvious red
> > > flags.
> > > > > >
> > > > > > When I try to hit my REST service at localhost:8181, it
> > > > just
> > > times
> > > > > out, which is not surprising, as the bundle in question
> > > probably is not
> > > > > active.
> > > > > >
> > > > > > I also tried installing the web console. I just did
> > > "feature:install
> > > > > webconsole" and then went to
> > > "http://localhost:8181/system/console" in
> > > > > my browser. This timed out.
> > > > > >
> > > > > > What should I be looking at to diagnose this?
> > > > > >
> > > > >
> > > > > --
> > > > > Jean-Baptiste Onofré
> > > > > jbonofre@apache.org <ma...@apache.org>
> > > > > https://urldefense.proofpoint.com/v2/url?u=http-
> > > > > 3A__blog.nanthrax.net
> > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-
> > > 5Fblog.nanthrax.net&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > > xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=183dl-
> > > n0jyIayv3W4Sa0ZmQAds0rULtG_tfaAhBD9T0&e=>&d=DwIDaQ&c=LFYZ-
> > > o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > > > >
> > > xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=jl9mLMBBm
> > > RS
> > > > > FeUETzUN7l8dHAQbh5CGPlgZd6fqUSJI&e=
> > > > > Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> > > > > 3A__www.talend.com
> > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-
> > > 5Fwww.talend.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > > xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=dFH73q3dy
> > > _A
> > > HWMrBmRmvPfa05oD5w6zCEzeYtClLSNw&e=>&d=DwIDaQ&c=LFYZ-
> > > o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > > > >
> > > xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=ZcPGU_vMw
> > > hY
> > > > > t2Zoc_2TdHZKrZ1Z-wyM2owPWlY6nFM0&e=
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > --
> > > > Christian Schneider
> > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.liquid-2Drea
> > > > li
> > > > ty.de&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=u
> > > > vs
> > > > yQNSH95-x80guhhYZXWlX1lqZKZxOy62d-pLfANc&s=oqch2t-t9p3zdAX1JFbMog5KX
> > > > EC
> > > > 434XLv2C6D35h_qQ&e=
> > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__owa.talend.com
> > > > _o
> > > > wa_redir.aspx-3FC-3D3aa4083e0c744ae1ba52bd062c5a7e46-26URL-3Dhttp-25
> > > > 3a
> > > > -252f-252fwww.liquid-2Dreality.de&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&
> > > > r=
> > > > OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU
> > > > &s =XA1g_edbuF0uLDolXaY7sLvXsAufVqxXS4pXHBhIPX0&e=>
> > > >
> > > > Computer Scientist
> > > >
> > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adobe.com&d=
> > > > Dw
> > > > IDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=uvsyQNSH95-
> > > > x8
> > > > 0guhhYZXWlX1lqZKZxOy62d-pLfANc&s=2lBE-kof-4ZKEx4yMWxOctGGW5ytCGq9EDg
> > > > yf
> > > > Osbzeg&e=
> > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adobe.com&d
> > > > =D
> > > > wMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLX
> > > > X8
> > > > vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=j5d5pJJFEcyJY7GSdGav9yUx9tOTMdV2YM
> > > > Ti
> > > > 26h1J7o&e=>
> > > >
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbonofre@apache.org
> > > https://urldefense.proofpoint.com/v2/url?u=http-
> > > 3A__blog.nanthrax.net&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > > xy2uk0vYF_EA&m=uvsyQNSH95-x80guhhYZXWlX1lqZKZxOy62d-
> > > pLfANc&s=VW3bA1xavrTnr0Ca6JoFfDab1JAUaNDXjdA8tHfq5ms&e=
> > > Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> > > 3A__www.talend.com&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > > xy2uk0vYF_EA&m=uvsyQNSH95-x80guhhYZXWlX1lqZKZxOy62d-pLfANc&s=zxB-
> > > 9Zxqn8S_iAjr73tz2dLwyAMbyqzYIDYyPoj-HgQ&e=
>
--
------------------------
Guillaume Nodet
RE: What kind of things would prevent a set of bundles from going
Active?
Posted by "KARR, DAVID" <dk...@att.com>.
> -----Original Message-----
> From: KARR, DAVID
> Sent: Thursday, October 05, 2017 2:14 PM
> To: user@karaf.apache.org
> Subject: RE: What kind of things would prevent a set of bundles from
> going Active?
>
> > -----Original Message-----
> > From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> > Sent: Wednesday, October 04, 2017 9:58 PM
> > To: user@karaf.apache.org
> > Subject: Re: What kind of things would prevent a set of bundles from
> > going Active?
> >
> > You can actually check the packages available with the packages:*
> > commands.
>
> Running either "packages:exports" or "packages:imports" gives "Command
> not found".
>
> > bundle:headers also gives you details about the wiring.
>
> Sort of a side question, but how can I write the output of a command to
> a file, and peruse the output outside of the console?
>
> I tried "bundle:headers > headers.txt", which behaved as if it was
> writing the output to the file, but then I couldn't find the file
> anywhere on my box.
I figured out the very non-obvious use of "command | tac -f filename".
> I wouldn't have to do this if I was able to ssh into the console, my
> problems with which are described in a note on this list from a few days
> ago.
>
> > On 10/04/2017 07:54 PM, KARR, DAVID wrote:
> > > What’s confusing about this is that those packages appear to be
> > > present, but perhaps they’re not being presented properly, and the
> > > requested version ranges are strange.
> > >
> > > I find the quartz artifact in my .m2/repository, version 2.1.5 as
> > > specified in our properties files. I also find the relevant Spring
> > > artifacts, but version 3.2.4.RELEASE (also as specified in
> > > properties). That version expression says that it is looking for a
> > version less than 3.0.0. I don’t understand why that is.
> > >
> > > *From:* cschneider111@gmail.com [mailto:cschneider111@gmail.com] *On
> > > Behalf Of *Christian Schneider
> > > *Sent:* Tuesday, October 03, 2017 10:15 PM
> > > *To:* user@karaf.apache.org
> > > *Subject:* Re: What kind of things would prevent a set of bundles
> > > from
> > going Active?
> > >
> > > For each bundle that can not be resolved diag shows the dependency
> > > tree of the requirement the resolver failed on.
> > >
> > > Typically you look at the line at the bottom. This is what is really
> > > missing. In your case it means:
> > >
> > > The package org.quartz.impl is missing.
> > >
> > > The package org.springframework.xml.xpath with a version
> > > [2.0.0,3.0.0)
> > ias missing.
> > >
> > > The strings are in polish notation which make them unambiguous like
> > > David wrote but also hard to read if you are not used to it.
> > >
> > > Christian
> > >
> > > 2017-10-03 1:37 GMT+02:00 KARR, DAVID <dk068x@att.com
> > <ma...@att.com>>:
> > >
> > > > -----Original Message-----
> > > > From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net
> > <ma...@nanthrax.net>]
> > > > Sent: Friday, September 29, 2017 10:49 PM
> > > > To: user@karaf.apache.org <ma...@karaf.apache.org>
> > > > Subject: Re: What kind of things would prevent a set of
> > > bundles
> > from
> > > > going Active?
> > > >
> > > > Hi,
> > > >
> > > > When a bundle is resolved, it means that the constraints
> > resolution is
> > > > OK.
> > > > Basically, Import packages & requirements are satisfied.
> > > >
> > > > So, a bundle stays in Installed state if it can go to
> > > Resolved
> > due to a
> > > > unsatisfied resolution constraint (for instance an imported
> > package is
> > > > not present).
> > > >
> > > > When a bundle is in Resolved state, it's possible to start
> it.
> > Basically
> > > > it means calling the start method of the activator. If the
> > start method
> > > > works and didn't throw an exception, then, the bundle becomes
> > active.
> > > >
> > > > In the case of blueprint, the activator is managed by
> > blueprint. Grace-
> > > > Period means that blueprint is looking for a dependency
> > > service
> > at
> > > > startup and it doesn't find it. So, he's waiting for the
> > service.
> > > >
> > > > bundle:diag or log gives you detail about the service not
> > present.
> > >
> > > Thanks for the reply. This is helping.
> > >
> > > Running "bundle:diag" did give me some useful output. Running
> > "log" just
> > > returned to the prompt.
> > >
> > > An excerpt from the "bundle:diag" output is here:
> > > ------------------
> > > apis-base (82)
> > > --------------
> > > Status: Installed
> > > Unsatisfied Requirements:
> > > [82.0] osgi.wiring.package;
> > (&(osgi.wiring.package=org.apache.commons.io
> > > <https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__org.apache.commons.io&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXE
> > n-
> > xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=Sroqq0ikL
> > qB
> > Cw2IqT1qc-
> > ukvJqIodJsi3hH1qILBihM&e=>)(version>=1.4.0)(!(version>=2.0.0)))
> > > [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz)
> > > [82.0] osgi.wiring.package;
> > > (osgi.wiring.package=org.quartz.impl)
> > >
> > > onemap-impl (89)
> > > ----------------
> > > Status: Installed
> > > Unsatisfied Requirements:
> > > [89.0] osgi.wiring.package;
> > >
> > (&(osgi.wiring.package=com.att.ecom.base.util)(version>=1.1.0)(!(versi
> > on
> > >=2.0.0)))
> > > [89.0] osgi.wiring.package;
> > > (osgi.wiring.package=com.att.ecom.onemap.api.constants)
> > > [89.0] osgi.wiring.package;
> > >
> > (&(osgi.wiring.package=net.sf.ehcache)(version>=2.5.0)(!(version>=3.0.
> > 0)
> > ))
> > > [89.0] osgi.wiring.package;
> > >
> > (&(osgi.wiring.package=net.sf.ehcache.config)(version>=2.5.0)(!(versio
> > n>
> > =3.0.0)))
> > > [89.0] osgi.wiring.package;
> > >
> > (&(osgi.wiring.package=net.sf.ehcache.store)(version>=2.5.0)(!(version
> > >=
> > 3.0.0)))
> > > [89.0] osgi.wiring.package;
> > (osgi.wiring.package=org.springframework.dao)
> > > [89.0] osgi.wiring.package;
> > (osgi.wiring.package=org.springframework.jdbc.core)
> > > [89.0] osgi.wiring.package;
> > >
> > (&(osgi.wiring.package=org.springframework.xml.xpath)(version>=2.0.0)(
> > !(
> > version>=3.0.0)))
> > > ------------------
> > >
> > > In the past, I've tried to find a guide for fully interpreting
> > these error
> > > messages, but I've always ended up just blundering through it.
> > > Is
> > there a
> > > clear guide for how to interpret these somewhere? I could guess
> > that the
> > > first bundle needs commons-io and quartz, and the second needs
> > ehcache, some
> > > spring artifacts, and a couple of application-specific
> > > artifacts,
> > and I can
> > > interpret some of those version expressions, but I don't
> > understand why it
> > > sometimes has the "&()" wrapper (is that always when there's a
> > version
> > > expression?).
> > >
> > > > On 09/29/2017 07:30 PM, KARR, DAVID wrote:
> > > > > I'm still working with the legacy app using Karaf 3.0.1,
> > which I don't
> > > > have very good overall documentation for.
> > > > >
> > > > > I've been able to execute my "feature:install" command in
> > > the
> > karaf
> > > > console, which appeared to complete successfully, but at that
> > point it's
> > > > apparently expected that all of my bundles are in an "Active"
> > state.
> > > > However, for some reason most of them are not. Some are, but
> > some of
> > > > the application-specific bundles are "Installed", or even
> > "Grace
> > > > Period".
> > > > >
> > > > > I've checked the karaf.log, and there are no obvious red
> > flags.
> > > > >
> > > > > When I try to hit my REST service at localhost:8181, it
> > > just
> > times
> > > > out, which is not surprising, as the bundle in question
> > probably is not
> > > > active.
> > > > >
> > > > > I also tried installing the web console. I just did
> > "feature:install
> > > > webconsole" and then went to
> > "http://localhost:8181/system/console" in
> > > > my browser. This timed out.
> > > > >
> > > > > What should I be looking at to diagnose this?
> > > > >
> > > >
> > > > --
> > > > Jean-Baptiste Onofré
> > > > jbonofre@apache.org <ma...@apache.org>
> > > > https://urldefense.proofpoint.com/v2/url?u=http-
> > > > 3A__blog.nanthrax.net
> > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-
> > 5Fblog.nanthrax.net&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=183dl-
> > n0jyIayv3W4Sa0ZmQAds0rULtG_tfaAhBD9T0&e=>&d=DwIDaQ&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > > >
> > xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=jl9mLMBBm
> > RS
> > > > FeUETzUN7l8dHAQbh5CGPlgZd6fqUSJI&e=
> > > > Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> > > > 3A__www.talend.com
> > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-
> > 5Fwww.talend.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=dFH73q3dy
> > _A
> > HWMrBmRmvPfa05oD5w6zCEzeYtClLSNw&e=>&d=DwIDaQ&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > > >
> > xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=ZcPGU_vMw
> > hY
> > > > t2Zoc_2TdHZKrZ1Z-wyM2owPWlY6nFM0&e=
> > >
> > >
> > >
> > > --
> > >
> > > --
> > > Christian Schneider
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.liquid-2Drea
> > > li
> > > ty.de&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=u
> > > vs
> > > yQNSH95-x80guhhYZXWlX1lqZKZxOy62d-pLfANc&s=oqch2t-t9p3zdAX1JFbMog5KX
> > > EC
> > > 434XLv2C6D35h_qQ&e=
> > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__owa.talend.com
> > > _o
> > > wa_redir.aspx-3FC-3D3aa4083e0c744ae1ba52bd062c5a7e46-26URL-3Dhttp-25
> > > 3a
> > > -252f-252fwww.liquid-2Dreality.de&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&
> > > r=
> > > OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU
> > > &s =XA1g_edbuF0uLDolXaY7sLvXsAufVqxXS4pXHBhIPX0&e=>
> > >
> > > Computer Scientist
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adobe.com&d=
> > > Dw
> > > IDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=uvsyQNSH95-
> > > x8
> > > 0guhhYZXWlX1lqZKZxOy62d-pLfANc&s=2lBE-kof-4ZKEx4yMWxOctGGW5ytCGq9EDg
> > > yf
> > > Osbzeg&e=
> > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adobe.com&d
> > > =D
> > > wMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLX
> > > X8
> > > vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=j5d5pJJFEcyJY7GSdGav9yUx9tOTMdV2YM
> > > Ti
> > > 26h1J7o&e=>
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__blog.nanthrax.net&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=uvsyQNSH95-x80guhhYZXWlX1lqZKZxOy62d-
> > pLfANc&s=VW3bA1xavrTnr0Ca6JoFfDab1JAUaNDXjdA8tHfq5ms&e=
> > Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__www.talend.com&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=uvsyQNSH95-x80guhhYZXWlX1lqZKZxOy62d-pLfANc&s=zxB-
> > 9Zxqn8S_iAjr73tz2dLwyAMbyqzYIDYyPoj-HgQ&e=
RE: What kind of things would prevent a set of bundles from going
Active?
Posted by "KARR, DAVID" <dk...@att.com>.
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> Sent: Wednesday, October 04, 2017 9:58 PM
> To: user@karaf.apache.org
> Subject: Re: What kind of things would prevent a set of bundles from
> going Active?
>
> You can actually check the packages available with the packages:*
> commands.
Running either "packages:exports" or "packages:imports" gives "Command not found".
> bundle:headers also gives you details about the wiring.
Sort of a side question, but how can I write the output of a command to a file, and peruse the output outside of the console?
I tried "bundle:headers > headers.txt", which behaved as if it was writing the output to the file, but then I couldn't find the file anywhere on my box.
I wouldn't have to do this if I was able to ssh into the console, my problems with which are described in a note on this list from a few days ago.
> On 10/04/2017 07:54 PM, KARR, DAVID wrote:
> > What’s confusing about this is that those packages appear to be
> > present, but perhaps they’re not being presented properly, and the
> > requested version ranges are strange.
> >
> > I find the quartz artifact in my .m2/repository, version 2.1.5 as
> > specified in our properties files. I also find the relevant Spring
> > artifacts, but version 3.2.4.RELEASE (also as specified in
> > properties). That version expression says that it is looking for a
> version less than 3.0.0. I don’t understand why that is.
> >
> > *From:* cschneider111@gmail.com [mailto:cschneider111@gmail.com] *On
> > Behalf Of *Christian Schneider
> > *Sent:* Tuesday, October 03, 2017 10:15 PM
> > *To:* user@karaf.apache.org
> > *Subject:* Re: What kind of things would prevent a set of bundles from
> going Active?
> >
> > For each bundle that can not be resolved diag shows the dependency
> > tree of the requirement the resolver failed on.
> >
> > Typically you look at the line at the bottom. This is what is really
> > missing. In your case it means:
> >
> > The package org.quartz.impl is missing.
> >
> > The package org.springframework.xml.xpath with a version [2.0.0,3.0.0)
> ias missing.
> >
> > The strings are in polish notation which make them unambiguous like
> > David wrote but also hard to read if you are not used to it.
> >
> > Christian
> >
> > 2017-10-03 1:37 GMT+02:00 KARR, DAVID <dk068x@att.com
> <ma...@att.com>>:
> >
> > > -----Original Message-----
> > > From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net
> <ma...@nanthrax.net>]
> > > Sent: Friday, September 29, 2017 10:49 PM
> > > To: user@karaf.apache.org <ma...@karaf.apache.org>
> > > Subject: Re: What kind of things would prevent a set of bundles
> from
> > > going Active?
> > >
> > > Hi,
> > >
> > > When a bundle is resolved, it means that the constraints
> resolution is
> > > OK.
> > > Basically, Import packages & requirements are satisfied.
> > >
> > > So, a bundle stays in Installed state if it can go to Resolved
> due to a
> > > unsatisfied resolution constraint (for instance an imported
> package is
> > > not present).
> > >
> > > When a bundle is in Resolved state, it's possible to start it.
> Basically
> > > it means calling the start method of the activator. If the
> start method
> > > works and didn't throw an exception, then, the bundle becomes
> active.
> > >
> > > In the case of blueprint, the activator is managed by
> blueprint. Grace-
> > > Period means that blueprint is looking for a dependency service
> at
> > > startup and it doesn't find it. So, he's waiting for the
> service.
> > >
> > > bundle:diag or log gives you detail about the service not
> present.
> >
> > Thanks for the reply. This is helping.
> >
> > Running "bundle:diag" did give me some useful output. Running
> "log" just
> > returned to the prompt.
> >
> > An excerpt from the "bundle:diag" output is here:
> > ------------------
> > apis-base (82)
> > --------------
> > Status: Installed
> > Unsatisfied Requirements:
> > [82.0] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.commons.io
> > <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__org.apache.commons.io&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=Sroqq0ikLqB
> Cw2IqT1qc-
> ukvJqIodJsi3hH1qILBihM&e=>)(version>=1.4.0)(!(version>=2.0.0)))
> > [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz)
> > [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz.impl)
> >
> > onemap-impl (89)
> > ----------------
> > Status: Installed
> > Unsatisfied Requirements:
> > [89.0] osgi.wiring.package;
> >
> (&(osgi.wiring.package=com.att.ecom.base.util)(version>=1.1.0)(!(version
> >=2.0.0)))
> > [89.0] osgi.wiring.package;
> > (osgi.wiring.package=com.att.ecom.onemap.api.constants)
> > [89.0] osgi.wiring.package;
> >
> (&(osgi.wiring.package=net.sf.ehcache)(version>=2.5.0)(!(version>=3.0.0)
> ))
> > [89.0] osgi.wiring.package;
> >
> (&(osgi.wiring.package=net.sf.ehcache.config)(version>=2.5.0)(!(version>
> =3.0.0)))
> > [89.0] osgi.wiring.package;
> >
> (&(osgi.wiring.package=net.sf.ehcache.store)(version>=2.5.0)(!(version>=
> 3.0.0)))
> > [89.0] osgi.wiring.package;
> (osgi.wiring.package=org.springframework.dao)
> > [89.0] osgi.wiring.package;
> (osgi.wiring.package=org.springframework.jdbc.core)
> > [89.0] osgi.wiring.package;
> >
> (&(osgi.wiring.package=org.springframework.xml.xpath)(version>=2.0.0)(!(
> version>=3.0.0)))
> > ------------------
> >
> > In the past, I've tried to find a guide for fully interpreting
> these error
> > messages, but I've always ended up just blundering through it. Is
> there a
> > clear guide for how to interpret these somewhere? I could guess
> that the
> > first bundle needs commons-io and quartz, and the second needs
> ehcache, some
> > spring artifacts, and a couple of application-specific artifacts,
> and I can
> > interpret some of those version expressions, but I don't
> understand why it
> > sometimes has the "&()" wrapper (is that always when there's a
> version
> > expression?).
> >
> > > On 09/29/2017 07:30 PM, KARR, DAVID wrote:
> > > > I'm still working with the legacy app using Karaf 3.0.1,
> which I don't
> > > have very good overall documentation for.
> > > >
> > > > I've been able to execute my "feature:install" command in the
> karaf
> > > console, which appeared to complete successfully, but at that
> point it's
> > > apparently expected that all of my bundles are in an "Active"
> state.
> > > However, for some reason most of them are not. Some are, but
> some of
> > > the application-specific bundles are "Installed", or even
> "Grace
> > > Period".
> > > >
> > > > I've checked the karaf.log, and there are no obvious red
> flags.
> > > >
> > > > When I try to hit my REST service at localhost:8181, it just
> times
> > > out, which is not surprising, as the bundle in question
> probably is not
> > > active.
> > > >
> > > > I also tried installing the web console. I just did
> "feature:install
> > > webconsole" and then went to
> "http://localhost:8181/system/console" in
> > > my browser. This timed out.
> > > >
> > > > What should I be looking at to diagnose this?
> > > >
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbonofre@apache.org <ma...@apache.org>
> > > https://urldefense.proofpoint.com/v2/url?u=http-
> > > 3A__blog.nanthrax.net
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-
> 5Fblog.nanthrax.net&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=183dl-
> n0jyIayv3W4Sa0ZmQAds0rULtG_tfaAhBD9T0&e=>&d=DwIDaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > >
> xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=jl9mLMBBmRS
> > > FeUETzUN7l8dHAQbh5CGPlgZd6fqUSJI&e=
> > > Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> > > 3A__www.talend.com
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-
> 5Fwww.talend.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=dFH73q3dy_A
> HWMrBmRmvPfa05oD5w6zCEzeYtClLSNw&e=>&d=DwIDaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > >
> xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=ZcPGU_vMwhY
> > > t2Zoc_2TdHZKrZ1Z-wyM2owPWlY6nFM0&e=
> >
> >
> >
> > --
> >
> > --
> > Christian Schneider
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.liquid-2Dreali
> > ty.de&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=uvs
> > yQNSH95-x80guhhYZXWlX1lqZKZxOy62d-pLfANc&s=oqch2t-t9p3zdAX1JFbMog5KXEC
> > 434XLv2C6D35h_qQ&e=
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__owa.talend.com_o
> > wa_redir.aspx-3FC-3D3aa4083e0c744ae1ba52bd062c5a7e46-26URL-3Dhttp-253a
> > -252f-252fwww.liquid-2Dreality.de&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=
> > OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s
> > =XA1g_edbuF0uLDolXaY7sLvXsAufVqxXS4pXHBhIPX0&e=>
> >
> > Computer Scientist
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adobe.com&d=Dw
> > IDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=uvsyQNSH95-x8
> > 0guhhYZXWlX1lqZKZxOy62d-pLfANc&s=2lBE-kof-4ZKEx4yMWxOctGGW5ytCGq9EDgyf
> > Osbzeg&e=
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adobe.com&d=D
> > wMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8
> > vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=j5d5pJJFEcyJY7GSdGav9yUx9tOTMdV2YMTi
> > 26h1J7o&e=>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__blog.nanthrax.net&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=uvsyQNSH95-x80guhhYZXWlX1lqZKZxOy62d-
> pLfANc&s=VW3bA1xavrTnr0Ca6JoFfDab1JAUaNDXjdA8tHfq5ms&e=
> Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.talend.com&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=uvsyQNSH95-x80guhhYZXWlX1lqZKZxOy62d-pLfANc&s=zxB-
> 9Zxqn8S_iAjr73tz2dLwyAMbyqzYIDYyPoj-HgQ&e=
Re: What kind of things would prevent a set of bundles from going
Active?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
You can actually check the packages available with the packages:* commands.
bundle:headers also gives you details about the wiring.
Regards
JB
On 10/04/2017 07:54 PM, KARR, DAVID wrote:
> What’s confusing about this is that those packages appear to be present, but
> perhaps they’re not being presented properly, and the requested version ranges
> are strange.
>
> I find the quartz artifact in my .m2/repository, version 2.1.5 as specified in
> our properties files. I also find the relevant Spring artifacts, but version
> 3.2.4.RELEASE (also as specified in properties). That version expression says
> that it is looking for a version less than 3.0.0. I don’t understand why that is.
>
> *From:* cschneider111@gmail.com [mailto:cschneider111@gmail.com] *On Behalf Of
> *Christian Schneider
> *Sent:* Tuesday, October 03, 2017 10:15 PM
> *To:* user@karaf.apache.org
> *Subject:* Re: What kind of things would prevent a set of bundles from going Active?
>
> For each bundle that can not be resolved diag shows the dependency tree of the
> requirement the resolver failed on.
>
> Typically you look at the line at the bottom. This is what is really missing. In
> your case it means:
>
> The package org.quartz.impl is missing.
>
> The package org.springframework.xml.xpath with a version [2.0.0,3.0.0) ias missing.
>
> The strings are in polish notation which make them unambiguous like David wrote
> but also hard to read if you are not used to it.
>
> Christian
>
> 2017-10-03 1:37 GMT+02:00 KARR, DAVID <dk068x@att.com <ma...@att.com>>:
>
> > -----Original Message-----
> > From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net <ma...@nanthrax.net>]
> > Sent: Friday, September 29, 2017 10:49 PM
> > To: user@karaf.apache.org <ma...@karaf.apache.org>
> > Subject: Re: What kind of things would prevent a set of bundles from
> > going Active?
> >
> > Hi,
> >
> > When a bundle is resolved, it means that the constraints resolution is
> > OK.
> > Basically, Import packages & requirements are satisfied.
> >
> > So, a bundle stays in Installed state if it can go to Resolved due to a
> > unsatisfied resolution constraint (for instance an imported package is
> > not present).
> >
> > When a bundle is in Resolved state, it's possible to start it. Basically
> > it means calling the start method of the activator. If the start method
> > works and didn't throw an exception, then, the bundle becomes active.
> >
> > In the case of blueprint, the activator is managed by blueprint. Grace-
> > Period means that blueprint is looking for a dependency service at
> > startup and it doesn't find it. So, he's waiting for the service.
> >
> > bundle:diag or log gives you detail about the service not present.
>
> Thanks for the reply. This is helping.
>
> Running "bundle:diag" did give me some useful output. Running "log" just
> returned to the prompt.
>
> An excerpt from the "bundle:diag" output is here:
> ------------------
> apis-base (82)
> --------------
> Status: Installed
> Unsatisfied Requirements:
> [82.0] osgi.wiring.package; (&(osgi.wiring.package=org.apache.commons.io
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__org.apache.commons.io&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=Sroqq0ikLqBCw2IqT1qc-ukvJqIodJsi3hH1qILBihM&e=>)(version>=1.4.0)(!(version>=2.0.0)))
> [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz)
> [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz.impl)
>
> onemap-impl (89)
> ----------------
> Status: Installed
> Unsatisfied Requirements:
> [89.0] osgi.wiring.package;
> (&(osgi.wiring.package=com.att.ecom.base.util)(version>=1.1.0)(!(version>=2.0.0)))
> [89.0] osgi.wiring.package;
> (osgi.wiring.package=com.att.ecom.onemap.api.constants)
> [89.0] osgi.wiring.package;
> (&(osgi.wiring.package=net.sf.ehcache)(version>=2.5.0)(!(version>=3.0.0)))
> [89.0] osgi.wiring.package;
> (&(osgi.wiring.package=net.sf.ehcache.config)(version>=2.5.0)(!(version>=3.0.0)))
> [89.0] osgi.wiring.package;
> (&(osgi.wiring.package=net.sf.ehcache.store)(version>=2.5.0)(!(version>=3.0.0)))
> [89.0] osgi.wiring.package; (osgi.wiring.package=org.springframework.dao)
> [89.0] osgi.wiring.package; (osgi.wiring.package=org.springframework.jdbc.core)
> [89.0] osgi.wiring.package;
> (&(osgi.wiring.package=org.springframework.xml.xpath)(version>=2.0.0)(!(version>=3.0.0)))
> ------------------
>
> In the past, I've tried to find a guide for fully interpreting these error
> messages, but I've always ended up just blundering through it. Is there a
> clear guide for how to interpret these somewhere? I could guess that the
> first bundle needs commons-io and quartz, and the second needs ehcache, some
> spring artifacts, and a couple of application-specific artifacts, and I can
> interpret some of those version expressions, but I don't understand why it
> sometimes has the "&()" wrapper (is that always when there's a version
> expression?).
>
> > On 09/29/2017 07:30 PM, KARR, DAVID wrote:
> > > I'm still working with the legacy app using Karaf 3.0.1, which I don't
> > have very good overall documentation for.
> > >
> > > I've been able to execute my "feature:install" command in the karaf
> > console, which appeared to complete successfully, but at that point it's
> > apparently expected that all of my bundles are in an "Active" state.
> > However, for some reason most of them are not. Some are, but some of
> > the application-specific bundles are "Installed", or even "Grace
> > Period".
> > >
> > > I've checked the karaf.log, and there are no obvious red flags.
> > >
> > > When I try to hit my REST service at localhost:8181, it just times
> > out, which is not surprising, as the bundle in question probably is not
> > active.
> > >
> > > I also tried installing the web console. I just did "feature:install
> > webconsole" and then went to "http://localhost:8181/system/console" in
> > my browser. This timed out.
> > >
> > > What should I be looking at to diagnose this?
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org <ma...@apache.org>
> > https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__blog.nanthrax.net
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-5Fblog.nanthrax.net&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=183dl-n0jyIayv3W4Sa0ZmQAds0rULtG_tfaAhBD9T0&e=>&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=jl9mLMBBmRS
> > FeUETzUN7l8dHAQbh5CGPlgZd6fqUSJI&e=
> > Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__www.talend.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-5Fwww.talend.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=dFH73q3dy_AHWMrBmRmvPfa05oD5w6zCEzeYtClLSNw&e=>&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=ZcPGU_vMwhY
> > t2Zoc_2TdHZKrZ1Z-wyM2owPWlY6nFM0&e=
>
>
>
> --
>
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__owa.talend.com_owa_redir.aspx-3FC-3D3aa4083e0c744ae1ba52bd062c5a7e46-26URL-3Dhttp-253a-252f-252fwww.liquid-2Dreality.de&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=XA1g_edbuF0uLDolXaY7sLvXsAufVqxXS4pXHBhIPX0&e=>
>
> Computer Scientist
>
> http://www.adobe.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adobe.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=j5d5pJJFEcyJY7GSdGav9yUx9tOTMdV2YMTi26h1J7o&e=>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: What kind of things would prevent a set of bundles from going
Active?
Posted by "KARR, DAVID" <dk...@att.com>.
What’s confusing about this is that those packages appear to be present, but perhaps they’re not being presented properly, and the requested version ranges are strange.
I find the quartz artifact in my .m2/repository, version 2.1.5 as specified in our properties files. I also find the relevant Spring artifacts, but version 3.2.4.RELEASE (also as specified in properties). That version expression says that it is looking for a version less than 3.0.0. I don’t understand why that is.
From: cschneider111@gmail.com [mailto:cschneider111@gmail.com] On Behalf Of Christian Schneider
Sent: Tuesday, October 03, 2017 10:15 PM
To: user@karaf.apache.org
Subject: Re: What kind of things would prevent a set of bundles from going Active?
For each bundle that can not be resolved diag shows the dependency tree of the requirement the resolver failed on.
Typically you look at the line at the bottom. This is what is really missing. In your case it means:
The package org.quartz.impl is missing.
The package org.springframework.xml.xpath with a version [2.0.0,3.0.0) ias missing.
The strings are in polish notation which make them unambiguous like David wrote but also hard to read if you are not used to it.
Christian
2017-10-03 1:37 GMT+02:00 KARR, DAVID <dk...@att.com>>:
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net<ma...@nanthrax.net>]
> Sent: Friday, September 29, 2017 10:49 PM
> To: user@karaf.apache.org<ma...@karaf.apache.org>
> Subject: Re: What kind of things would prevent a set of bundles from
> going Active?
>
> Hi,
>
> When a bundle is resolved, it means that the constraints resolution is
> OK.
> Basically, Import packages & requirements are satisfied.
>
> So, a bundle stays in Installed state if it can go to Resolved due to a
> unsatisfied resolution constraint (for instance an imported package is
> not present).
>
> When a bundle is in Resolved state, it's possible to start it. Basically
> it means calling the start method of the activator. If the start method
> works and didn't throw an exception, then, the bundle becomes active.
>
> In the case of blueprint, the activator is managed by blueprint. Grace-
> Period means that blueprint is looking for a dependency service at
> startup and it doesn't find it. So, he's waiting for the service.
>
> bundle:diag or log gives you detail about the service not present.
Thanks for the reply. This is helping.
Running "bundle:diag" did give me some useful output. Running "log" just returned to the prompt.
An excerpt from the "bundle:diag" output is here:
------------------
apis-base (82)
--------------
Status: Installed
Unsatisfied Requirements:
[82.0] osgi.wiring.package; (&(osgi.wiring.package=org.apache.commons.io<https://urldefense.proofpoint.com/v2/url?u=http-3A__org.apache.commons.io&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=Sroqq0ikLqBCw2IqT1qc-ukvJqIodJsi3hH1qILBihM&e=>)(version>=1.4.0)(!(version>=2.0.0)))
[82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz)
[82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz.impl)
onemap-impl (89)
----------------
Status: Installed
Unsatisfied Requirements:
[89.0] osgi.wiring.package; (&(osgi.wiring.package=com.att.ecom.base.util)(version>=1.1.0)(!(version>=2.0.0)))
[89.0] osgi.wiring.package; (osgi.wiring.package=com.att.ecom.onemap.api.constants)
[89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.ehcache)(version>=2.5.0)(!(version>=3.0.0)))
[89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.ehcache.config)(version>=2.5.0)(!(version>=3.0.0)))
[89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.ehcache.store)(version>=2.5.0)(!(version>=3.0.0)))
[89.0] osgi.wiring.package; (osgi.wiring.package=org.springframework.dao)
[89.0] osgi.wiring.package; (osgi.wiring.package=org.springframework.jdbc.core)
[89.0] osgi.wiring.package; (&(osgi.wiring.package=org.springframework.xml.xpath)(version>=2.0.0)(!(version>=3.0.0)))
------------------
In the past, I've tried to find a guide for fully interpreting these error messages, but I've always ended up just blundering through it. Is there a clear guide for how to interpret these somewhere? I could guess that the first bundle needs commons-io and quartz, and the second needs ehcache, some spring artifacts, and a couple of application-specific artifacts, and I can interpret some of those version expressions, but I don't understand why it sometimes has the "&()" wrapper (is that always when there's a version expression?).
> On 09/29/2017 07:30 PM, KARR, DAVID wrote:
> > I'm still working with the legacy app using Karaf 3.0.1, which I don't
> have very good overall documentation for.
> >
> > I've been able to execute my "feature:install" command in the karaf
> console, which appeared to complete successfully, but at that point it's
> apparently expected that all of my bundles are in an "Active" state.
> However, for some reason most of them are not. Some are, but some of
> the application-specific bundles are "Installed", or even "Grace
> Period".
> >
> > I've checked the karaf.log, and there are no obvious red flags.
> >
> > When I try to hit my REST service at localhost:8181, it just times
> out, which is not surprising, as the bundle in question probably is not
> active.
> >
> > I also tried installing the web console. I just did "feature:install
> webconsole" and then went to "http://localhost:8181/system/console" in
> my browser. This timed out.
> >
> > What should I be looking at to diagnose this?
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org<ma...@apache.org>
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__blog.nanthrax.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-5Fblog.nanthrax.net&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=183dl-n0jyIayv3W4Sa0ZmQAds0rULtG_tfaAhBD9T0&e=>&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=jl9mLMBBmRS
> FeUETzUN7l8dHAQbh5CGPlgZd6fqUSJI&e=
> Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.talend.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-5Fwww.talend.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=dFH73q3dy_AHWMrBmRmvPfa05oD5w6zCEzeYtClLSNw&e=>&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=ZcPGU_vMwhY
> t2Zoc_2TdHZKrZ1Z-wyM2owPWlY6nFM0&e=
--
--
Christian Schneider
http://www.liquid-reality.de<https://urldefense.proofpoint.com/v2/url?u=https-3A__owa.talend.com_owa_redir.aspx-3FC-3D3aa4083e0c744ae1ba52bd062c5a7e46-26URL-3Dhttp-253a-252f-252fwww.liquid-2Dreality.de&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=XA1g_edbuF0uLDolXaY7sLvXsAufVqxXS4pXHBhIPX0&e=>
Computer Scientist
http://www.adobe.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adobe.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-xy2uk0vYF_EA&m=ywsgJ_pZLXX8vzZNai1vxoxc946N5Ls_M8h0G5a50rU&s=j5d5pJJFEcyJY7GSdGav9yUx9tOTMdV2YMTi26h1J7o&e=>
Re: What kind of things would prevent a set of bundles from going Active?
Posted by Christian Schneider <ch...@die-schneider.net>.
For each bundle that can not be resolved diag shows the dependency tree of
the requirement the resolver failed on.
Typically you look at the line at the bottom. This is what is really
missing. In your case it means:
The package org.quartz.impl is missing.
The package org.springframework.xml.xpath with a version [2.0.0,3.0.0) ias
missing.
The strings are in polish notation which make them unambiguous like David
wrote but also hard to read if you are not used to it.
Christian
2017-10-03 1:37 GMT+02:00 KARR, DAVID <dk...@att.com>:
> > -----Original Message-----
> > From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> > Sent: Friday, September 29, 2017 10:49 PM
> > To: user@karaf.apache.org
> > Subject: Re: What kind of things would prevent a set of bundles from
> > going Active?
> >
> > Hi,
> >
> > When a bundle is resolved, it means that the constraints resolution is
> > OK.
> > Basically, Import packages & requirements are satisfied.
> >
> > So, a bundle stays in Installed state if it can go to Resolved due to a
> > unsatisfied resolution constraint (for instance an imported package is
> > not present).
> >
> > When a bundle is in Resolved state, it's possible to start it. Basically
> > it means calling the start method of the activator. If the start method
> > works and didn't throw an exception, then, the bundle becomes active.
> >
> > In the case of blueprint, the activator is managed by blueprint. Grace-
> > Period means that blueprint is looking for a dependency service at
> > startup and it doesn't find it. So, he's waiting for the service.
> >
> > bundle:diag or log gives you detail about the service not present.
>
> Thanks for the reply. This is helping.
>
> Running "bundle:diag" did give me some useful output. Running "log" just
> returned to the prompt.
>
> An excerpt from the "bundle:diag" output is here:
> ------------------
> apis-base (82)
> --------------
> Status: Installed
> Unsatisfied Requirements:
> [82.0] osgi.wiring.package; (&(osgi.wiring.package=org.apache.commons.io
> )(version>=1.4.0)(!(version>=2.0.0)))
> [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz)
> [82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz.impl)
>
> onemap-impl (89)
> ----------------
> Status: Installed
> Unsatisfied Requirements:
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=com.
> att.ecom.base.util)(version>=1.1.0)(!(version>=2.0.0)))
> [89.0] osgi.wiring.package; (osgi.wiring.package=com.att.
> ecom.onemap.api.constants)
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.
> ehcache)(version>=2.5.0)(!(version>=3.0.0)))
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.
> ehcache.config)(version>=2.5.0)(!(version>=3.0.0)))
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.
> ehcache.store)(version>=2.5.0)(!(version>=3.0.0)))
> [89.0] osgi.wiring.package; (osgi.wiring.package=org.springframework.dao)
> [89.0] osgi.wiring.package; (osgi.wiring.package=org.
> springframework.jdbc.core)
> [89.0] osgi.wiring.package; (&(osgi.wiring.package=org.
> springframework.xml.xpath)(version>=2.0.0)(!(version>=3.0.0)))
> ------------------
>
> In the past, I've tried to find a guide for fully interpreting these error
> messages, but I've always ended up just blundering through it. Is there a
> clear guide for how to interpret these somewhere? I could guess that the
> first bundle needs commons-io and quartz, and the second needs ehcache,
> some spring artifacts, and a couple of application-specific artifacts, and
> I can interpret some of those version expressions, but I don't understand
> why it sometimes has the "&()" wrapper (is that always when there's a
> version expression?).
>
> > On 09/29/2017 07:30 PM, KARR, DAVID wrote:
> > > I'm still working with the legacy app using Karaf 3.0.1, which I don't
> > have very good overall documentation for.
> > >
> > > I've been able to execute my "feature:install" command in the karaf
> > console, which appeared to complete successfully, but at that point it's
> > apparently expected that all of my bundles are in an "Active" state.
> > However, for some reason most of them are not. Some are, but some of
> > the application-specific bundles are "Installed", or even "Grace
> > Period".
> > >
> > > I've checked the karaf.log, and there are no obvious red flags.
> > >
> > > When I try to hit my REST service at localhost:8181, it just times
> > out, which is not surprising, as the bundle in question probably is not
> > active.
> > >
> > > I also tried installing the web console. I just did "feature:install
> > webconsole" and then went to "http://localhost:8181/system/console" in
> > my browser. This timed out.
> > >
> > > What should I be looking at to diagnose this?
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__blog.nanthrax.net&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=jl9mLMBBmRS
> > FeUETzUN7l8dHAQbh5CGPlgZd6fqUSJI&e=
> > Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__www.talend.com&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=ZcPGU_vMwhY
> > t2Zoc_2TdHZKrZ1Z-wyM2owPWlY6nFM0&e=
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Computer Scientist
http://www.adobe.com
RE: What kind of things would prevent a set of bundles from going
Active?
Posted by "KARR, DAVID" <dk...@att.com>.
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> Sent: Friday, September 29, 2017 10:49 PM
> To: user@karaf.apache.org
> Subject: Re: What kind of things would prevent a set of bundles from
> going Active?
>
> Hi,
>
> When a bundle is resolved, it means that the constraints resolution is
> OK.
> Basically, Import packages & requirements are satisfied.
>
> So, a bundle stays in Installed state if it can go to Resolved due to a
> unsatisfied resolution constraint (for instance an imported package is
> not present).
>
> When a bundle is in Resolved state, it's possible to start it. Basically
> it means calling the start method of the activator. If the start method
> works and didn't throw an exception, then, the bundle becomes active.
>
> In the case of blueprint, the activator is managed by blueprint. Grace-
> Period means that blueprint is looking for a dependency service at
> startup and it doesn't find it. So, he's waiting for the service.
>
> bundle:diag or log gives you detail about the service not present.
Thanks for the reply. This is helping.
Running "bundle:diag" did give me some useful output. Running "log" just returned to the prompt.
An excerpt from the "bundle:diag" output is here:
------------------
apis-base (82)
--------------
Status: Installed
Unsatisfied Requirements:
[82.0] osgi.wiring.package; (&(osgi.wiring.package=org.apache.commons.io)(version>=1.4.0)(!(version>=2.0.0)))
[82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz)
[82.0] osgi.wiring.package; (osgi.wiring.package=org.quartz.impl)
onemap-impl (89)
----------------
Status: Installed
Unsatisfied Requirements:
[89.0] osgi.wiring.package; (&(osgi.wiring.package=com.att.ecom.base.util)(version>=1.1.0)(!(version>=2.0.0)))
[89.0] osgi.wiring.package; (osgi.wiring.package=com.att.ecom.onemap.api.constants)
[89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.ehcache)(version>=2.5.0)(!(version>=3.0.0)))
[89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.ehcache.config)(version>=2.5.0)(!(version>=3.0.0)))
[89.0] osgi.wiring.package; (&(osgi.wiring.package=net.sf.ehcache.store)(version>=2.5.0)(!(version>=3.0.0)))
[89.0] osgi.wiring.package; (osgi.wiring.package=org.springframework.dao)
[89.0] osgi.wiring.package; (osgi.wiring.package=org.springframework.jdbc.core)
[89.0] osgi.wiring.package; (&(osgi.wiring.package=org.springframework.xml.xpath)(version>=2.0.0)(!(version>=3.0.0)))
------------------
In the past, I've tried to find a guide for fully interpreting these error messages, but I've always ended up just blundering through it. Is there a clear guide for how to interpret these somewhere? I could guess that the first bundle needs commons-io and quartz, and the second needs ehcache, some spring artifacts, and a couple of application-specific artifacts, and I can interpret some of those version expressions, but I don't understand why it sometimes has the "&()" wrapper (is that always when there's a version expression?).
> On 09/29/2017 07:30 PM, KARR, DAVID wrote:
> > I'm still working with the legacy app using Karaf 3.0.1, which I don't
> have very good overall documentation for.
> >
> > I've been able to execute my "feature:install" command in the karaf
> console, which appeared to complete successfully, but at that point it's
> apparently expected that all of my bundles are in an "Active" state.
> However, for some reason most of them are not. Some are, but some of
> the application-specific bundles are "Installed", or even "Grace
> Period".
> >
> > I've checked the karaf.log, and there are no obvious red flags.
> >
> > When I try to hit my REST service at localhost:8181, it just times
> out, which is not surprising, as the bundle in question probably is not
> active.
> >
> > I also tried installing the web console. I just did "feature:install
> webconsole" and then went to "http://localhost:8181/system/console" in
> my browser. This timed out.
> >
> > What should I be looking at to diagnose this?
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__blog.nanthrax.net&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=jl9mLMBBmRS
> FeUETzUN7l8dHAQbh5CGPlgZd6fqUSJI&e=
> Talend - https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.talend.com&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=ZMfiZcSDNceMx7Qo65Vgub5g4k_Jmwo5hPTCY33LQXA&s=ZcPGU_vMwhY
> t2Zoc_2TdHZKrZ1Z-wyM2owPWlY6nFM0&e=
Re: What kind of things would prevent a set of bundles from going
Active?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
When a bundle is resolved, it means that the constraints resolution is OK.
Basically, Import packages & requirements are satisfied.
So, a bundle stays in Installed state if it can go to Resolved due to a
unsatisfied resolution constraint (for instance an imported package is not present).
When a bundle is in Resolved state, it's possible to start it. Basically it
means calling the start method of the activator. If the start method works and
didn't throw an exception, then, the bundle becomes active.
In the case of blueprint, the activator is managed by blueprint. Grace-Period
means that blueprint is looking for a dependency service at startup and it
doesn't find it. So, he's waiting for the service.
bundle:diag or log gives you detail about the service not present.
Regards
JB
On 09/29/2017 07:30 PM, KARR, DAVID wrote:
> I'm still working with the legacy app using Karaf 3.0.1, which I don't have very good overall documentation for.
>
> I've been able to execute my "feature:install" command in the karaf console, which appeared to complete successfully, but at that point it's apparently expected that all of my bundles are in an "Active" state. However, for some reason most of them are not. Some are, but some of the application-specific bundles are "Installed", or even "Grace Period".
>
> I've checked the karaf.log, and there are no obvious red flags.
>
> When I try to hit my REST service at localhost:8181, it just times out, which is not surprising, as the bundle in question probably is not active.
>
> I also tried installing the web console. I just did "feature:install webconsole" and then went to "http://localhost:8181/system/console" in my browser. This timed out.
>
> What should I be looking at to diagnose this?
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com