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 <dk0...@att.com> wrote: > >> -----Original Message----- >> From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net >> <mailto:j...@nanthrax.net>] >> Sent: Friday, September 29, 2017 10:49 PM >> To: user@karaf.apache.org <mailto: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 > <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é >> jbono...@apache.org <mailto:jbono...@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=
