[news.eclipse.technology.equinox] Re: Plugins - singletons or not?

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

"Mel Martinez" <melm@xxxxxxxxxx> wrote in message
news:b69nv7$ie2$1@xxxxxxxxxxxxxxxx
> Jeff McAffer wrote:
> > "pkriens" <Peter.Kriens@xxxxxxxx> wrote in message
> > news:3E8800D9.4050203@xxxxxxxxxxx
> >
> >>I am a bit confused. If we have dynamic plugins, we have the problem
> >>that they can go away. The patterns described to handle plugin creation
> >>are therefore not applicable anymore, isnt it?
> >>
> >>If plugins come and go, we need a service registry approach where the
> >>plugins are registered and unregistered. Access to static fields and
> >>getInstance()/getDefault() methods seem to be not sufficient?
> >
> >
> > Right.  In actual fact, the plugin registry already provides this
function.
> > If plugin A is deactivated and reactivated you can safely reference the
new
> > one via the registry.  Same for uninstall, install, update, ...
> >
> > For my money getDefault/getInstance should be
> >     return Platform.getPlugin("my id");
> >
>
> I couldn't agree more with that last statement except that it doesn't go
> far enough to address Peter's concern.  To remove need for access to the
> class one shouldn't even be using a static getInstance() method.
> Instead, they should always be going directly to the
> Platform.getPlugin("my id") modus, and probably Plugin implementation's
> should not even be providing a getDefault()/getInstance() accessor.

Yes.  I am a little unclear about the need to remove references to classes.
While this may be a good thing in general, clearly plugins are going to
reference classes from other plugins.  Clearing up this one case does not
solve the problem.  So what am I missing here?  Are you proposing that all
cross plugin class references use some sort of service registry mechanism?
As a point of interest, how does that work for subclassing, implementing,
casting etc style relationships?

> Since this is not a strongly enforced convention, we may have problems
> going forward with unnecessary coupling arising from this.  I guess this
> dependency is flagged broadly under the <requires> element.

The <requires> elements tell you that if A requires B and B is shutdown,
replaced, ... A needs to do something.  The straightforward approach is to
shutdown and restart all the dependents (or the whole platform) in these
situations.

In OSGi (at least some older versions) the old bundle (B) would stay around
until the framework was restarted or all dependent bundles were shutdown and
restarted.  Is this still the state of the art in OSGi?

Jeff