Home » Eclipse Projects » Equinox » New states for plugins
| New states for plugins [message #17655] |
Mon, 31 March 2003 12:04  |
Eclipse User |
|
|
|
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~/equi nox-home/dynamic
Plugins/glossary.html and
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynamic
Plugins/registryLifeCycle.html)
The primed state of a plugin (defined in
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-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~/equi nox-home/dynamic
Plugins/handlePrimedState.html
I don't think this is similar to the OSGi resolved status
Regards,
PaScaL
|
|
|
| Re: New states for plugins [message #17668 is a reply to message #17655] |
Mon, 31 March 2003 12:20  |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
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@ca.ibm.com> wrote in message
news:b69s7b$mbn$1@rogue.oti.com...
> 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~/equi nox-home/dynamic
> Plugins/glossary.html and
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynamic
> Plugins/registryLifeCycle.html)
>
> The primed state of a plugin (defined in
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-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~/equi nox-home/dynamic
> Plugins/handlePrimedState.html
>
> I don't think this is similar to the OSGi resolved status
>
>
> Regards,
>
> PaScaL
>
>
|
|
|
| Re: New states for plugins [message #17740 is a reply to message #17668] |
Mon, 31 March 2003 15:16 |
| Eclipse User |
|
|
|
The question of who disable / deactivate is not answered yet. It's an open
question for which
Olivier proposed solution
( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynami
cPlugins/classloadersAndInstances.html) Personnaly I made the assumption
that the disable and the deactivate are called by the user (I commited a
small plugin that allows
that).
"Kevin" <kduffey@marketron.com> wrote in message
news:b69t4i$nav$1@rogue.oti.com...
> 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?
When a plugin is disabled, active plugins are notified of the
disablement.
To be disabled a plugin must be inactive. In contrary to the
unactivation,
the disablement does not cause the disablement of other plugins.
>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?
A plugin can not be active if its prerequisite are not active.
Deactivation of a plugin
causes all the depending plugins to get deactivated too.
So there is not need for if statements as you said.
The plugin registry only changes when a plugin is "enabled" or "disabled".
PaScaL
|
|
|
| Re: New states for plugins [message #18488 is a reply to message #17740] |
Mon, 31 March 2003 16:35 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
The mechanism should be generic enough that various policies can be
implemented to trigger deactivation/disablement. As has been pointed out,
the obvious ones include explicit user action, some sort of LRU,
application-specific policies, ...
This is a very interesting area to think about.
Jeff
"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
news:b6a7fv$oh$1@rogue.oti.com...
> The question of who disable / deactivate is not answered yet. It's an open
> question for which
> Olivier proposed solution
>
( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynami
> cPlugins/classloadersAndInstances.html) Personnaly I made the assumption
> that the disable and the deactivate are called by the user (I commited a
> small plugin that allows
> that).
>
>
> "Kevin" <kduffey@marketron.com> wrote in message
> news:b69t4i$nav$1@rogue.oti.com...
> > 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?
> When a plugin is disabled, active plugins are notified of the
> disablement.
> To be disabled a plugin must be inactive. In contrary to the
> unactivation,
> the disablement does not cause the disablement of other plugins.
>
>
> >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?
> A plugin can not be active if its prerequisite are not active.
> Deactivation of a plugin
> causes all the depending plugins to get deactivated too.
> So there is not need for if statements as you said.
>
> The plugin registry only changes when a plugin is "enabled" or "disabled".
>
> PaScaL
>
>
|
|
|
Goto Forum:
Current Time: Wed Jun 18 11:00:40 EDT 2025
Powered by FUDForum. Page generated in 0.04419 seconds |
Home