Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » Overriding IExtensionRegistry / IExtensionPoint / IExtension
Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #125138] Mon, 26 January 2009 19:14 Go to next message
Eclipse UserFriend
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 #125140 is a reply to message #125138] Mon, 26 January 2009 19:06 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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


Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #125149 is a reply to message #125140] Tue, 27 January 2009 14:49 Go to previous messageGo to next message
Eclipse UserFriend
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 #125153 is a reply to message #125149] Wed, 28 January 2009 14:46 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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


Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #125155 is a reply to message #125153] Wed, 28 January 2009 18:00 Go to previous messageGo to next message
Eclipse UserFriend
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 #125156 is a reply to message #125155] Wed, 28 January 2009 18:25 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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.


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.

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


Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #125159 is a reply to message #125156] Thu, 29 January 2009 14:44 Go to previous messageGo to next message
Eclipse UserFriend
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 #125161 is a reply to message #125159] Thu, 29 January 2009 15:06 Go to previous messageGo to next message
Danail Nachev is currently offline Danail NachevFriend
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 #125251 is a reply to message #125159] Thu, 29 January 2009 15:01 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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


Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #125257 is a reply to message #125155] Thu, 29 January 2009 15:12 Go to previous messageGo to next message
Oleg Besedin is currently offline Oleg BesedinFriend
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 #125264 is a reply to message #125251] Thu, 29 January 2009 15:18 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Paul Webster wrote:
>
> 1) start up and check licenses. No license, uninstall those bundles
> (save all the bundles' location information in your useful application
> state location).

A useful bundle location can be found from
org.eclipse.core.runtime.FileLocator.getBundleFile(Bundle)

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


Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #125286 is a reply to message #125251] Thu, 29 January 2009 19:24 Go to previous messageGo to next message
Eclipse UserFriend
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 #125323 is a reply to message #125286] Fri, 30 January 2009 00:03 Go to previous messageGo to next message
Chris Aniszczyk is currently offline Chris AniszczykFriend
Messages: 674
Registered: July 2009
Senior Member
Eric Rizzo wrote:
> 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.

PackageAdmin is just a OSGi service...

We use it in PDE for a couple things. Here's some sample code...

org.eclipse.pde.internal.runtime.PDERuntimePlugin.getPackage Admin()

Cheers,

~ Chris
Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #125334 is a reply to message #125286] Fri, 30 January 2009 13:28 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Eric Rizzo wrote:
> 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.

In addition to Chris' example, there's also
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ui.test s/Eclipse%20UI%20Tests/org/eclipse/ui/tests/dynamicplugins/T estInstallUtil.java?view=co

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


Re: Overriding IExtensionRegistry / IExtensionPoint / IExtension [message #125540 is a reply to message #125257] Wed, 04 February 2009 17:03 Go to previous message
Eclipse UserFriend
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
>
>
Previous Topic:default autostart
Next Topic:Best practice for creating multi-platform update sites?
Goto Forum:
  


Current Time: Tue Mar 19 08:36:26 GMT 2024

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

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

Back to the top