[news.eclipse.technology.equinox] Re: Separating concerns...

["Pascal Rapicault" <pascal_rapicault@xxxxxxxxxx>]

This page has been moved to

http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/dynamic
Plugins/classloadersAndInstances.html

    PaScaL

"Mel Martinez" <melm@xxxxxxxxxx> wrote in message
news:b629ou$at0$1@xxxxxxxxxxxxxxxx
> After I wrote the comments below, I saw that Olivier has posted similar
> comments in greater detail on this topic at the web site:
>
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/dynamic
Plugins/deactivatingPlugins.html
>
> For those following this thread.
>
> - mel
>
> Mel Martinez wrote:
> > Olivier Gruber wrote:
> >
> >>
> >> I would like us to separate concerns a bit... it seems that we
> >> are too much focus on plugins... what I mean by that is that
> >> we want event notifications about plugins lifecycles... mostly
> >> because we load and unload plugins... but actually, plugin
> >> developers know nothing about plugins... in most cases...
> >>
> >> From most plugin developers' perspective (pun intended :-),
> >> plugins do not really exist... they deal with extensions and
> >> extension points through the registry... or directly with
> >> Java classes (like SWT or Xerces)... they don't know
> >> about plugins most of the time, and I believe it should
> >> remain that way.
> >>
> >
> > This is a good point.  I thought I made that separation by defining
> > 'RegistryListener' independent of plugins.  Thus any class could become
> > a RegistryListener simply by extending the interface.  In fact I was
> > thinking that it might be desirable behavior that, when resolving
> > extension points and extensions of, that the two parties be implicitly
> > checked for instanceof RegistryListener and automatically registered for
> > events on that registry path.
> >
> > That shouldn't disallow others for registering to listen, of course.
> >
> >> So, along those lines, as an extension point provider,
> >> I am interested to know if new extensions are available
> >> for my extension point or if some are disappearing.
> >> This is enough to support plugin loading/unloading as
> >> well as dynamic registration of extensions and extension points.
> >
> >
> > Well, there is another area that needs to looked at.  Consider that even
> > if you don't use an extension point, you might be using a reference to a
> > class exposed through <runtime><export> on the one side and then
> > <requires> on other.  The code that is using an exported class needs to
> > somehow be told that it is going to be unloaded and that it should
> > release it's reference and perhaps wait on another event to reaquire.
> >
> > So the model here might be that in order to <require> a dynamic plugin
> > the dependent code must in turn provide a designated listener class that
> > listens for the appropriate load/unload events.
> >
> > For backward compatibility, if no listener is designated, we could treat
> > this as a 'lock' that prevents unloading.
> >
> > Thoughts?
> >
> > Mel
> >
>