What kind of things would prevent a set of bundles from going Active?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

What kind of things would prevent a set of bundles from going Active?

KARR, DAVID
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?
Reply | Threaded
Open this post in threaded view
|

Re: What kind of things would prevent a set of bundles from going Active?

jbonofre
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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

RE: What kind of things would prevent a set of bundles from going Active?

KARR, DAVID
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:[hidden email]]
> Sent: Friday, September 29, 2017 10:49 PM
> To: [hidden email]
> 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é
> [hidden email]
> 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=
Reply | Threaded
Open this post in threaded view
|

Re: What kind of things would prevent a set of bundles from going Active?

David Jencks-2
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 <[hidden email]> wrote:

-----Original Message-----
From: Jean-Baptiste Onofré [[hidden email]]
Sent: Friday, September 29, 2017 10:49 PM
To: [hidden email]
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é
[hidden email]
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=

Reply | Threaded
Open this post in threaded view
|

Re: What kind of things would prevent a set of bundles from going Active?

cschneider
In reply to this post by KARR, DAVID
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 <[hidden email]>:
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:[hidden email]]
> Sent: Friday, September 29, 2017 10:49 PM
> To: [hidden email]
> 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é
> [hidden email]
> 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

Computer Scientist

Reply | Threaded
Open this post in threaded view
|

RE: What kind of things would prevent a set of bundles from going Active?

KARR, DAVID

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: [hidden email] [mailto:[hidden email]] On Behalf Of Christian Schneider
Sent: Tuesday, October 03, 2017 10:15 PM
To: [hidden email]
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 <[hidden email]>:

> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:[hidden email]]
> Sent: Friday, September 29, 2017 10:49 PM
> To: [hidden email]
> 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é
> [hidden email]
> 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

Computer Scientist

 

Reply | Threaded
Open this post in threaded view
|

Re: What kind of things would prevent a set of bundles from going Active?

jbonofre
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:* [hidden email] [mailto:[hidden email]] *On Behalf Of
> *Christian Schneider
> *Sent:* Tuesday, October 03, 2017 10:15 PM
> *To:* [hidden email]
> *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 <[hidden email] <mailto:[hidden email]>>:
>
>      > -----Original Message-----
>      > From: Jean-Baptiste Onofré [mailto:[hidden email] <mailto:[hidden email]>]
>      > Sent: Friday, September 29, 2017 10:49 PM
>      > To: [hidden email] <mailto:[hidden email]>
>      > 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é
>      > [hidden email] <mailto:[hidden email]>
>      > 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

RE: What kind of things would prevent a set of bundles from going Active?

KARR, DAVID
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:[hidden email]]
> Sent: Wednesday, October 04, 2017 9:58 PM
> To: [hidden email]
> 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:* [hidden email] [mailto:[hidden email]] *On
> > Behalf Of *Christian Schneider
> > *Sent:* Tuesday, October 03, 2017 10:15 PM
> > *To:* [hidden email]
> > *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 <[hidden email]
> <mailto:[hidden email]>>:
> >
> >      > -----Original Message-----
> >      > From: Jean-Baptiste Onofré [mailto:[hidden email]
> <mailto:[hidden email]>]
> >      > Sent: Friday, September 29, 2017 10:49 PM
> >      > To: [hidden email] <mailto:[hidden email]>
> >      > 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é
> >      > [hidden email] <mailto:[hidden email]>
> >      > 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é
> [hidden email]
> 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=
Reply | Threaded
Open this post in threaded view
|

RE: What kind of things would prevent a set of bundles from going Active?

KARR, DAVID
> -----Original Message-----
> From: KARR, DAVID
> Sent: Thursday, October 05, 2017 2:14 PM
> To: [hidden email]
> Subject: RE: What kind of things would prevent a set of bundles from
> going Active?
>
> > -----Original Message-----
> > From: Jean-Baptiste Onofré [mailto:[hidden email]]
> > Sent: Wednesday, October 04, 2017 9:58 PM
> > To: [hidden email]
> > 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:* [hidden email] [mailto:[hidden email]] *On
> > > Behalf Of *Christian Schneider
> > > *Sent:* Tuesday, October 03, 2017 10:15 PM
> > > *To:* [hidden email]
> > > *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 <[hidden email]
> > <mailto:[hidden email]>>:
> > >
> > >      > -----Original Message-----
> > >      > From: Jean-Baptiste Onofré [mailto:[hidden email]
> > <mailto:[hidden email]>]
> > >      > Sent: Friday, September 29, 2017 10:49 PM
> > >      > To: [hidden email] <mailto:[hidden email]>
> > >      > 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é
> > >      > [hidden email] <mailto:[hidden email]>
> > >      > 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é
> > [hidden email]
> > 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=
Reply | Threaded
Open this post in threaded view
|

Re: What kind of things would prevent a set of bundles from going Active?

Guillaume Nodet-2

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 <[hidden email]>:
> -----Original Message-----
> From: KARR, DAVID
> Sent: Thursday, October 05, 2017 2:14 PM
> To: [hidden email]
> Subject: RE: What kind of things would prevent a set of bundles from
> going Active?
>
> > -----Original Message-----
> > From: Jean-Baptiste Onofré [mailto:[hidden email]]
> > Sent: Wednesday, October 04, 2017 9:58 PM
> > To: [hidden email]
> > 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:* [hidden email] [mailto:[hidden email]] *On
> > > Behalf Of *Christian Schneider
> > > *Sent:* Tuesday, October 03, 2017 10:15 PM
> > > *To:* [hidden email]
> > > *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 <[hidden email]
> > <mailto:[hidden email]>>:
> > >
> > >      > -----Original Message-----
> > >      > From: Jean-Baptiste Onofré [mailto:[hidden email]
> > <mailto:[hidden email]>]
> > >      > Sent: Friday, September 29, 2017 10:49 PM
> > >      > To: [hidden email] <mailto:[hidden email]>
> > >      > 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é
> > >      > [hidden email] <mailto:[hidden email]>
> > >      > 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é
> > [hidden email]
> > 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