[news.eclipse.technology.equinox] Re: New states for plugins

["Kevin" <kduffey@xxxxxxxxxxxxx>]

Questions on disabled plugins. First, what disables them? Is there a thread
that somehow monitors when a plugin is active or not? It seems pretty
impossible to figure out when a plugin is active unless every method in the
plugin updates some registry state of its activity? Since that can't be
enforced, it seems useless to even attempt. Second, when a plugin is
disabled, how do plugins that have references to it react? Are they notified
when a plugin they depend on or a service they have acquired at runtime is
no longer available? Do they programmtically have to handle this in such a
way that if plugin A depends on B, C, D, E, F, and G, and all the plugins it
depends on become unavailable, that there is a bunch of if( pluginB is
available) { do this } else { can't use it so do this } type of code?

Before anyone answers, I am going to assume that the plugin registry always
stays intact for all "loaded" plugins, meaning that a plugin's state could
be set there and other plugins dependent upon it could always check a
plugins state/availability through the registry. By this I mean, if I have
plugin A depend on B and at some point get's a ref to B, then makes some
calls to B methods. Then at some point B becomes "disabled" for a period of
time but A's code is still running, does A's code always have to be written
to check the state of B before it makes any calls on it? Or is there some
disablement going on in A as well, such that a method that uses B's code
won't get called any longer because B is not available?

Just trying to understand how this works.


"Pascal Rapicault" <pascal_rapicault@xxxxxxxxxx> wrote in message
news:b69s7b$mbn$1@xxxxxxxxxxxxxxxx
> In a different thread (classes for dynamix plugin events), Olivier was
> surprised by some new state:
>   disabled and primed.
>
> Disabled has been the named that has always been used (since the first
> version of the site) to indicate
> a plugin whose functions are no longer available (see:
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/dynamic
> Plugins/glossary.html and
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/dynamic
> Plugins/registryLifeCycle.html)
>
> The primed state of a plugin (defined in
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/dynamic
> Plugins/registryLifeCycle.html) is a state where the plugin is not
> "activated" but where some of its functions (not requiring the full power
of
> the plugin) can be made available. This is especially usefull for
decorators
> or filters (for example the binary project filter requires the all pde
> plugin (and required plugins) to be activated just to NOT display
> something...).
>
> Olivier:
> >While I am on the subject, I also don't quite understand
> >the primed state... Does it mean that the class loader
> >is present but the plugin has not executed any code yet?
> >If so, this is very analog to the OSGi RESOLVED versus
> >ACTIVE states for a bundle (remember a bundle is equivalent
> >to a library plugin).
>
> When a plugin is in a primed state: the plugin is not activated.
> The classloader is here, classes can be loaded and instances created.
> For more details on this see:
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/dynamic
> Plugins/handlePrimedState.html
>
> I don't think this is similar to the OSGi resolved status
>
>
> Regards,
>
>     PaScaL
>
>