Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » Update on Enablement and Disablement Subproject
Update on Enablement and Disablement Subproject [message #23853] Fri, 02 May 2003 19:42 Go to next message
Keith Kimball is currently offline Keith KimballFriend
Messages: 22
Registered: July 2009
Junior Member
I've wanted to let the newsgroup know about work beginning in the
enablement and disablement of plugins area.

The web page has been reformatted and includes a development plan with
specific milestones. As progress is made, more details will be added.

http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynamicPlugins/EnableDisablePlugins.html

I'm currently working on the easiest end to end case which results in
the enablement of a plugin.

Rafael Chaves, from the Eclipse team, is working on milestone #3 which
involves incremental registry resolution. This is one of the most
difficult parts of the project.

We've struggled with the definition of enablement and disablement (see
the issues section) and were hoping for newsgroup comment. A summary of
the issue is:

On startup, the registry resolver is presented with a registry of
unresolved plugins. Many of the plugins are resolved but there may be
some which fail resolution.

Now we come along with a new plugin to be enabled.

One line of thought is that besides the new plugin and the currently
resolved plugins, we should also consider plugins which previous failed
resolution. The result is that by enabling one plugin, we could have an
entire set of plugins become resolved. On the negative side, by
considering a new plugin, we could have a currently resolved plugin go
unresolved.

The other line of thought is to only consider the new plugin and
currently resolved plugins. The operation succeeds if the new plugin can
be resolved into the registry without causing any plugins to become
unresolved. (Ignore extensions etc).

Comments?

Thanks,
Keith
Re: Update on Enablement and Disablement Subproject [message #23896 is a reply to message #23853] Mon, 05 May 2003 13:50 Go to previous messageGo to next message
Pascal Rapicault is currently offline Pascal RapicaultFriend
Messages: 333
Registered: July 2009
Location: Ottawa
Senior Member
Keith,

I checked your documents and the progress you are making with Raphael are
great. Let us now when you are able to enable a simple plugin!!!

I have comments about the terminology and some other details:
- I find the "unresolved" state to be confusing with the existing
one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
amicPlugins/state_description.html), especially in this area of the registry
resolution. To my opinion a clear distinction between the states unresolved,
disabled, etc. is necessary because they do not represent the same
information.

- In the bullet 3 of the "plugin diagram" section it is said "During
platform startup, a registry of unresolved plugins is presented for
resolution" however, I think it is "During platform startup, a SET of
ENABLED plugins is presented for resolution"


> One line of thought is that besides the new plugin and the currently
> resolved plugins, we should also consider plugins which previous failed
> resolution. The result is that by enabling one plugin, we could have an
> entire set of plugins become resolved. On the negative side, by
> considering a new plugin, we could have a currently resolved plugin go
> unresolved.
>
> The other line of thought is to only consider the new plugin and
> currently resolved plugins. The operation succeeds if the new plugin can
> be resolved into the registry without causing any plugins to become
> unresolved. (Ignore extensions etc).
From the two approaches stated above, I think the first one makes the
more sense because it is deterministic. The second one is not because the
resolution of plugins depend on enablement order. An other problem that I
can see in the second case is the difference between resolved and unresolved
plugins between two sessions: for example during a session I can try to
enable plugin (whose resolution fails). Then I shutdown and restart, the
plugin whose resolution failed during the previous startup is resolved this
time, and may cause other plugins to be resolved or unresolved.

Don't you think that the registry could keep track of the unresolved
plugins?

Could you give more details about the concept of DynamicExtensionPoint?

HTH

PaScaL
DynamicExtensionPoint [message #23936 is a reply to message #23896] Mon, 05 May 2003 17:38 Go to previous messageGo to next message
Keith Kimball is currently offline Keith KimballFriend
Messages: 22
Registered: July 2009
Junior Member
I've been doing background thinking and not a lot of research regarding
how to handle dynamic extension points. So, please don't tear my random
thoughts to threads.

The issue I'm worried about is a plugin having a menu item up and we
want to disable it. For this to work, the plugin containing the
extension point needs to be able dynamically remove the menu item. The
idea would be that the extension point could declare itself as being
able to handle dynamicity and then corresponding extensions could be
safely disabled (provided all other conditions are met). This could be
done by having a class which extends ExtensionPoint (may be otherwise
identical?) and conveys the information.

We would have to work though all 4 combinations of extension/extension
point and static/dynamic to see if works. If it does, then we could
maintain compabitlity with existing plugins with the property of not
allowing disablement until the plugin is upgrade to handle dynamicity.

As I said, I'm currently focused on registry resolution and not on
extension points but at 1st glance it seems like a interesting path to
explore.

Thanks for your comments,
Keith

Pascal Rapicault wrote:
> Keith,
>
> I checked your documents and the progress you are making with Raphael are
> great. Let us now when you are able to enable a simple plugin!!!
>
> I have comments about the terminology and some other details:
> - I find the "unresolved" state to be confusing with the existing
> one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> amicPlugins/state_description.html), especially in this area of the registry
> resolution. To my opinion a clear distinction between the states unresolved,
> disabled, etc. is necessary because they do not represent the same
> information.
>
> - In the bullet 3 of the "plugin diagram" section it is said "During
> platform startup, a registry of unresolved plugins is presented for
> resolution" however, I think it is "During platform startup, a SET of
> ENABLED plugins is presented for resolution"
>
>
>
>>One line of thought is that besides the new plugin and the currently
>>resolved plugins, we should also consider plugins which previous failed
>>resolution. The result is that by enabling one plugin, we could have an
>>entire set of plugins become resolved. On the negative side, by
>>considering a new plugin, we could have a currently resolved plugin go
>>unresolved.
>>
>>The other line of thought is to only consider the new plugin and
>>currently resolved plugins. The operation succeeds if the new plugin can
>>be resolved into the registry without causing any plugins to become
>>unresolved. (Ignore extensions etc).
>
> From the two approaches stated above, I think the first one makes the
> more sense because it is deterministic. The second one is not because the
> resolution of plugins depend on enablement order. An other problem that I
> can see in the second case is the difference between resolved and unresolved
> plugins between two sessions: for example during a session I can try to
> enable plugin (whose resolution fails). Then I shutdown and restart, the
> plugin whose resolution failed during the previous startup is resolved this
> time, and may cause other plugins to be resolved or unresolved.
>
> Don't you think that the registry could keep track of the unresolved
> plugins?
>
> Could you give more details about the concept of DynamicExtensionPoint?
>
> HTH
>
> PaScaL
>
>
States [message #23976 is a reply to message #23896] Mon, 05 May 2003 18:20 Go to previous messageGo to next message
Keith Kimball is currently offline Keith KimballFriend
Messages: 22
Registered: July 2009
Junior Member
Pascal,

So far little progress but it's great that Raphael joined the project.
We have a good division of labor as he's looking at the difficult area
of registry resoltion and I'm making broader changes needed to drive his
work.

I'll address you comments inline - prefixed by ** Keith **
Keith

Pascal Rapicault wrote:
> Keith,
>
> I checked your documents and the progress you are making with Raphael are
> great. Let us now when you are able to enable a simple plugin!!!
>
> I have comments about the terminology and some other details:
> - I find the "unresolved" state to be confusing with the existing
> one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> amicPlugins/state_description.html), especially in this area of the registry
> resolution. To my opinion a clear distinction between the states unresolved,
> disabled, etc. is necessary because they do not represent the same
> information.

** Keith **
What information is different? In either case, they are not resolved
with the registry. The main difference is that you want to consider
"unresolved" and not "disabled" plugins during the next registry resolution

>
> - In the bullet 3 of the "plugin diagram" section it is said "During
> platform startup, a registry of unresolved plugins is presented for
> resolution" however, I think it is "During platform startup, a SET of
> ENABLED plugins is presented for resolution"
>
>
** Keith **
Are we both correct? Aren't enabled plugins either resolved or
unresolved and aren't only unresolved plugins being presented for
resolution?


>
>>One line of thought is that besides the new plugin and the currently
>>resolved plugins, we should also consider plugins which previous failed
>>resolution. The result is that by enabling one plugin, we could have an
>>entire set of plugins become resolved. On the negative side, by
>>considering a new plugin, we could have a currently resolved plugin go
>>unresolved.
>>
>>The other line of thought is to only consider the new plugin and
>>currently resolved plugins. The operation succeeds if the new plugin can
>>be resolved into the registry without causing any plugins to become
>>unresolved. (Ignore extensions etc).
>
> From the two approaches stated above, I think the first one makes the
> more sense because it is deterministic. The second one is not because the
> resolution of plugins depend on enablement order. An other problem that I
> can see in the second case is the difference between resolved and unresolved
> plugins between two sessions: for example during a session I can try to
> enable plugin (whose resolution fails). Then I shutdown and restart, the
> plugin whose resolution failed during the previous startup is resolved this
> time, and may cause other plugins to be resolved or unresolved.

** Keith **
To me, the former seems more natural. I say plugin.enable() and the only
registry change is the enablement of that plugin. Your approach has
the advantage that enabling one plugin can cause an entire group of
plugins to become resolved but also has the disadvantage of potentially
causing a resolved plugin to become unresolved.

Interesting comment about deterministic - I hadn't thought of it.

>
> Don't you think that the registry could keep track of the unresolved
> plugins?

** Keith **
Easily and in a compatibley manner so that existing routines would
return the same results as today.

>
> Could you give more details about the concept of DynamicExtensionPoint?
** Keith **
Previous posting.

>
> HTH
>
> PaScaL
>
>
Re: Update on Enablement and Disablement Subproject [message #24018 is a reply to message #23853] Mon, 05 May 2003 19:46 Go to previous messageGo to next message
Mel Martinez is currently offline Mel MartinezFriend
Messages: 44
Registered: July 2009
Member
Keith Kimball wrote:
>>
> We've struggled with the definition of enablement and disablement (see
> the issues section) and were hoping for newsgroup comment. A summary of
> the issue is:
>
> On startup, the registry resolver is presented with a registry of
> unresolved plugins. Many of the plugins are resolved but there may be
> some which fail resolution.
>
> Now we come along with a new plugin to be enabled.
>
> One line of thought is that besides the new plugin and the currently
> resolved plugins, we should also consider plugins which previous failed
> resolution. The result is that by enabling one plugin, we could have an
> entire set of plugins become resolved. On the negative side, by
> considering a new plugin, we could have a currently resolved plugin go
> unresolved.
>
> The other line of thought is to only consider the new plugin and
> currently resolved plugins. The operation succeeds if the new plugin can
> be resolved into the registry without causing any plugins to become
> unresolved. (Ignore extensions etc).
>

I think that in general, my preferred default behavior would be to try
to resolve while including formerly unresolved plugins. It seems
logical to me that a common reason for 'adding' a new plugin would be to
try to fix those unresolved dependencies.

Another option is to explicitely ask the user if that is what he wants.
I.E. he adds a new plugin and a UI for confirmation allows him to
select from other unresolved plugins to try to resolve. This would have
to be just one possible mode, though. It would not make sense in a
headless mode.

I believe that the simplest default case for handling the outcome of the
resolution should be that if the resulting configuration results in the
'unresolving' of previously resolved plugins that it be considered a
failure. However, one could, again, prompt the user with something like:

"Adding <the specified> plugin(s) would result in the unloading of
<specified other> plugins due to <conflicts>. Would you like to
continue? [Continue|Cancel]"

This would be appropriate in the case where the user specifically
doesn't care that a particular plugin is no longer resolved and thus
unavailable. In fact it may be he/she deterministically wants that to
happen.

I realize that providing these options presents additional complexity,
but flexibility usually pays off in the long run.

Just some thoughts.

Mel
Re: States [message #24052 is a reply to message #23976] Mon, 05 May 2003 22:06 Go to previous messageGo to next message
Pascal Rapicault is currently offline Pascal RapicaultFriend
Messages: 333
Registered: July 2009
Location: Ottawa
Senior Member
> > I have comments about the terminology and some other details:
> > - I find the "unresolved" state to be confusing with the existing
> >
one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> > amicPlugins/state_description.html), especially in this area of the
registry
> > resolution. To my opinion a clear distinction between the states
unresolved,
> > disabled, etc. is necessary because they do not represent the same
> > information.
>
> ** Keith **
> What information is different? In either case, they are not resolved
> with the registry. The main difference is that you want to consider
> "unresolved" and not "disabled" plugins during the next registry
resolution
**Pascal**
The difference I see between unresolved and disabled, is that unresolved
is the result of a registry resolution and that disabled is the result of a
user operation who somehow decided to no longer use a plugin and disabled
it. A plugin that is disabled does not participate in registry resolution.

> > - In the bullet 3 of the "plugin diagram" section it is said "During
> > platform startup, a registry of unresolved plugins is presented for
> > resolution" however, I think it is "During platform startup, a SET of
> > ENABLED plugins is presented for resolution"
> >
> >
> ** Keith **
> Are we both correct? Aren't enabled plugins either resolved or
> unresolved and aren't only unresolved plugins being presented for
> resolution?
**Pascal**
To me, only resolved plugins are presented to the registry.

PaScaL
Re: States [message #24080 is a reply to message #24052] Tue, 06 May 2003 16:39 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com

"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
news:b96n8g$4tu$1@rogue.oti.com...
> > ** Keith **
> > Are we both correct? Aren't enabled plugins either resolved or
> > unresolved and aren't only unresolved plugins being presented for
> > resolution?
> **Pascal**
> To me, only resolved plugins are presented to the registry.

In the hope of clarifying, here's my cut...

All enabled (both resolved and unresolved) plugins are presented to the
resolver. The resolver computes and figures out which are resolved and
which are unresolved. The current model has the registry remembering only
the resolved plugins. It has been proposed that the registry have
additional API to report the unresolved plugins as well. The current API
would not change.

Jeff
Re: Update on Enablement and Disablement Subproject [message #24099 is a reply to message #23853] Tue, 06 May 2003 17:41 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com

"Keith Kimball" <keith2@us.ibm.com> wrote in message
news:b8uhlj$cje$1@rogue.oti.com...
> I've wanted to let the newsgroup know about work beginning in the
> enablement and disablement of plugins area.
>
> The web page has been reformatted and includes a development plan with
> specific milestones. As progress is made, more details will be added.
>
>
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dynamic
Plugins/EnableDisablePlugins.html
>
> I'm currently working on the easiest end to end case which results in
> the enablement of a plugin.


WRT the API...
The first usecase for the dynamic plugin function is to allow plugins to be
(from the user's point of view) installed, updated and removed dynamically
(without shutdown/restart). In terms of triggering this, it should only
require a IPluginRegistry.refresh() (or some such) method being called by
some "external" configuration mechanism (e.g., PlatformConfiguration).

To enable/disable plugins from code we should be consulting the object
(e.g., PlatformConfiguration) which manages the over all plugin
configuration we are running. For example,
PlatformConfiguration.disable/enable(plug-in ids[])
<not sure what kind of object to use as the arg here. We need the
plugin id and version but can't (don't really want to) use a
descriptor>
And then use IPluginRegistry.refresh(). This allows for batching of
expensive registry change operations.

Note that the API cannot go on the registry because there is no way to get
the plugin or descriptor for plugins which are not enabled. For unresolved
plugins we may not even be able to get the descriptor and certainly could
not get the plugin itself.

Jeff
Re: States [message #24184 is a reply to message #24052] Tue, 06 May 2003 19:24 Go to previous messageGo to next message
Keith Kimball is currently offline Keith KimballFriend
Messages: 22
Registered: July 2009
Junior Member
Thanks for your comments!!!

I will change the design such that unresolved plugins are considered
during enable and disablement. This is not my preference but I believe
in the principles of "when in Rome act like Romans" and "Respect those
with more experience in an area than yourself". You and Jeff are clearly
the Romans with the experience and I would be foolish not to follow your
suggestions especially given the requirement to get code accepted by the
Platform team.

A technical nit, it's my reading of the existing code that during
startup, the registry contains only unresolved plugins, resolution
occurs, and then unresolved plugins are trimmed from the registy. After
startup, the registry only contains resolved plugins. Thus the claim
that only unresolved plugins are presented for resolution.
Re: Update on Enablement and Disablement Subproject [message #24225 is a reply to message #24018] Tue, 06 May 2003 19:25 Go to previous messageGo to next message
Keith Kimball is currently offline Keith KimballFriend
Messages: 22
Registered: July 2009
Junior Member
Will adopt your suggestion.
Re: Update on Enablement and Disablement Subproject [message #24268 is a reply to message #24099] Tue, 06 May 2003 19:26 Go to previous messageGo to next message
Keith Kimball is currently offline Keith KimballFriend
Messages: 22
Registered: July 2009
Junior Member
Thanks for the suggested APIs. I will explore their use.
Re: States [message #24354 is a reply to message #24184] Wed, 07 May 2003 13:55 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com

"Keith Kimball" <keith2@us.ibm.com> wrote in message
news:b99243$obc$1@rogue.oti.com...
> Thanks for your comments!!!
>
> I will change the design such that unresolved plugins are considered
> during enable and disablement. This is not my preference but I believe
> in the principles of "when in Rome act like Romans" and "Respect those
> with more experience in an area than yourself". You and Jeff are clearly
> the Romans with the experience and I would be foolish not to follow your
> suggestions especially given the requirement to get code accepted by the
> Platform team.

Don't be too humble Keith. The dynamic plugins stuff is new and we are all
working through the issues. It is great to have "non-Romans" involved
because they don't carry all the baggage of having worked on this stuff for
a long time. In short, it is good to have assumptions questioned. Keep it
up.

> A technical nit, it's my reading of the existing code that during
> startup, the registry contains only unresolved plugins, resolution
> occurs, and then unresolved plugins are trimmed from the registy. After
> startup, the registry only contains resolved plugins. Thus the claim
> that only unresolved plugins are presented for resolution.

In the current model yes, only unresolved plugins are presented for
resolution. But that's not too surprising since the current model only
resolves the registry once. By definition then all plugins are unresolved
whenever the resolver runs.

Sidenote: It was an implementation convenience to populate "the registry"
with the unresolved plugins and then have the resolver trim. It would be
clearer if we think of the registry as the result of resolution. The
datastructure input to the resolver should really just be a collection of
plugins.

In the dynamic model the resolver runs more times. You could consider that
each time the resolver is run all plugins are marked unresolved. That seems
like semantic trickery. Under the model I have described, the resolver
simply considers all enabled plugins regardless of their resolved state.
The result is a registry that contains only resolved plugins (as with the
current approach). We should have API (on the registry or otherwise) to get
the set of enabled but unresolved plugins and prehaps reasons why the plugin
is unresolved. As you have pointed out, the current API should continue to
deal in resolved plugins.

Jeff
Re: States [message #24395 is a reply to message #24354] Wed, 07 May 2003 21:14 Go to previous messageGo to next message
Mel Martinez is currently offline Mel MartinezFriend
Messages: 44
Registered: July 2009
Member
Jeff McAffer wrote:

> In the dynamic model the resolver runs more times. You could consider that
> each time the resolver is run all plugins are marked unresolved. That seems
> like semantic trickery. Under the model I have described, the resolver
> simply considers all enabled plugins regardless of their resolved state.
> The result is a registry that contains only resolved plugins (as with the
> current approach). We should have API (on the registry or otherwise) to get
> the set of enabled but unresolved plugins and prehaps reasons why the plugin
> is unresolved. As you have pointed out, the current API should continue to
> deal in resolved plugins.
>

For our purposes, would it be useful to decouple the RegistryResolver
class from the PluginRegistryModel class by adding a resolve() method
that simply takes an array of plugins (i.e. 'PluginDescriptorModel[]')
and returns a resolved (trimmed) array?

Mel
Re: States [message #24436 is a reply to message #24395] Wed, 07 May 2003 21:48 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com

That sounds about right. I'm not sure where exactly it should go etc.

Jeff

"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b9bt5r$r9k$1@rogue.oti.com...
> Jeff McAffer wrote:
>
> > In the dynamic model the resolver runs more times. You could consider
that
> > each time the resolver is run all plugins are marked unresolved. That
seems
> > like semantic trickery. Under the model I have described, the resolver
> > simply considers all enabled plugins regardless of their resolved state.
> > The result is a registry that contains only resolved plugins (as with
the
> > current approach). We should have API (on the registry or otherwise) to
get
> > the set of enabled but unresolved plugins and prehaps reasons why the
plugin
> > is unresolved. As you have pointed out, the current API should continue
to
> > deal in resolved plugins.
> >
>
> For our purposes, would it be useful to decouple the RegistryResolver
> class from the PluginRegistryModel class by adding a resolve() method
> that simply takes an array of plugins (i.e. 'PluginDescriptorModel[]')
> and returns a resolved (trimmed) array?
>
> Mel
>
Re: DynamicExtensionPoint [message #24478 is a reply to message #23936] Mon, 12 May 2003 23:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: kduffey.marketron.com

I have a similar issue with my own engine and handling dynamic
load/unload/reload of plugins. One thought I had on this, which also touches
on your other threads in enable/disable, is rather than resolve a plugin
when the engine first starts, only resolve at runtime. It would add a bit of
overhead, but only on each first time need to resolve. Once a given
dependent class is resolved it sits in the classloader cache.

I haven't actually implemented this yet. I am not sure if it is a bad idea
at this point, but I tend to believe it would work out well. If a plugin is
added after the app is running, and it attaches to an existing extension
point, things are fine. If the plugin that owns the existing extension point
is unloaded or disabled, then somehow all extensions "listening" to that
extension point need to be notified not to use it any longer, right? The
only way I really seeing this work properly is on a per plugin
implementation basis. Every plugin would have to be written to assume any
dependent code it uses might not be available. This actually fits in very
well with the concept of services as well. If code uses a service (such as
how OSGi may implement a service), it has to check to see that the service
is available before making any calls to it, otherwise NPEs or other nasties
could occur. So long as all plugins are handling these types of checks,
there should be no issues with pluging being
loaded/unloaded/enabled/disabled.



"Keith Kimball" <keith2@us.ibm.com> wrote in message
news:b967gr$p8j$1@rogue.oti.com...
> I've been doing background thinking and not a lot of research regarding
> how to handle dynamic extension points. So, please don't tear my random
> thoughts to threads.
>
> The issue I'm worried about is a plugin having a menu item up and we
> want to disable it. For this to work, the plugin containing the
> extension point needs to be able dynamically remove the menu item. The
> idea would be that the extension point could declare itself as being
> able to handle dynamicity and then corresponding extensions could be
> safely disabled (provided all other conditions are met). This could be
> done by having a class which extends ExtensionPoint (may be otherwise
> identical?) and conveys the information.
>
> We would have to work though all 4 combinations of extension/extension
> point and static/dynamic to see if works. If it does, then we could
> maintain compabitlity with existing plugins with the property of not
> allowing disablement until the plugin is upgrade to handle dynamicity.
>
> As I said, I'm currently focused on registry resolution and not on
> extension points but at 1st glance it seems like a interesting path to
> explore.
>
> Thanks for your comments,
> Keith
>
> Pascal Rapicault wrote:
> > Keith,
> >
> > I checked your documents and the progress you are making with Raphael
are
> > great. Let us now when you are able to enable a simple plugin!!!
> >
> > I have comments about the terminology and some other details:
> > - I find the "unresolved" state to be confusing with the existing
> >
one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> > amicPlugins/state_description.html), especially in this area of the
registry
> > resolution. To my opinion a clear distinction between the states
unresolved,
> > disabled, etc. is necessary because they do not represent the same
> > information.
> >
> > - In the bullet 3 of the "plugin diagram" section it is said "During
> > platform startup, a registry of unresolved plugins is presented for
> > resolution" however, I think it is "During platform startup, a SET of
> > ENABLED plugins is presented for resolution"
> >
> >
> >
> >>One line of thought is that besides the new plugin and the currently
> >>resolved plugins, we should also consider plugins which previous failed
> >>resolution. The result is that by enabling one plugin, we could have an
> >>entire set of plugins become resolved. On the negative side, by
> >>considering a new plugin, we could have a currently resolved plugin go
> >>unresolved.
> >>
> >>The other line of thought is to only consider the new plugin and
> >>currently resolved plugins. The operation succeeds if the new plugin can
> >>be resolved into the registry without causing any plugins to become
> >>unresolved. (Ignore extensions etc).
> >
> > From the two approaches stated above, I think the first one makes
the
> > more sense because it is deterministic. The second one is not because
the
> > resolution of plugins depend on enablement order. An other problem that
I
> > can see in the second case is the difference between resolved and
unresolved
> > plugins between two sessions: for example during a session I can try to
> > enable plugin (whose resolution fails). Then I shutdown and restart, the
> > plugin whose resolution failed during the previous startup is resolved
this
> > time, and may cause other plugins to be resolved or unresolved.
> >
> > Don't you think that the registry could keep track of the unresolved
> > plugins?
> >
> > Could you give more details about the concept of DynamicExtensionPoint?
> >
> > HTH
> >
> > PaScaL
> >
> >
>
Re: States [message #24519 is a reply to message #24436] Mon, 12 May 2003 23:38 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: kduffey.marketron.com

Perhaps I am missing the point, but why do all "resolved" plugins need to be
checked if they are already resolved? As I see it, the JVM asks a
classloader to find it a class. The classloader at that point could attempt
to "resolve" a given class at runtime, as opposed to a resolver (thread?)
running so often to resolve all plugins even if they are resolved.


"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b9buvf$scs$1@rogue.oti.com...
> That sounds about right. I'm not sure where exactly it should go etc.
>
> Jeff
>
> "Mel Martinez" <melm@us.ibm.com> wrote in message
> news:b9bt5r$r9k$1@rogue.oti.com...
> > Jeff McAffer wrote:
> >
> > > In the dynamic model the resolver runs more times. You could consider
> that
> > > each time the resolver is run all plugins are marked unresolved. That
> seems
> > > like semantic trickery. Under the model I have described, the
resolver
> > > simply considers all enabled plugins regardless of their resolved
state.
> > > The result is a registry that contains only resolved plugins (as with
> the
> > > current approach). We should have API (on the registry or otherwise)
to
> get
> > > the set of enabled but unresolved plugins and prehaps reasons why the
> plugin
> > > is unresolved. As you have pointed out, the current API should
continue
> to
> > > deal in resolved plugins.
> > >
> >
> > For our purposes, would it be useful to decouple the RegistryResolver
> > class from the PluginRegistryModel class by adding a resolve() method
> > that simply takes an array of plugins (i.e. 'PluginDescriptorModel[]')
> > and returns a resolved (trimmed) array?
> >
> > Mel
> >
>
>
Re: States [message #24560 is a reply to message #24395] Tue, 13 May 2003 16:55 Go to previous messageGo to next message
Keith Kimball is currently offline Keith KimballFriend
Messages: 22
Registered: July 2009
Junior Member
Mel,

I think this is a good idea. I've now thinking of resoltion as occuring
in 3 steps:

* Resolving the registry w/o considering extensions. This could be done
by passing 2 arguments:
PluginDescriptorModel[]
PluginFragmentModel[]
The result of this operation is a MultiStatus and each plugin is
marked as enabled or disabled. This should probably be called resolved
or unresolved but ... I actually haven't started using the arrays yet.
I made the function static with the interface being:

status = RegistryResolver.resolve(plugins,fragments);

* Trimming the registry. I don't think this belongs in
RegistryResolution. I've moved the function into
RegistryPluginModel.resolve which steps through the array of
PluginModelDescriptors and moves the "disabled" ones to a list of
unresolved plugins which I can then use for the next resolution.
This is done conditionally based on a boolean passed to
PluginRegistryModel.resolve called trimDisabledPlugins. Its always
passed as true.

* Resolving Extension and Extension Points. I beleive this could also
be done with a simple list of plugins. I've made it static and the
final interface would look like

status = RegistryResolver.resolveExtensions(plugins).

The one problem is a lose of a nice access function included with
the registry. This is done conditionally based on the crossLink
parameter based to PluginRegistryModel.

The nice part of this is that these are the only 2 public functions
avaiable from RegistryResolver.

One final comment - we should probably move the "extension Resolver" out
of RegistryResolver and into its own class. Having the two together just
makes the RegistryResolver look a lot more complicated than it actually
is.

Mel Martinez wrote:
> Jeff McAffer wrote:
>
>> In the dynamic model the resolver runs more times. You could consider
>> that
>> each time the resolver is run all plugins are marked unresolved. That
>> seems
>> like semantic trickery. Under the model I have described, the resolver
>> simply considers all enabled plugins regardless of their resolved state.
>> The result is a registry that contains only resolved plugins (as with the
>> current approach). We should have API (on the registry or otherwise)
>> to get
>> the set of enabled but unresolved plugins and prehaps reasons why the
>> plugin
>> is unresolved. As you have pointed out, the current API should
>> continue to
>> deal in resolved plugins.
>>
>
> For our purposes, would it be useful to decouple the RegistryResolver
> class from the PluginRegistryModel class by adding a resolve() method
> that simply takes an array of plugins (i.e. 'PluginDescriptorModel[]')
> and returns a resolved (trimmed) array?
>
> Mel
>
Re: States [message #24601 is a reply to message #24560] Tue, 13 May 2003 19:37 Go to previous messageGo to next message
Mel Martinez is currently offline Mel MartinezFriend
Messages: 44
Registered: July 2009
Member
Excellent! This is pretty much what I was thinking should be done.

I also agree with refactoring the extension resolver.

I'm thinking it might be useful to be able to re-use the resolution
algorithm in a couple of places, such as installation of plugins via
update or from a separate installer. Thus this refactoring could be handy.

Mel


Keith Kimball wrote:
> Mel,
>
> I think this is a good idea. I've now thinking of resoltion as occuring
> in 3 steps:
>
> * Resolving the registry w/o considering extensions. This could be done
> by passing 2 arguments:
> PluginDescriptorModel[]
> PluginFragmentModel[]
> The result of this operation is a MultiStatus and each plugin is
> marked as enabled or disabled. This should probably be called resolved
> or unresolved but ... I actually haven't started using the arrays yet.
> I made the function static with the interface being:
>
> status = RegistryResolver.resolve(plugins,fragments);
>
> * Trimming the registry. I don't think this belongs in
> RegistryResolution. I've moved the function into
> RegistryPluginModel.resolve which steps through the array of
> PluginModelDescriptors and moves the "disabled" ones to a list of
> unresolved plugins which I can then use for the next resolution.
> This is done conditionally based on a boolean passed to
> PluginRegistryModel.resolve called trimDisabledPlugins. Its always
> passed as true.
>
> * Resolving Extension and Extension Points. I beleive this could also
> be done with a simple list of plugins. I've made it static and the
> final interface would look like
>
> status = RegistryResolver.resolveExtensions(plugins).
>
> The one problem is a lose of a nice access function included with
> the registry. This is done conditionally based on the crossLink
> parameter based to PluginRegistryModel.
>
> The nice part of this is that these are the only 2 public functions
> avaiable from RegistryResolver.
>
> One final comment - we should probably move the "extension Resolver" out
> of RegistryResolver and into its own class. Having the two together just
> makes the RegistryResolver look a lot more complicated than it actually
> is.
>
> Mel Martinez wrote:
>
>> Jeff McAffer wrote:
>>
>>> In the dynamic model the resolver runs more times. You could
>>> consider that
>>> each time the resolver is run all plugins are marked unresolved.
>>> That seems
>>> like semantic trickery. Under the model I have described, the resolver
>>> simply considers all enabled plugins regardless of their resolved state.
>>> The result is a registry that contains only resolved plugins (as with
>>> the
>>> current approach). We should have API (on the registry or otherwise)
>>> to get
>>> the set of enabled but unresolved plugins and prehaps reasons why the
>>> plugin
>>> is unresolved. As you have pointed out, the current API should
>>> continue to
>>> deal in resolved plugins.
>>>
>>
>> For our purposes, would it be useful to decouple the RegistryResolver
>> class from the PluginRegistryModel class by adding a resolve() method
>> that simply takes an array of plugins (i.e. 'PluginDescriptorModel[]')
>> and returns a resolved (trimmed) array?
>>
>> Mel
>>
>
Re: States [message #24682 is a reply to message #24601] Wed, 14 May 2003 03:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com

See my notes in the equinox mailing list. I agree with the trend towards
separating the parts of the resolution system and registry and would would
like to push it as far as possible.

Jeff

"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b9ri1h$g9r$1@rogue.oti.com...
> Excellent! This is pretty much what I was thinking should be done.
>
> I also agree with refactoring the extension resolver.
>
> I'm thinking it might be useful to be able to re-use the resolution
> algorithm in a couple of places, such as installation of plugins via
> update or from a separate installer. Thus this refactoring could be
handy.
>
> Mel
>
>
> Keith Kimball wrote:
> > Mel,
> >
> > I think this is a good idea. I've now thinking of resoltion as occuring
> > in 3 steps:
> >
> > * Resolving the registry w/o considering extensions. This could be done
> > by passing 2 arguments:
> > PluginDescriptorModel[]
> > PluginFragmentModel[]
> > The result of this operation is a MultiStatus and each plugin is
> > marked as enabled or disabled. This should probably be called resolved
> > or unresolved but ... I actually haven't started using the arrays yet.
> > I made the function static with the interface being:
> >
> > status = RegistryResolver.resolve(plugins,fragments);
> >
> > * Trimming the registry. I don't think this belongs in
> > RegistryResolution. I've moved the function into
> > RegistryPluginModel.resolve which steps through the array of
> > PluginModelDescriptors and moves the "disabled" ones to a list of
> > unresolved plugins which I can then use for the next resolution.
> > This is done conditionally based on a boolean passed to
> > PluginRegistryModel.resolve called trimDisabledPlugins. Its always
> > passed as true.
> >
> > * Resolving Extension and Extension Points. I beleive this could also
> > be done with a simple list of plugins. I've made it static and the
> > final interface would look like
> >
> > status = RegistryResolver.resolveExtensions(plugins).
> >
> > The one problem is a lose of a nice access function included with
> > the registry. This is done conditionally based on the crossLink
> > parameter based to PluginRegistryModel.
> >
> > The nice part of this is that these are the only 2 public functions
> > avaiable from RegistryResolver.
> >
> > One final comment - we should probably move the "extension Resolver" out
> > of RegistryResolver and into its own class. Having the two together just
> > makes the RegistryResolver look a lot more complicated than it actually
> > is.
> >
> > Mel Martinez wrote:
> >
> >> Jeff McAffer wrote:
> >>
> >>> In the dynamic model the resolver runs more times. You could
> >>> consider that
> >>> each time the resolver is run all plugins are marked unresolved.
> >>> That seems
> >>> like semantic trickery. Under the model I have described, the
resolver
> >>> simply considers all enabled plugins regardless of their resolved
state.
> >>> The result is a registry that contains only resolved plugins (as with
> >>> the
> >>> current approach). We should have API (on the registry or otherwise)
> >>> to get
> >>> the set of enabled but unresolved plugins and prehaps reasons why the
> >>> plugin
> >>> is unresolved. As you have pointed out, the current API should
> >>> continue to
> >>> deal in resolved plugins.
> >>>
> >>
> >> For our purposes, would it be useful to decouple the RegistryResolver
> >> class from the PluginRegistryModel class by adding a resolve() method
> >> that simply takes an array of plugins (i.e. 'PluginDescriptorModel[]')
> >> and returns a resolved (trimmed) array?
> >>
> >> Mel
> >>
> >
>
Re: DynamicExtensionPoint [message #24722 is a reply to message #24478] Sat, 17 May 2003 18:55 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mkot.at.ru

It is looks like Service Configurator pattern.
See articles of Douglas Schmidt:
http://www.cs.wustl.edu/~schmidt/PDF/O-Service-Configurator. pdf

Michail

"Kevin" <kduffey@marketron.com> wrote in message
news:b9pb4c$mt7$1@rogue.oti.com...
> I have a similar issue with my own engine and handling dynamic
> load/unload/reload of plugins. One thought I had on this, which also
touches
> on your other threads in enable/disable, is rather than resolve a plugin
> when the engine first starts, only resolve at runtime. It would add a bit
of
> overhead, but only on each first time need to resolve. Once a given
> dependent class is resolved it sits in the classloader cache.
>
> I haven't actually implemented this yet. I am not sure if it is a bad idea
> at this point, but I tend to believe it would work out well. If a plugin
is
> added after the app is running, and it attaches to an existing extension
> point, things are fine. If the plugin that owns the existing extension
point
> is unloaded or disabled, then somehow all extensions "listening" to that
> extension point need to be notified not to use it any longer, right? The
> only way I really seeing this work properly is on a per plugin
> implementation basis. Every plugin would have to be written to assume any
> dependent code it uses might not be available. This actually fits in very
> well with the concept of services as well. If code uses a service (such as
> how OSGi may implement a service), it has to check to see that the service
> is available before making any calls to it, otherwise NPEs or other
nasties
> could occur. So long as all plugins are handling these types of checks,
> there should be no issues with pluging being
> loaded/unloaded/enabled/disabled.
>
>
>
> "Keith Kimball" <keith2@us.ibm.com> wrote in message
> news:b967gr$p8j$1@rogue.oti.com...
> > I've been doing background thinking and not a lot of research regarding
> > how to handle dynamic extension points. So, please don't tear my random
> > thoughts to threads.
> >
> > The issue I'm worried about is a plugin having a menu item up and we
> > want to disable it. For this to work, the plugin containing the
> > extension point needs to be able dynamically remove the menu item. The
> > idea would be that the extension point could declare itself as being
> > able to handle dynamicity and then corresponding extensions could be
> > safely disabled (provided all other conditions are met). This could be
> > done by having a class which extends ExtensionPoint (may be otherwise
> > identical?) and conveys the information.
> >
> > We would have to work though all 4 combinations of extension/extension
> > point and static/dynamic to see if works. If it does, then we could
> > maintain compabitlity with existing plugins with the property of not
> > allowing disablement until the plugin is upgrade to handle dynamicity.
> >
> > As I said, I'm currently focused on registry resolution and not on
> > extension points but at 1st glance it seems like a interesting path to
> > explore.
> >
> > Thanks for your comments,
> > Keith
> >
> > Pascal Rapicault wrote:
> > > Keith,
> > >
> > > I checked your documents and the progress you are making with Raphael
> are
> > > great. Let us now when you are able to enable a simple plugin!!!
> > >
> > > I have comments about the terminology and some other details:
> > > - I find the "unresolved" state to be confusing with the existing
> > >
>
one( http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/dyn
> > > amicPlugins/state_description.html), especially in this area of the
> registry
> > > resolution. To my opinion a clear distinction between the states
> unresolved,
> > > disabled, etc. is necessary because they do not represent the same
> > > information.
> > >
> > > - In the bullet 3 of the "plugin diagram" section it is said
"During
> > > platform startup, a registry of unresolved plugins is presented for
> > > resolution" however, I think it is "During platform startup, a SET of
> > > ENABLED plugins is presented for resolution"
> > >
> > >
> > >
> > >>One line of thought is that besides the new plugin and the currently
> > >>resolved plugins, we should also consider plugins which previous
failed
> > >>resolution. The result is that by enabling one plugin, we could have
an
> > >>entire set of plugins become resolved. On the negative side, by
> > >>considering a new plugin, we could have a currently resolved plugin go
> > >>unresolved.
> > >>
> > >>The other line of thought is to only consider the new plugin and
> > >>currently resolved plugins. The operation succeeds if the new plugin
can
> > >>be resolved into the registry without causing any plugins to become
> > >>unresolved. (Ignore extensions etc).
> > >
> > > From the two approaches stated above, I think the first one makes
> the
> > > more sense because it is deterministic. The second one is not because
> the
> > > resolution of plugins depend on enablement order. An other problem
that
> I
> > > can see in the second case is the difference between resolved and
> unresolved
> > > plugins between two sessions: for example during a session I can try
to
> > > enable plugin (whose resolution fails). Then I shutdown and restart,
the
> > > plugin whose resolution failed during the previous startup is resolved
> this
> > > time, and may cause other plugins to be resolved or unresolved.
> > >
> > > Don't you think that the registry could keep track of the unresolved
> > > plugins?
> > >
> > > Could you give more details about the concept of
DynamicExtensionPoint?
> > >
> > > HTH
> > >
> > > PaScaL
> > >
> > >
> >
>
>
org.eclipse.core.registry.ui plugin [message #28404 is a reply to message #23853] Wed, 09 July 2003 21:05 Go to previous message
Keith Kimball is currently offline Keith KimballFriend
Messages: 22
Registered: July 2009
Junior Member
I recently created a plugin called 'org.eclipse.core.registry.ui' in the
DynamicPlugins branch. It presents 3 checkbox plugin lists (Resolved,
Unresolved, and Disabled) and 2 buttons (enable and disable). The only
implemented transformation is unresolved->disabled.
Previous Topic:Re: [OSGi] practices with the bundle context
Next Topic:OSGi: about import
Goto Forum:
  


Current Time: Thu Mar 28 13:38:47 GMT 2024

Powered by FUDForum. Page generated in 0.04047 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top