Re: NPE and bundleContext.getBundle(0) with feature jar from 4.1.3-SNAPSHOT

[J. Brebec]

I am using surefire 2.16, but I can't share this pom

On 2017-10-10 11:22, Jean-Baptiste Onofré  wrote: 
> Which surefire version ? Is it possible to share the itest pom XML ?
> 
> Thanks
> Regards
> JB
> 
> On 10/10/2017 11:10 AM, J. Brebec wrote:
> > I am unable to reproduce it on my workstation - in fact, it works better 
> > with Karaf 4.1.3 than with 4.1.2
> > 
> > However, on the production server, I run 200 tests, and on each run, 5 or 6 
> > tests fails because of this NPE. The test are run with PaxExam (4.11).
> > 
> > On 2017-10-10 11:05, Jean-Baptiste Onofré  wrote:
> >> Hi Jérémie,
> >>
> >> does it happen in Pax Exam ? Or generally speaking ?
> >>
> >> Do you have a scenario to reproduce that ?
> >>
> >> Thanks !
> >> Regards
> >> JB
> >>
> >> On 10/10/2017 11:03 AM, J. Brebec wrote:
> >>> Hello,
> >>>
> >>> I am using Karaf 4.1.2 with the bundle features from Karaf 4.1.3-SNAPSHOT.
> >>>
> >>> Randomly, my integration tests fails on internals classes from Aries, 
> >>> Felix etc when this librairies tries to get the system bundle : 
> >>> getBundle(0) return null
> >>>
> >>> I don't see when this bundle can be null, and I suspect that the region 
> >>> hook hides the system bundle.. If I use the jar from Karaf 4.1.2, then my 
> >>> integrations tests pass.
> >>>
> >>> Is this a known issue with Karaf 4.1.3 ?
> >>>
> >>> Regards
> >>> Jérémie
> >>>
> >>
> >> -- 
> >> Jean-Baptiste Onofré
> >> jbono...@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

Re: NPE and bundleContext.getBundle(0) with feature jar from 4.1.3-SNAPSHOT

[Jean-Baptiste Onofré]

Which surefire version ? Is it possible to share the itest pom XML ?

Thanks
Regards
JB

On 10/10/2017 11:10 AM, J. Brebec wrote:

I am unable to reproduce it on my workstation - in fact, it works better with 
Karaf 4.1.3 than with 4.1.2

However, on the production server, I run 200 tests, and on each run, 5 or 6 
tests fails because of this NPE. The test are run with PaxExam (4.11).

On 2017-10-10 11:05, Jean-Baptiste Onofré  wrote:

Hi Jérémie,

does it happen in Pax Exam ? Or generally speaking ?

Do you have a scenario to reproduce that ?

Thanks !
Regards
JB

On 10/10/2017 11:03 AM, J. Brebec wrote:

Hello,

I am using Karaf 4.1.2 with the bundle features from Karaf 4.1.3-SNAPSHOT.

Randomly, my integration tests fails on internals classes from Aries, Felix etc 
when this librairies tries to get the system bundle : getBundle(0) return null

I don't see when this bundle can be null, and I suspect that the region hook 
hides the system bundle.. If I use the jar from Karaf 4.1.2, then my 
integrations tests pass.

Is this a known issue with Karaf 4.1.3 ?

Regards
Jérémie



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: NPE and bundleContext.getBundle(0) with feature jar from 4.1.3-SNAPSHOT

[J. Brebec]

I am unable to reproduce it on my workstation - in fact, it works better with 
Karaf 4.1.3 than with 4.1.2

However, on the production server, I run 200 tests, and on each run, 5 or 6 
tests fails because of this NPE. The test are run with PaxExam (4.11).

On 2017-10-10 11:05, Jean-Baptiste Onofré  wrote: 
> Hi Jérémie,
> 
> does it happen in Pax Exam ? Or generally speaking ?
> 
> Do you have a scenario to reproduce that ?
> 
> Thanks !
> Regards
> JB
> 
> On 10/10/2017 11:03 AM, J. Brebec wrote:
> > Hello,
> > 
> > I am using Karaf 4.1.2 with the bundle features from Karaf 4.1.3-SNAPSHOT.
> > 
> > Randomly, my integration tests fails on internals classes from Aries, Felix 
> > etc when this librairies tries to get the system bundle : getBundle(0) 
> > return null
> > 
> > I don't see when this bundle can be null, and I suspect that the region 
> > hook hides the system bundle.. If I use the jar from Karaf 4.1.2, then my 
> > integrations tests pass.
> > 
> > Is this a known issue with Karaf 4.1.3 ?
> > 
> > Regards
> > Jérémie
> > 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

Re: NPE and bundleContext.getBundle(0) with feature jar from 4.1.3-SNAPSHOT

[Jean-Baptiste Onofré]

Hi Jérémie,

does it happen in Pax Exam ? Or generally speaking ?

Do you have a scenario to reproduce that ?

Thanks !
Regards
JB

On 10/10/2017 11:03 AM, J. Brebec wrote:

Hello,

I am using Karaf 4.1.2 with the bundle features from Karaf 4.1.3-SNAPSHOT.

Randomly, my integration tests fails on internals classes from Aries, Felix etc 
when this librairies tries to get the system bundle : getBundle(0) return null

I don't see when this bundle can be null, and I suspect that the region hook 
hides the system bundle.. If I use the jar from Karaf 4.1.2, then my 
integrations tests pass.

Is this a known issue with Karaf 4.1.3 ?

Regards
Jérémie



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

NPE and bundleContext.getBundle(0) with feature jar from 4.1.3-SNAPSHOT

[J. Brebec]

Hello,

I am using Karaf 4.1.2 with the bundle features from Karaf 4.1.3-SNAPSHOT.

Randomly, my integration tests fails on internals classes from Aries, Felix etc 
when this librairies tries to get the system bundle : getBundle(0) return null

I don't see when this bundle can be null, and I suspect that the region hook 
hides the system bundle.. If I use the jar from Karaf 4.1.2, then my 
integrations tests pass.

Is this a known issue with Karaf 4.1.3 ?

Regards
Jérémie

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

[Guillaume Nodet]

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 :

> > -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:j...@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:* cschneider...@gmail.com [mailto:cschneider...@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  > > >:
> > > >
> > > >  > -Original Message-
> > > >  > From: Jean-Baptiste Onofré [mailto:j...@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.

Re: Strange resolution problem

[Guillaume Nodet]

Given it happens at runtime, then it means the import is already in your
net.leangen.expedition.platform.ddd.diag bundle, so it's just the
consequence of a problem happening at build time.  And this means, either a
class import the package, or there is an explicit instruction to import it
either in the bundle plugin config or in a bnd file.  Last possibility is
that the bundle being built embeds code from a different jar, and that code
has a class which import the package.
As for blacklisting, you can urls in the etc/blacklisted.properties file,
but it seems the problem comes from your own net.leangen.expedition.
platform.ddd.diag bundle...

2017-10-10 0:03 GMT+02:00 David Leangen :

>
>
> > On Oct 9, 2017, at 4:23 PM, Achim Nierbeck 
> wrote:
>
> > On Oct 9, 2017, at 4:28 PM, Guillaume Nodet  wrote:
>
> Thanks for the suggestions. You are no doubt right, so I quadruple checked
> my code, and bumped all versions. Ran the build locally, and confirmed that
> the old package is not being pulled in… but it still gets pulled in during
> resolution in Karaf.
>
> Two questions:
>
> 1. Is there a mechanism to trace back the results of the resolution so I
> can try to pinpoint where the bad package is being pulled in?
>
> 2. Is it possible to blacklist in Karaf, so I can avoid a particular
> version of a bundle or package? (I did not see anything in the docs.)
>
>
> Thanks!
> =David
>
>
>


-- 

Guillaume Nodet