You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by "Leschke, Scott" <SL...@medline.com> on 2014/07/23 21:58:36 UTC
Null BundleContext in class
I'm seeing some behavior using Karaf/Felix that I find odd.
I have a Blueprint service that fails to instantiate when the Blueprint container tries to create it. The service is itself trying to create an an object (JDO PersistenceManagerFactory) using the JDO API and DataNucleus JDO implementation
The root cause of the failure appears to be that one of the DN bundles is attempting to get its own BundleContext but gets an NPE instead. The only way that this could occur to my knowledge is if the bundle isn't in an appropriate state (STARTING at a minimum). I'm not sure why the OSGi framework wouldn't have already started the bundle in question (org.datanucleus) since the invoking bundle (org.datanucleus.api.jdo) has explicit dependencies declared on the packages it exports, specifically package org.datanucleus.plugin.
Is this framework behavior reasonable? Additional detail is below. Any thoughts greatly appreciated.
Caused by: java.lang.NullPointerException
at org.datanucleus.plugin.OSGiPluginRegistry.registerExtensions(OSGiPluginRegistry.java:104)
at org.datanucleus.plugin.OSGiPluginRegistry.registerExtensionPoints(OSGiPluginRegistry.java:89)
at org.datanucleus.plugin.PluginManager.<init>(PluginManager.java:63)
at org.datanucleus.plugin.PluginManager.createPluginManager(PluginManager.java:430)
at org.datanucleus.AbstractNucleusContext.<init>(AbstractNucleusContext.java:85)
at org.datanucleus.PersistenceNucleusContextImpl.<init>(PersistenceNucleusContextImpl.java:164)
at org.datanucleus.PersistenceNucleusContextImpl.<init>(PersistenceNucleusContextImpl.java:153)
at org.datanucleus.api.jdo.JDOPersistenceManagerFactory.<init>(JDOPersistenceManagerFactory.java:426)
Lines 100-104 of class org.datanucleus.plugin.OSGiPluginRegistry are shown below. Clearly 'ctx" must be null.
BundleContext ctx = FrameworkUtil.getBundle(this.getClass()).getBundleContext();
// parse the plugin files
DocumentBuilder docBuilder = OSGiBundleParser.getDocumentBuilder();
org.osgi.framework.Bundle[] osgiBundles = ctx.getBundles();
RE: Null BundleContext in class
Posted by "Leschke, Scott" <SL...@medline.com>.
They're just dropped in the deploy folder along with the bundle that causes it's execution during Blueprint initialization. Nope, no activation policy.
Everything goes swimmingly until the one class tries to get it's BundleContext using FrameworkUtil. I think I'll try to run it in Eclipse/Equinox again when I get a chance just to see what happens. It's been a while since I've tried it like that.
Scott
-----Original Message-----
From: David Jencks [mailto:david_jencks@yahoo.com]
Sent: Thursday, July 24, 2014 12:02 PM
To: user@karaf.apache.org
Subject: Re: Null BundleContext in class
I recall having this problem years ago but don't remember the cause. I don't think defining a bundle activator will help. How are you installing these bundles? Do any of them have an activation policy in the manifest? I would think that installing them all via a karat feature would result in them all getting started, but I haven't used karat in years and am not 100% sure.
david jencks
On Jul 24, 2014, at 8:45 AM, "Leschke, Scott" <SL...@medline.com> wrote:
> Yes, they are. I've used DataNucleus without problems in the past in Eclipse/Equinox . I've also looked at the MANIFEST.MF files to check the IMPORT/EXPORT-PACKAGE clauses.
>
> I just think that the class in question is loaded and executing in the RESOLVED state, which is possible/valid I guess. I guess I always assumed that the first class to load in a bundle would be the activator if it's specified.
>
> Assuming that's the case, it would seem that the only way for a class to guarantee that it can get access to its BundleContext is to declare an activator and do it after the activator runs.
>
> -----Original Message-----
> From: jkraushaar [mailto:jochen.kraushaar@doubleslash.de]
> Sent: Thursday, July 24, 2014 2:17 AM
> To: user@karaf.apache.org
> Subject: RE: Null BundleContext in class
>
> Hi Scott,
>
> are you sure that both bundles are valid OSGi bundles? I had similar problems in the past when I've installed JAR without OSGi meta informations.
> The framework told me that it has the state ACTIVE, but it was not a bundle at all.
>
> Regards
> Jochen
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Null-BundleContext-in-class-tp403441
> 3p4034421.html Sent from the Karaf - User mailing list archive at
> Nabble.com.
Re: Null BundleContext in class
Posted by David Jencks <da...@yahoo.com>.
I recall having this problem years ago but don't remember the cause. I don't think defining a bundle activator will help. How are you installing these bundles? Do any of them have an activation policy in the manifest? I would think that installing them all via a karat feature would result in them all getting started, but I haven't used karat in years and am not 100% sure.
david jencks
On Jul 24, 2014, at 8:45 AM, "Leschke, Scott" <SL...@medline.com> wrote:
> Yes, they are. I've used DataNucleus without problems in the past in Eclipse/Equinox . I've also looked at the MANIFEST.MF files to check the IMPORT/EXPORT-PACKAGE clauses.
>
> I just think that the class in question is loaded and executing in the RESOLVED state, which is possible/valid I guess. I guess I always assumed that the first class to load in a bundle would be the activator if it's specified.
>
> Assuming that's the case, it would seem that the only way for a class to guarantee that it can get access to its BundleContext is to declare an activator and do it after the activator runs.
>
> -----Original Message-----
> From: jkraushaar [mailto:jochen.kraushaar@doubleslash.de]
> Sent: Thursday, July 24, 2014 2:17 AM
> To: user@karaf.apache.org
> Subject: RE: Null BundleContext in class
>
> Hi Scott,
>
> are you sure that both bundles are valid OSGi bundles? I had similar problems in the past when I've installed JAR without OSGi meta informations.
> The framework told me that it has the state ACTIVE, but it was not a bundle at all.
>
> Regards
> Jochen
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Null-BundleContext-in-class-tp4034413p4034421.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
RE: Null BundleContext in class
Posted by "Leschke, Scott" <SL...@medline.com>.
Yes, they are. I've used DataNucleus without problems in the past in Eclipse/Equinox . I've also looked at the MANIFEST.MF files to check the IMPORT/EXPORT-PACKAGE clauses.
I just think that the class in question is loaded and executing in the RESOLVED state, which is possible/valid I guess. I guess I always assumed that the first class to load in a bundle would be the activator if it's specified.
Assuming that's the case, it would seem that the only way for a class to guarantee that it can get access to its BundleContext is to declare an activator and do it after the activator runs.
-----Original Message-----
From: jkraushaar [mailto:jochen.kraushaar@doubleslash.de]
Sent: Thursday, July 24, 2014 2:17 AM
To: user@karaf.apache.org
Subject: RE: Null BundleContext in class
Hi Scott,
are you sure that both bundles are valid OSGi bundles? I had similar problems in the past when I've installed JAR without OSGi meta informations.
The framework told me that it has the state ACTIVE, but it was not a bundle at all.
Regards
Jochen
--
View this message in context: http://karaf.922171.n3.nabble.com/Null-BundleContext-in-class-tp4034413p4034421.html
Sent from the Karaf - User mailing list archive at Nabble.com.
RE: Null BundleContext in class
Posted by jkraushaar <jo...@doubleslash.de>.
Hi Scott,
are you sure that both bundles are valid OSGi bundles? I had similar
problems in the past when I've installed JAR without OSGi meta informations.
The framework told me that it has the state ACTIVE, but it was not a bundle
at all.
Regards
Jochen
--
View this message in context: http://karaf.922171.n3.nabble.com/Null-BundleContext-in-class-tp4034413p4034421.html
Sent from the Karaf - User mailing list archive at Nabble.com.
RE: Null BundleContext in class
Posted by "Leschke, Scott" <SL...@medline.com>.
I haven't done anything to get it to start. I didn't think the classes would be available until "Starting" state given that the context isn't available until then. When I look in the console, after occurrence of the NPE, its state is "Active".
So I guess a class in a bundle can't depend on getting access to the BundleContext of the bundle in which it resides?
From: David Jencks [mailto:david_jencks@yahoo.com]
Sent: Wednesday, July 23, 2014 3:57 PM
To: user@karaf.apache.org
Subject: Re: Null BundleContext in class
It sounds like the bundle is resolved but not started. What have you done to try to get the bundle to start? All the classes from a resolved bundle are available without it starting.
david jencks
On Jul 23, 2014, at 12:58 PM, "Leschke, Scott" <SL...@medline.com>> wrote:
I'm seeing some behavior using Karaf/Felix that I find odd.
I have a Blueprint service that fails to instantiate when the Blueprint container tries to create it. The service is itself trying to create an an object (JDO PersistenceManagerFactory) using the JDO API and DataNucleus JDO implementation
The root cause of the failure appears to be that one of the DN bundles is attempting to get its own BundleContext but gets an NPE instead. The only way that this could occur to my knowledge is if the bundle isn't in an appropriate state (STARTING at a minimum). I'm not sure why the OSGi framework wouldn't have already started the bundle in question (org.datanucleus) since the invoking bundle (org.datanucleus.api.jdo) has explicit dependencies declared on the packages it exports, specifically package org.datanucleus.plugin.
Is this framework behavior reasonable? Additional detail is below. Any thoughts greatly appreciated.
Caused by: java.lang.NullPointerException
at org.datanucleus.plugin.OSGiPluginRegistry.registerExtensions(OSGiPluginRegistry.java:104)
at org.datanucleus.plugin.OSGiPluginRegistry.registerExtensionPoints(OSGiPluginRegistry.java:89)
at org.datanucleus.plugin.PluginManager.<init>(PluginManager.java:63)
at org.datanucleus.plugin.PluginManager.createPluginManager(PluginManager.java:430)
at org.datanucleus.AbstractNucleusContext.<init>(AbstractNucleusContext.java:85)
at org.datanucleus.PersistenceNucleusContextImpl.<init>(PersistenceNucleusContextImpl.java:164)
at org.datanucleus.PersistenceNucleusContextImpl.<init>(PersistenceNucleusContextImpl.java:153)
at org.datanucleus.api.jdo.JDOPersistenceManagerFactory.<init>(JDOPersistenceManagerFactory.java:426)
Lines 100-104 of class org.datanucleus.plugin.OSGiPluginRegistry are shown below. Clearly 'ctx" must be null.
BundleContext ctx = FrameworkUtil.getBundle(this.getClass()).getBundleContext();
// parse the plugin files
DocumentBuilder docBuilder = OSGiBundleParser.getDocumentBuilder();
org.osgi.framework.Bundle[] osgiBundles = ctx.getBundles();
Re: Null BundleContext in class
Posted by David Jencks <da...@yahoo.com>.
It sounds like the bundle is resolved but not started. What have you done to try to get the bundle to start? All the classes from a resolved bundle are available without it starting.
david jencks
On Jul 23, 2014, at 12:58 PM, "Leschke, Scott" <SL...@medline.com> wrote:
> I’m seeing some behavior using Karaf/Felix that I find odd.
>
> I have a Blueprint service that fails to instantiate when the Blueprint container tries to create it. The service is itself trying to create an an object (JDO PersistenceManagerFactory) using the JDO API and DataNucleus JDO implementation
>
> The root cause of the failure appears to be that one of the DN bundles is attempting to get its own BundleContext but gets an NPE instead. The only way that this could occur to my knowledge is if the bundle isn’t in an appropriate state (STARTING at a minimum). I’m not sure why the OSGi framework wouldn’t have already started the bundle in question (org.datanucleus) since the invoking bundle (org.datanucleus.api.jdo) has explicit dependencies declared on the packages it exports, specifically package org.datanucleus.plugin.
>
> Is this framework behavior reasonable? Additional detail is below. Any thoughts greatly appreciated.
>
> Caused by: java.lang.NullPointerException
> at org.datanucleus.plugin.OSGiPluginRegistry.registerExtensions(OSGiPluginRegistry.java:104)
> at org.datanucleus.plugin.OSGiPluginRegistry.registerExtensionPoints(OSGiPluginRegistry.java:89)
> at org.datanucleus.plugin.PluginManager.<init>(PluginManager.java:63)
> at org.datanucleus.plugin.PluginManager.createPluginManager(PluginManager.java:430)
> at org.datanucleus.AbstractNucleusContext.<init>(AbstractNucleusContext.java:85)
> at org.datanucleus.PersistenceNucleusContextImpl.<init>(PersistenceNucleusContextImpl.java:164)
> at org.datanucleus.PersistenceNucleusContextImpl.<init>(PersistenceNucleusContextImpl.java:153)
> at org.datanucleus.api.jdo.JDOPersistenceManagerFactory.<init>(JDOPersistenceManagerFactory.java:426)
>
> Lines 100-104 of class org.datanucleus.plugin.OSGiPluginRegistry are shown below. Clearly ‘ctx” must be null.
>
> BundleContext ctx = FrameworkUtil.getBundle(this.getClass()).getBundleContext();
>
> // parse the plugin files
> DocumentBuilder docBuilder = OSGiBundleParser.getDocumentBuilder();
> org.osgi.framework.Bundle[] osgiBundles = ctx.getBundles();
>