2008/4/30 Mark Derricutt <[EMAIL PROTECTED]>:

> Oops - my bad.  Yes, simply stopping/starting Bundle A works fine, if I
> update Bundle A however it doesn't.
>
> I can work around things by using reflection to execute the class I'm
> loading from Bundle B, and moving the object I was passing over as a
> parameter to be an exported OSGi service which is then looked up, it's not
> as clean as I'd hoped.
>

if you want to update A (ie. to change it's implementation) but avoid
the class cast issues then I'd suggest moving its public API classes
into a separate bundle (A-interface)

then you can start/stop/update A or B as much as you like...

Mark
>
> On Wed, Apr 30, 2008 at 3:37 PM, Richard S. Hall <[EMAIL PROTECTED]>
> wrote:
>
> > 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]
> >
> >
>
>
> --
> "It is easier to optimize correct code than to correct optimized code." --
> Bill Harlan
>



-- 
Cheers, Stuart

Reply via email to