If I am understanding correctly, something seems fishy here.
Simply restarting A should not cause a new class loader to be recreated.
I believe you should only see a new class loader if you are updating A,
for example.
Is your description below accurate or are you updating the bundle?
-> richard
Mark Derricutt wrote:
Hey all,
Running into a small problem with reloading bundles which I'm sure's been
solved by something simple I'm not quite seeing.
The scenario is that I have two bundles A and B - A provides an interface
MountProvider, and B has a class that implements it.
When bundle A starts it looks for all bundles that provide an instance of
MountProvider, bundle A also listens to other bundles starting up which
provide the instance.
Things all work fine on startup. Bundle A starts, Bundle B starts. Bundle
A detects the MountProvider instance using the following code:
String classname = (String)
bundle.getHeaders().get(SMX3_RESTLET_PROVIDER);
Class activatorClass = bundle.loadClass(classname);
if (MountProvider.class.isAssignableFrom(activatorClass)) {
MountProvider mountRequestEvent = (MountProvider)
restActivatorClass.newInstance();
mountRequestEvent.mountResources(mountManager);
}
If I restart bundle B, the above code reruns fine as expected, finding the
updated MountProvider instance.
However, if I restart bundle A - when bundle B is processed again, the check
fails and processing isn't performed. My assumption here is that the
MountProvider class from bundle B is an instance of "the original bundle A's
MountProvider", and not the "current bundle A's MountProvider" class so the
call to isAssignableFrom fails.
Whats the proper/OSGi way to check for this that respects the change in
class loaders? Should I do something like:
Class activatorClass = bundle.loadClass(classname);
Class mountProviderClass =
bundle.loadClass(MountProvider.class.getName());
if (mountProviderClass.isAssignableFrom(activatorClass)) {
instead? And using an indirect reference to my MountProvider interface, as
seen by the bundle?
Thanks in advance,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
