On 1 August 2014 at 15:05:35, Leschke, Scott ([email protected]) wrote:
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?
The answer was in your original question… DN should simply use a Bundle
Activator! This can always be done without breaking compatibility for non-OSGi
users, because outside of OSGi the Bundle-Activator header is simply ignored.
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…
The BC represents the bundle’s connection to OSGi, therefore bundles can only
interact with OSGi if they are actually activated. The purpose is to stop
“inactive” bundles from accidentally doing things they shouldn’t be able to do.
Neil
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
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: "Leschke, Scott" <[email protected]>
To: "[email protected]" <[email protected]>
Date: 2014/07/31 18:27
Subject: [osgi-dev] Bundle attempting to interrogate BundleContext when
starting up
Sent by: [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]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
