Home » Eclipse Projects » Eclipse Platform » Overriding IExtensionRegistry / IExtensionPoint / IExtension
Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334212] |
Mon, 26 January 2009 19:14 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Are there any articles, examples, or other help for overriding the
default behavior of IExtensionRegistry, IExtensionPoint, and IExtension?
The reason I (think) I want to do this is because we have a requirement
to prevent reading extension contributions from certain plugins, even if
they are installed. In other words, if certain conditions about a plugin
are satisfied, we need to prevent any extensions from that plugin from
being contributed at runtime.
Any pointers?
Thanks in advance,
Eric
|
|
|
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334213 is a reply to message #334212] |
Mon, 26 January 2009 19:06 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
|
Eric Rizzo wrote:
> Are there any articles, examples, or other help for overriding the
> default behavior of IExtensionRegistry, IExtensionPoint, and IExtension?
> The reason I (think) I want to do this is because we have a requirement
> to prevent reading extension contributions from certain plugins, even if
> they are installed. In other words, if certain conditions about a plugin
> are satisfied, we need to prevent any extensions from that plugin from
> being contributed at runtime.
There's always everybody's friend,
http://wiki.eclipse.org/Equinox_Transforms :-) I did confirm recently
that it works, but of course it works by removing the extension
contributions themselves.
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334227 is a reply to message #334213] |
Tue, 27 January 2009 14:49 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 1/26/2009 2:06 PM, Paul Webster wrote:
> Eric Rizzo wrote:
>> Are there any articles, examples, or other help for overriding the
>> default behavior of IExtensionRegistry, IExtensionPoint, and IExtension?
>> The reason I (think) I want to do this is because we have a
>> requirement to prevent reading extension contributions from certain
>> plugins, even if they are installed. In other words, if certain
>> conditions about a plugin are satisfied, we need to prevent any
>> extensions from that plugin from being contributed at runtime.
>
> There's always everybody's friend,
> http://wiki.eclipse.org/Equinox_Transforms :-) I did confirm recently
> that it works, but of course it works by removing the extension
> contributions themselves.
That page mentions that you must alter config.ini in order to have the
transforms invoked. That seems to preclude this option in the scenario
where our plugins are being installed by the user into an existing
Eclipse, doesn't it?
Is there any alternative solution that will work for both an RCP-based
product and features/plugins installed into Eclipse?
Eric
|
|
|
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334238 is a reply to message #334227] |
Wed, 28 January 2009 14:46 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
|
Eric Rizzo wrote:
> That page mentions that you must alter config.ini in order to have the
> transforms invoked. That seems to preclude this option in the scenario
> where our plugins are being installed by the user into an existing
> Eclipse, doesn't it?
Yes, the transforms are the kind of thing you can implement at the
product level, since they are framework extensions and have to live in
the same place as org.eclipse.osgi.
> Is there any alternative solution that will work for both an RCP-based
> product and features/plugins installed into Eclipse?
Not really in the general case. As of 3.4 some specific extensions
(usually UI extensions, view,editor, wizard registries, etc) are set up
so that with the correct org.eclipse.ui.activities.ITriggerPointAdvisor,
expression based activities will not only make it disappear but prevent
the *RegistryReader class from reporting it at all ... but that only
works for readers that are set up to use the restrictUseOf(*) helper,
and only when the tiggerPointAdvisor had been replaced (so RCP again).
If you're not the product, then you can't really interfere with other
plugin contributions.
That being said, you could use a method like
org.eclipse.core.runtime.IExtensionRegistry.removeExtension( IExtension,
Object) to completely hack out an extension ... but even if you've set
the null user-token property (which involves changing startup files) it
looks like you would have to hack internals and use reflection to get
the master token ... and you're off into "unsupported and may change in
any maintenance release"
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334242 is a reply to message #334238] |
Wed, 28 January 2009 18:00 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Paul,
Thanks for the explanations. Some more comments below...
On 1/28/2009 9:46 AM, Paul Webster wrote:
> Eric Rizzo wrote:
>> Is there any alternative solution that will work for both an RCP-based
>> product and features/plugins installed into Eclipse?
>
> Not really in the general case.
> If you're not the product, then you can't really interfere with other
> plugin contributions.
When stated that way, it makes perfect sense that this is difficult, if
not practically impossible, to do as a plug-in.
Let me step back and state the higher level requirement in the hopes
that some other ideas might come up.
We need some of our plugins to be licensed; if the user installs those
plugins but does not have a valid license, we want the contributions of
those plugins to be completely ignored/invisible. I have been able to
prevent the plugins from loading by throwing an exception in the
activator's start() method, but the extension point contributions still
show up in various places, leading to a poor user experience in some cases.
So, given that requirement, is there any alternative solution, other
than trying to override the extension registry? It seems that support
for this would be a general need; obviously other products have rolled
their own solutions (IBM Rational, for example), but when we looked
around for a commercial licensing product that was Eclipse-aware, we did
not find much to choose from. So we picked a general-purpose licensing
vendor and rolled our own Eclipse integration. Obviously, it still falls
short in the area of hiding extension point contributions.
Is there another path I could explore?
Thanks again,
Eric
|
|
| |
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334255 is a reply to message #334245] |
Thu, 29 January 2009 14:44 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 1/28/2009 1:25 PM, Paul Webster wrote:
> I think all of the examples of this I have seen are RCP based (where
> they can control loading). The product customization (equinox
> transforms) is one option, hacking the IExtensionRegistry (via
> reflection, makes my hair stand on end :-) is another. I know that
> plugins like eclipse-jaas (http://eclipse-jaas.sourceforge.net/) also
> prevent unauthorized plugins from loading, although I'm not sure how.
After a brief look at eclipse-jaas, it appear to be an RCP-only
solution. In addition, it requires that "authorization-required" plugins
be located in a separate location than normal ones. So not an option for me.
....But an interesting project to know about, just the same.
> Another potential option that comes to mind is plugin unloading. If you
> can get your license-checking plugin to load right at the startup
> (org.eclipse.ui.startup is one way :-) then you could validate your
> license and simply use Bundle#uninstall() and PackageAdmin to get rid of
> the offending plugins completely (there's some work you would have to do
> if you ever wanted them to come back :-) and leave the exceptions in the
> activators for those that wanted to circumvent your license plugin.
> While work, the advantage is that it is all API.
Isn't Bundle.uninstall() persistent/permanent? What I'd need is to
disable the plugin for only this session - the user might get their
license and restart, in which case the plugin needs to load and run
normally. So wouldn't I just want Bundle.stop() in that case?
If I understand correctly, this idea would involve some code like the
following in a centralized license-checking plugin's start():
List licensedPluginIDs = getAllLicensedPlugins();
for (String pluginID : licensedPluginIDs) {
Bundle plugin = Platform.getBundle(pluginID);
plugin.stop();
}
Does that look correct (more or less)?
Thanks again,
Eric
|
|
|
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334256 is a reply to message #334255] |
Thu, 29 January 2009 15:06 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Danail Nachev![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=d.nachev%40gmail.com) Messages: 110 Registered: July 2009 |
Senior Member |
|
|
The only option for you is to uninstall the bundle, stop won't make
difference to the extension registry.
I think that p2/Update Manager will install your bundle back on each
platform startup, so you can easily get your bundles back if there is a
valid license present. If this is not the case, you can analyze the
initial location of the bundles you are about to remove and install them
when the valid license shows up.
Does this make sense?
Eric Rizzo wrote:
> On 1/28/2009 1:25 PM, Paul Webster wrote:
>> I think all of the examples of this I have seen are RCP based (where
>> they can control loading). The product customization (equinox
>> transforms) is one option, hacking the IExtensionRegistry (via
>> reflection, makes my hair stand on end :-) is another. I know that
>> plugins like eclipse-jaas (http://eclipse-jaas.sourceforge.net/) also
>> prevent unauthorized plugins from loading, although I'm not sure how.
>
> After a brief look at eclipse-jaas, it appear to be an RCP-only
> solution. In addition, it requires that "authorization-required" plugins
> be located in a separate location than normal ones. So not an option for
> me.
> ...But an interesting project to know about, just the same.
>
>> Another potential option that comes to mind is plugin unloading. If you
>> can get your license-checking plugin to load right at the startup
>> (org.eclipse.ui.startup is one way :-) then you could validate your
>> license and simply use Bundle#uninstall() and PackageAdmin to get rid of
>> the offending plugins completely (there's some work you would have to do
>> if you ever wanted them to come back :-) and leave the exceptions in the
>> activators for those that wanted to circumvent your license plugin.
>> While work, the advantage is that it is all API.
>
> Isn't Bundle.uninstall() persistent/permanent? What I'd need is to
> disable the plugin for only this session - the user might get their
> license and restart, in which case the plugin needs to load and run
> normally. So wouldn't I just want Bundle.stop() in that case?
>
>
> If I understand correctly, this idea would involve some code like the
> following in a centralized license-checking plugin's start():
>
> List licensedPluginIDs = getAllLicensedPlugins();
> for (String pluginID : licensedPluginIDs) {
> Bundle plugin = Platform.getBundle(pluginID);
> plugin.stop();
> }
>
>
> Does that look correct (more or less)?
>
> Thanks again,
> Eric
>
|
|
|
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334257 is a reply to message #334255] |
Thu, 29 January 2009 15:01 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
|
Eric Rizzo wrote:
>
> Isn't Bundle.uninstall() persistent/permanent? What I'd need is to
> disable the plugin for only this session - the user might get their
> license and restart, in which case the plugin needs to load and run
> normally. So wouldn't I just want Bundle.stop() in that case?
uninstall() is persistent, that's why you would have to do more work.
For example:
1) start up and check licenses. No license, uninstall those bundles
(save all the bundles' location information in your useful application
state location).
2) start up and check licenses. No license but they're uninstalled, so
nothing
3) start up and check licenses. Granted, so retrieve the uninstalled
bundles and re-install them.
Here, uninstall() isn't physically removing them from wherever they are,
simply telling the system to ignore them :-)
>
> If I understand correctly, this idea would involve some code like the
> following in a centralized license-checking plugin's start():
>
> List licensedPluginIDs = getAllLicensedPlugins();
> for (String pluginID : licensedPluginIDs) {
> Bundle plugin = Platform.getBundle(pluginID);
> plugin.stop();
> }
>
except it would have to be uninstall(). Like start(), stop() doesn't
effect the visibility of plugin.xml contributions (they are visible
before start and after stop).
Oleg might have more suggestions :-)
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334258 is a reply to message #334242] |
Thu, 29 January 2009 15:12 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Oleg Besedin![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=obesedin%40ca.ibm.com) Messages: 41 Registered: July 2009 |
Member |
|
|
Interesting scenario, I don't think there is a pre-canned solution for it.
As Paul said, bundle needs to gets uninstalled to remove its contribution
from the registry (or become unresolved if if depends on some environment
constraints that are not satisfied).
However, I would consider this to be a marketing opportunity :-).
Say, you have a "License manager" plugin. It checks the license, and:
- valid license - installs plugin "RealPlugin" that does the work;
- invalid license - installs plugin "LeadToMyWebsite" that has the same UI
triggers but just says "Buy me" instead of doing the work; uninstalls
"RealPlugin"
Obviously this needs some work. For instance, the RealPlugin in reality will
need to do the license check too or it will be too easy to bypass. I would
also suggest to put "uninstall" action into the marketing plugin to be a
good citizen.
Hope this helps.
Thanks,
Oleg Besedin
"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:glq6gf$sk2$1@build.eclipse.org...
> Paul,
> Thanks for the explanations. Some more comments below...
>
> On 1/28/2009 9:46 AM, Paul Webster wrote:
>> Eric Rizzo wrote:
>>> Is there any alternative solution that will work for both an RCP-based
>>> product and features/plugins installed into Eclipse?
>>
>> Not really in the general case.
>
>> If you're not the product, then you can't really interfere with other
>> plugin contributions.
>
> When stated that way, it makes perfect sense that this is difficult, if
> not practically impossible, to do as a plug-in.
>
> Let me step back and state the higher level requirement in the hopes that
> some other ideas might come up.
> We need some of our plugins to be licensed; if the user installs those
> plugins but does not have a valid license, we want the contributions of
> those plugins to be completely ignored/invisible. I have been able to
> prevent the plugins from loading by throwing an exception in the
> activator's start() method, but the extension point contributions still
> show up in various places, leading to a poor user experience in some
> cases.
> So, given that requirement, is there any alternative solution, other than
> trying to override the extension registry? It seems that support for this
> would be a general need; obviously other products have rolled their own
> solutions (IBM Rational, for example), but when we looked around for a
> commercial licensing product that was Eclipse-aware, we did not find much
> to choose from. So we picked a general-purpose licensing vendor and rolled
> our own Eclipse integration. Obviously, it still falls short in the area
> of hiding extension point contributions.
>
> Is there another path I could explore?
>
> Thanks again,
> Eric
|
|
| |
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334263 is a reply to message #334257] |
Thu, 29 January 2009 19:24 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 1/29/2009 10:01 AM, Paul Webster wrote:
> Eric Rizzo wrote:
>>
>> Isn't Bundle.uninstall() persistent/permanent? What I'd need is to
>> disable the plugin for only this session - the user might get their
>> license and restart, in which case the plugin needs to load and run
>> normally. So wouldn't I just want Bundle.stop() in that case?
>
> uninstall() is persistent, that's why you would have to do more work.
> For example:
>
> 1) start up and check licenses. No license, uninstall those bundles
> (save all the bundles' location information in your useful application
> state location).
>
> 2) start up and check licenses. No license but they're uninstalled, so
> nothing
>
> 3) start up and check licenses. Granted, so retrieve the uninstalled
> bundles and re-install them.
>
> Here, uninstall() isn't physically removing them from wherever they are,
> simply telling the system to ignore them :-)
>
>
>>
>> If I understand correctly, this idea would involve some code like the
>> following in a centralized license-checking plugin's start():
>>
>> List licensedPluginIDs = getAllLicensedPlugins();
>> for (String pluginID : licensedPluginIDs) {
>> Bundle plugin = Platform.getBundle(pluginID);
>> plugin.stop();
>> }
>>
>
> except it would have to be uninstall(). Like start(), stop() doesn't
> effect the visibility of plugin.xml contributions (they are visible
> before start and after stop).
OK, I understand.
So how does one get a reference to the PackageAdmin instance? I looked
around for a way in (and for some platform/JDT/WTP code to mimic), but
could not figure out how to get to it.
Thanks,
Eric
|
|
| | |
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #334359 is a reply to message #334258] |
Wed, 04 February 2009 17:03 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: jacek.pospychala.pl.ibm.com
you can also disable bundle, like it's done by Plug-in registry view:
DisabledInfo info = new DisabledInfo("org.eclipse.pde.ui", "Disabled via
PDE", desc);
PlatformAdmin platformAdmin =
PDERuntimePlugin.getDefault().getPlatformAdmin();
platformAdmin.addDisabledInfo(info);
Also have a look at DisabledInfo javadoc.
Disabling is also persistent, but it's easy to enable them back.
Oleg Besedin pisze:
> Interesting scenario, I don't think there is a pre-canned solution for it.
> As Paul said, bundle needs to gets uninstalled to remove its contribution
> from the registry (or become unresolved if if depends on some environment
> constraints that are not satisfied).
>
> However, I would consider this to be a marketing opportunity :-).
>
> Say, you have a "License manager" plugin. It checks the license, and:
>
> - valid license - installs plugin "RealPlugin" that does the work;
> - invalid license - installs plugin "LeadToMyWebsite" that has the same UI
> triggers but just says "Buy me" instead of doing the work; uninstalls
> "RealPlugin"
>
> Obviously this needs some work. For instance, the RealPlugin in reality will
> need to do the license check too or it will be too easy to bypass. I would
> also suggest to put "uninstall" action into the marketing plugin to be a
> good citizen.
>
> Hope this helps.
>
> Thanks,
> Oleg Besedin
>
> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
> news:glq6gf$sk2$1@build.eclipse.org...
>> Paul,
>> Thanks for the explanations. Some more comments below...
>>
>> On 1/28/2009 9:46 AM, Paul Webster wrote:
>>> Eric Rizzo wrote:
>>>> Is there any alternative solution that will work for both an RCP-based
>>>> product and features/plugins installed into Eclipse?
>>> Not really in the general case.
>>> If you're not the product, then you can't really interfere with other
>>> plugin contributions.
>> When stated that way, it makes perfect sense that this is difficult, if
>> not practically impossible, to do as a plug-in.
>>
>> Let me step back and state the higher level requirement in the hopes that
>> some other ideas might come up.
>> We need some of our plugins to be licensed; if the user installs those
>> plugins but does not have a valid license, we want the contributions of
>> those plugins to be completely ignored/invisible. I have been able to
>> prevent the plugins from loading by throwing an exception in the
>> activator's start() method, but the extension point contributions still
>> show up in various places, leading to a poor user experience in some
>> cases.
>> So, given that requirement, is there any alternative solution, other than
>> trying to override the extension registry? It seems that support for this
>> would be a general need; obviously other products have rolled their own
>> solutions (IBM Rational, for example), but when we looked around for a
>> commercial licensing product that was Eclipse-aware, we did not find much
>> to choose from. So we picked a general-purpose licensing vendor and rolled
>> our own Eclipse integration. Obviously, it still falls short in the area
>> of hiding extension point contributions.
>>
>> Is there another path I could explore?
>>
>> Thanks again,
>> Eric
>
>
|
|
|
Goto Forum:
Current Time: Fri Aug 23 07:16:49 GMT 2024
Powered by FUDForum. Page generated in 0.03716 seconds
|