Yes, that makes sense to me. So, would there be a generally recommended approach to do the sort of thing that the DataNucleus plugin is trying to do?
Also, I’m kind of curious if there is a particular reason that a BundleContext isn’t/can’t be available until a bundle is in the STARTING state? Is there a particular capability provided by the context that mandates that its creation be deferred until STARTING? Might be too detailed a question for this forum. I guess I could go read the spec… Scott From: [email protected] [mailto:[email protected]] On Behalf Of BJ Hargrave Sent: Thursday, July 31, 2014 5:41 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] Bundle attempting to interrogate BundleContext when starting up Package dependencies between bundles do not cause the bundles to be started. Starting/Stopping a bundle is independent of the RESOLVED state (package dependencies satisfied). Classes need to be able to be loaded from a bundle before it might be started. So you need to make sure the subject bundle is actually started. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance<http://www.osgi.org/> [email protected]<mailto:[email protected]> office: +1 386 848 1781 mobile: +1 386 848 3788 From: "Leschke, Scott" <[email protected]<mailto:[email protected]>> To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: 2014/07/31 18:27 Subject: [osgi-dev] Bundle attempting to interrogate BundleContext when starting up Sent by: [email protected]<mailto:[email protected]> ________________________________ 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]<mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
