I posted the following to the Apache Karaf user list last week. What I'm
primarily interested in is the fact that the DataNucleus bundle that is getting
the exception seems to be trying to do something that seems reasonable, i.e.
get it's own BundleContext when it's running, but gets an NPE which seems to
imply that it's executing in the RESOLVED state. The Karaf console shows the
bundle in the ACTIVE state when I check. I should point out that the exception
happens when Karaf starts up and goes through it's full bundle
resolution/activation processing.
I guess I've assumed that bundles wouldn't execute until they're STARTING. My
knowledge of class loaders and what they imply is limited so perhaps it's
obvious why this isn't, or at least doesn't appear to be, the case.
Given that, how would a bundle do what's being attempted by the DN bundle
reliably, get it's own BC and interrogate it, without necessarily doing it
within an activator?
Regards, Scott
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 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();
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
