Home » Eclipse Projects » Equinox » How are dependent plugins handled with unloading/reloading?
| How are dependent plugins handled with unloading/reloading? [message #16729] |
Fri, 28 March 2003 17:15  |
Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Hi am curious, if a plugin is unloaded or reloaded at runtime, how are all
dependent plugins treated? Do they all get unloaded by the engine, then
reloaded and reconnected when the requested reload operation is completed?
Or do they just sit idle, hoping that events or what have you do not come to
them that require their code to work with a plugin that may be in the middle
of a reload (or might have been unloaded completely)?
My initial assumption is that somehow the engine must "pause" or completely
unload all dependent plugins as well. My concern here if it is done in this
manner is the time to reload a single plugin could be noticeable. However, I
guess the question to be asked is, how often is any plugin reloaded at
runtime anyway? I can't think of any application, other than perhaps an
application during development/debug cycles, that would require plugins to
be reloaded at runtime, with the exception of an application that may check
for updates via a menu item click or button click, and if found, would
auto-reload the new version of the plugin. In most apps, like Photoshop, 3D
applications, even Eclipse, the most common place to reload a plugin is
actually at the start of the app, where it may load the plugin the first
time if a new version exists. I really don't see a strong need for reloading
during an application execution.
|
|
| |
| Re: How are dependent plugins handled with unloading/reloading? [message #17642 is a reply to message #16729] |
Mon, 31 March 2003 11:24  |
| Eclipse User |
|
|
|
Kevin wrote:
> Hi am curious, if a plugin is unloaded or reloaded at runtime, how are all
> dependent plugins treated? Do they all get unloaded by the engine, then
> reloaded and reconnected when the requested reload operation is completed?
> Or do they just sit idle, hoping that events or what have you do not come to
> them that require their code to work with a plugin that may be in the middle
> of a reload (or might have been unloaded completely)?
>
It kind of depends on the nature of the dependency. If the dependency
is based on class visibility, like so:
SomePlugin p = (SomePlugin)Platform.getPlugin("some.plugin.id");
p.someMethod();
Then if the SomePlugin class gets unloaded and reloaded, the above code
will no longer be valid and would also have to be reloaded. If the
dependency is indirect and only through platform API's:
Plugin p = Platform.getPlugin("some.plugin.id");
p.setDebugging(true);
Then this code MAY be decoupled, so long a it doesn't try to statefully
retain the reference 'p'. I.E., 'p' should be a local (method)
variable and never stored in a class or instance variable. A way of
working around that limitation is to use the Observer pattern to notify
dependents via events that SomePlugin is about to be unloaded. An event
listener callback method could then be used to release (nullify) any
instance or class references to the plugin (or any class provided by the
plugin). Another alternative is to write your code ready and willing to
deal with ClassDefNotFound and NullPointerExceptions. :-) Not a bad
idea in general, really.
> My initial assumption is that somehow the engine must "pause" or completely
> unload all dependent plugins as well. My concern here if it is done in this
> manner is the time to reload a single plugin could be noticeable. However, I
> guess the question to be asked is, how often is any plugin reloaded at
> runtime anyway? I can't think of any application, other than perhaps an
> application during development/debug cycles, that would require plugins to
> be reloaded at runtime, with the exception of an application that may check
> for updates via a menu item click or button click, and if found, would
> auto-reload the new version of the plugin. In most apps, like Photoshop, 3D
> applications, even Eclipse, the most common place to reload a plugin is
> actually at the start of the app, where it may load the plugin the first
> time if a new version exists. I really don't see a strong need for reloading
> during an application execution.
>
My group has a very very strong interest in the ability to add/remove
functionality during runtime with varying degrees of integration. I'm
not sure I want to or should get into the specifics of our particular
use cases. However, consider the analogy to broadly-purposed
application platforms such as a web-browser, which can run a variety of
independent thin-client applications (html pages, javascript, applets,
flash) that are loaded/unloaded/reloaded independent of each other, yet
still gain additional utility through consistency of the platform and at
least a thin layer of integration. Perhaps a better example might be
Lotus' Notes, which provides a vehicle for the deployment of a great
variety of much richer, full-featured (thick) applications that can be
added/removed from the user's environment yet still have a high level of
consistency and integration.
Mel
|
|
| |
| Re: How are dependent plugins handled with unloading/reloading? [message #18462 is a reply to message #17642] |
Mon, 31 March 2003 16:05 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Mel,
You hit it right on the nose with your reply. What you wrote is exactly what
I was thinking. Either every plugin that depends on another must listen for
a notification that the plugin it depends on may be deactivated, unloaded,
reloaded, etc, OR, you have to code for it with a bunch of checks, making
sure a reference to a plugin is not null before doing anything with it. On
the thought of making SomePlugin a local variable, I agree and disagree. I
can see arguments for and against this, in that, if many methods of a plugin
call upon a dependent plugin, and let's even go as far as saying one method
may be called a LOT quickly, then every call to any method using the plugin
takes up time by making several method calls just to get the ref to the
plugin they wish to work with. There is the one call to get the ref, and
internally you know the engine is doing lookup to find the plugin, probably
via internal method calls, and so forth. So my biggest concern with the
approach of always using the dependent plugin ref as a local variable is
speed. On the flip side, you NEVER have to worry about
unload/reload/deactivated issues. You simply get the ref, and if its null,
don't use it.
I don't know a lot about OSGi, or much about Eclipse (although more than
OSGi), but a few things I read here suggest that OSGi works in the way of
services, where by a plugin requests a dependent plugin and has to code for
the possibility that the dependent plugin service is not available. To me,
in order to support unload/reload/deactivate capabilities, EVERY plugin
should be coded in this manner, always prepared for the worse case. I also
think there should be the option to "lock" a plugin from ever unloading or
being deactivated. There may be times where "core" plugins must be available
at all times and could have many, if not all other plugins depend on them.
To unload or deactivate a core plugin would basically be like restarting the
application, only a bit faster because you are not shutting down the JVM and
restarting it, you are simply unloading all plugins, then reloading them. I
do believe this is ok though, so long as plugin developers are aware of what
may happen. I also think any application that uses a plugin engine to allow
reloadable core plugins is not designing very well. Whatever name is given
to them, the idea is that core plugins are crucial to the application, and
should most likely not be unloaded/reloaded at runtime. That said, I also
think the engine, for flexibilitie's sake, should still allow ANY plugin to
be reloaded, and either the notification sent to all dependent plugins, OR
the engine automatically just deactivates those plugins, reloads the plugin
they depend on, then activates them again. I think this is indeed possible.
If plugin A depends on B, and b gets reloaded, the engine should deactivate
A. So what happens if plugin C depends on A? Well, when A receives notice
that it is deactivating, C should also receive notice, and so on up the
chain of ALL dependent plugins. Upon reactivation, each plugin would have to
get its dependent plugin refs again possibly.
Lastly, I like your idea of a single application that allows "pluggable"
applications for the sake of integration. I am working on a pluggable
internet suite of apps, where by the email plugin, ftp plugin, irc plugin,
newsgroup plugin and so forth can all share a common platform to run under,
copy/paste is more seamlessly integrated, they can share the same
"addresses" so to speak, the same internet connection and so forth. My goal
is to create a complete Java internet suite of apps that would work on
Windows, Mac, Linux, Unix, etc. I know, there are plenty of
shareware/freeware/open-source projects out there. Well, one of my main
reasons for creating my own plugin engine from over a year ago is I like the
ability to architect and change things to the way I like them. The concept
of open-source is great, but to me plugins are the golden ingredients. Being
able to plug in my own email application that I wrote and use it and fix/add
to it as I see fit is better to me than hoping some change I added gets
accepted and committed to a project. Not that this is bad, open-source is
great. I just think I like the notion of adding in my own ideas rather than
hoping they'll get committed.
So here is a bit of thought, for anyone reading this. Maybe I just don't
know enough about OS's, but to me, it seems a tiny little "core" OS that is
nothing more than a plugin engine would provide the golden OS. That is, make
a tiny plugin engine core, that can then load plugins dynamically,
unload/reload them at will, like what we are discussing. Only, instead of
loading all fonts, print drivers, video card drivers, it only loads those
needed. I for the life of me can't see why Win2K requires SOOO much memory
to load, or OSX for that matter. And, I for the life of me can't figure out
why it is so difficult to configure these things. Sure, I agree that core
level stuff like the HAL, device drivers for things like ports, keyboards,
etc should be loaded to some extent. But do I really need to support 200
different kinds of mice and 80 keyboards? No, I have only one of each. Do I
really care to support the VGA mode I'll never use again because my video
card supports DVI? No! So why load it? To me, this stuff should be loaded
ONLY if its needed, not "just in case". If I had the nohow, I would love to
write an OS like this, because to me, this is the OS that could run on any
platform and easily be ported for most hardware, including set top boxes,
PDA's, etc. Well, just a thought provocation! I am sure there is a LOT I
don't know about how these things work. I would just love to start doing
something like this one day, but I am sure the most common question (and
reason for lack of acceptance) would be "Why another OS? We have plenty". My
thought is, build it around the Linux core, but find a way to avoid the long
boot up times and all those modules loading. I also love the idea of the OS
having a GUI layer plugin added, rather than always there. I think MS is
really missing the boat (and OSX as well) by not allowing a "scaled back"
version of their OS that has remote GUI admin capabilities that don't
require the entire GUI subsystem to be loaded. If the only thing I need
Win2K for is to run a web server, why do I need the tons of memory eating up
by the GUI layer? Just give me the HAL and a few things I need to run my
J2EE server damn it!
Ok, enough of rambling.
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:b69psn$kb0$1@rogue.oti.com...
> Kevin wrote:
> > Hi am curious, if a plugin is unloaded or reloaded at runtime, how are
all
> > dependent plugins treated? Do they all get unloaded by the engine, then
> > reloaded and reconnected when the requested reload operation is
completed?
> > Or do they just sit idle, hoping that events or what have you do not
come to
> > them that require their code to work with a plugin that may be in the
middle
> > of a reload (or might have been unloaded completely)?
> >
>
> It kind of depends on the nature of the dependency. If the dependency
> is based on class visibility, like so:
>
> SomePlugin p = (SomePlugin)Platform.getPlugin("some.plugin.id");
> p.someMethod();
>
> Then if the SomePlugin class gets unloaded and reloaded, the above code
> will no longer be valid and would also have to be reloaded. If the
> dependency is indirect and only through platform API's:
>
> Plugin p = Platform.getPlugin("some.plugin.id");
> p.setDebugging(true);
>
> Then this code MAY be decoupled, so long a it doesn't try to statefully
> retain the reference 'p'. I.E., 'p' should be a local (method)
> variable and never stored in a class or instance variable. A way of
> working around that limitation is to use the Observer pattern to notify
> dependents via events that SomePlugin is about to be unloaded. An event
> listener callback method could then be used to release (nullify) any
> instance or class references to the plugin (or any class provided by the
> plugin). Another alternative is to write your code ready and willing to
> deal with ClassDefNotFound and NullPointerExceptions. :-) Not a bad
> idea in general, really.
>
> > My initial assumption is that somehow the engine must "pause" or
completely
> > unload all dependent plugins as well. My concern here if it is done in
this
> > manner is the time to reload a single plugin could be noticeable.
However, I
> > guess the question to be asked is, how often is any plugin reloaded at
> > runtime anyway? I can't think of any application, other than perhaps an
> > application during development/debug cycles, that would require plugins
to
> > be reloaded at runtime, with the exception of an application that may
check
> > for updates via a menu item click or button click, and if found, would
> > auto-reload the new version of the plugin. In most apps, like Photoshop,
3D
> > applications, even Eclipse, the most common place to reload a plugin is
> > actually at the start of the app, where it may load the plugin the first
> > time if a new version exists. I really don't see a strong need for
reloading
> > during an application execution.
> >
>
> My group has a very very strong interest in the ability to add/remove
> functionality during runtime with varying degrees of integration. I'm
> not sure I want to or should get into the specifics of our particular
> use cases. However, consider the analogy to broadly-purposed
> application platforms such as a web-browser, which can run a variety of
> independent thin-client applications (html pages, javascript, applets,
> flash) that are loaded/unloaded/reloaded independent of each other, yet
> still gain additional utility through consistency of the platform and at
> least a thin layer of integration. Perhaps a better example might be
> Lotus' Notes, which provides a vehicle for the deployment of a great
> variety of much richer, full-featured (thick) applications that can be
> added/removed from the user's environment yet still have a high level of
> consistency and integration.
>
> Mel
>
|
|
|
| Re: How are dependent plugins handled with unloading/reloading? [message #18546 is a reply to message #17642] |
Tue, 01 April 2003 02:15 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
In the current context, we are discussing dynamic plugins and their
registry.
I'd like to point out that in the OSGi we found the registry model also
-very- applicable for many other patterns. In our case, devices that are
discovered in the outside world are also registered in the service
registry. We discovered the "white board approach" which is the model
where you just register an object in the register in the hope somebody
picks it up and can do something useful with it. This approach has been
VERY succesful so maybe we can keep in mind that a general registry has
many advantages.
Another thing we learned in OSGi is that tracking those plugins
(services) can be painful. We therefore included a ServiceTracker
utility in R2 that makes handling this dynamic aspect quite easy.
In this thread there is a discussion of locking a service in memory. We
discussed this extensively in OSGi and decided against that because it
is extremely deadlock prone. We accept the fact that there is a failure
mode in a short window where a service can become stale. With Java and
the exception model I think this is acceptable (it is not like C where
there would be a core dump).
As a last point, I think we should realize that the dynamic plugins are
VERY different beasts than static. I think it is important to fully
support the current model in Equinox but offer a new, more dynamic,
model. One will have to rewrite (part of) its plugin when supporting or
taking advantage of the dynamics.
Kind regards,
Peter Kriens
Mel Martinez wrote:
> Kevin wrote:
>
>> Hi am curious, if a plugin is unloaded or reloaded at runtime, how are
>> all
>> dependent plugins treated? Do they all get unloaded by the engine, then
>> reloaded and reconnected when the requested reload operation is
>> completed?
>> Or do they just sit idle, hoping that events or what have you do not
>> come to
>> them that require their code to work with a plugin that may be in the
>> middle
>> of a reload (or might have been unloaded completely)?
>>
>
> It kind of depends on the nature of the dependency. If the dependency
> is based on class visibility, like so:
>
> SomePlugin p = (SomePlugin)Platform.getPlugin("some.plugin.id");
> p.someMethod();
>
> Then if the SomePlugin class gets unloaded and reloaded, the above code
> will no longer be valid and would also have to be reloaded. If the
> dependency is indirect and only through platform API's:
>
> Plugin p = Platform.getPlugin("some.plugin.id");
> p.setDebugging(true);
>
> Then this code MAY be decoupled, so long a it doesn't try to statefully
> retain the reference 'p'. I.E., 'p' should be a local (method)
> variable and never stored in a class or instance variable. A way of
> working around that limitation is to use the Observer pattern to notify
> dependents via events that SomePlugin is about to be unloaded. An event
> listener callback method could then be used to release (nullify) any
> instance or class references to the plugin (or any class provided by the
> plugin). Another alternative is to write your code ready and willing to
> deal with ClassDefNotFound and NullPointerExceptions. :-) Not a bad
> idea in general, really.
>
>> My initial assumption is that somehow the engine must "pause" or
>> completely
>> unload all dependent plugins as well. My concern here if it is done in
>> this
>> manner is the time to reload a single plugin could be noticeable.
>> However, I
>> guess the question to be asked is, how often is any plugin reloaded at
>> runtime anyway? I can't think of any application, other than perhaps an
>> application during development/debug cycles, that would require
>> plugins to
>> be reloaded at runtime, with the exception of an application that may
>> check
>> for updates via a menu item click or button click, and if found, would
>> auto-reload the new version of the plugin. In most apps, like
>> Photoshop, 3D
>> applications, even Eclipse, the most common place to reload a plugin is
>> actually at the start of the app, where it may load the plugin the first
>> time if a new version exists. I really don't see a strong need for
>> reloading
>> during an application execution.
>>
>
> My group has a very very strong interest in the ability to add/remove
> functionality during runtime with varying degrees of integration. I'm
> not sure I want to or should get into the specifics of our particular
> use cases. However, consider the analogy to broadly-purposed
> application platforms such as a web-browser, which can run a variety of
> independent thin-client applications (html pages, javascript, applets,
> flash) that are loaded/unloaded/reloaded independent of each other, yet
> still gain additional utility through consistency of the platform and at
> least a thin layer of integration. Perhaps a better example might be
> Lotus' Notes, which provides a vehicle for the deployment of a great
> variety of much richer, full-featured (thick) applications that can be
> added/removed from the user's environment yet still have a high level of
> consistency and integration.
>
> Mel
>
|
|
|
| Re: How are dependent plugins handled with unloading/reloading? [message #19417 is a reply to message #18546] |
Wed, 02 April 2003 09:16 |
| Eclipse User |
|
|
|
Originally posted by: d3l3t3-heavy-n0spam.ungoverned.org
I am in agreement with Peter.
Dynamic plugins (or services in the case of OSGi) have unique
characteristics and provide very interesting capabilities. This is the
sole point of my current research work. Whether Eclipse needs these
capabilities is open for debate, I suppose, but my goal is to create an
application framework where nearly all functionality is through
dynamically available building blocks...this means that they can come
and go at any time.
Peter points out the OSGi Service Tracker, but we have pushed that
notion considerably further with our Service Binder (gravity.sf.net),
which automatically manages most aspects of dynamic service
dependencies. So, it is possible using such techniques to limit some of
the complexity associated with developing applications out of
dynamically available building blocks.
-> richard
pkriens wrote:
> In the current context, we are discussing dynamic plugins and their
> registry.
>
> I'd like to point out that in the OSGi we found the registry model also
> -very- applicable for many other patterns. In our case, devices that are
> discovered in the outside world are also registered in the service
> registry. We discovered the "white board approach" which is the model
> where you just register an object in the register in the hope somebody
> picks it up and can do something useful with it. This approach has been
> VERY succesful so maybe we can keep in mind that a general registry has
> many advantages.
>
> Another thing we learned in OSGi is that tracking those plugins
> (services) can be painful. We therefore included a ServiceTracker
> utility in R2 that makes handling this dynamic aspect quite easy.
>
> In this thread there is a discussion of locking a service in memory. We
> discussed this extensively in OSGi and decided against that because it
> is extremely deadlock prone. We accept the fact that there is a failure
> mode in a short window where a service can become stale. With Java and
> the exception model I think this is acceptable (it is not like C where
> there would be a core dump).
>
> As a last point, I think we should realize that the dynamic plugins are
> VERY different beasts than static. I think it is important to fully
> support the current model in Equinox but offer a new, more dynamic,
> model. One will have to rewrite (part of) its plugin when supporting or
> taking advantage of the dynamics.
>
> Kind regards,
>
> Peter Kriens
>
> Mel Martinez wrote:
>
>> Kevin wrote:
>>
>>> Hi am curious, if a plugin is unloaded or reloaded at runtime, how
>>> are all
>>> dependent plugins treated? Do they all get unloaded by the engine, then
>>> reloaded and reconnected when the requested reload operation is
>>> completed?
>>> Or do they just sit idle, hoping that events or what have you do not
>>> come to
>>> them that require their code to work with a plugin that may be in the
>>> middle
>>> of a reload (or might have been unloaded completely)?
>>>
>>
>> It kind of depends on the nature of the dependency. If the dependency
>> is based on class visibility, like so:
>>
>> SomePlugin p = (SomePlugin)Platform.getPlugin("some.plugin.id");
>> p.someMethod();
>>
>> Then if the SomePlugin class gets unloaded and reloaded, the above
>> code will no longer be valid and would also have to be reloaded. If
>> the dependency is indirect and only through platform API's:
>>
>> Plugin p = Platform.getPlugin("some.plugin.id");
>> p.setDebugging(true);
>>
>> Then this code MAY be decoupled, so long a it doesn't try to
>> statefully retain the reference 'p'. I.E., 'p' should be a local
>> (method) variable and never stored in a class or instance variable. A
>> way of working around that limitation is to use the Observer pattern
>> to notify dependents via events that SomePlugin is about to be
>> unloaded. An event listener callback method could then be used to
>> release (nullify) any instance or class references to the plugin (or
>> any class provided by the plugin). Another alternative is to write
>> your code ready and willing to deal with ClassDefNotFound and
>> NullPointerExceptions. :-) Not a bad idea in general, really.
>>
>>> My initial assumption is that somehow the engine must "pause" or
>>> completely
>>> unload all dependent plugins as well. My concern here if it is done
>>> in this
>>> manner is the time to reload a single plugin could be noticeable.
>>> However, I
>>> guess the question to be asked is, how often is any plugin reloaded at
>>> runtime anyway? I can't think of any application, other than perhaps an
>>> application during development/debug cycles, that would require
>>> plugins to
>>> be reloaded at runtime, with the exception of an application that may
>>> check
>>> for updates via a menu item click or button click, and if found, would
>>> auto-reload the new version of the plugin. In most apps, like
>>> Photoshop, 3D
>>> applications, even Eclipse, the most common place to reload a plugin is
>>> actually at the start of the app, where it may load the plugin the first
>>> time if a new version exists. I really don't see a strong need for
>>> reloading
>>> during an application execution.
>>>
>>
>> My group has a very very strong interest in the ability to add/remove
>> functionality during runtime with varying degrees of integration. I'm
>> not sure I want to or should get into the specifics of our particular
>> use cases. However, consider the analogy to broadly-purposed
>> application platforms such as a web-browser, which can run a variety
>> of independent thin-client applications (html pages, javascript,
>> applets, flash) that are loaded/unloaded/reloaded independent of each
>> other, yet still gain additional utility through consistency of the
>> platform and at least a thin layer of integration. Perhaps a better
>> example might be Lotus' Notes, which provides a vehicle for the
>> deployment of a great variety of much richer, full-featured (thick)
>> applications that can be added/removed from the user's environment yet
>> still have a high level of consistency and integration.
>>
>> Mel
>>
>
|
|
|
| Re: How are dependent plugins handled with unloading/reloading? [message #23199 is a reply to message #17642] |
Thu, 17 April 2003 12:52 |
| Eclipse User |
|
|
|
Originally posted by: wegener.cboenospam.com
Mel Martinez wrote:
> Kevin wrote:
> > Hi am curious, if a plugin is unloaded or reloaded at runtime, how are all
> > dependent plugins treated? Do they all get unloaded by the engine, then
> > reloaded and reconnected when the requested reload operation is completed?
> > Or do they just sit idle, hoping that events or what have you do not come
to
> > them that require their code to work with a plugin that may be in the
middle
> > of a reload (or might have been unloaded completely)?
> >
One possible way to deal with this would be to have the plugin object that
gets returned be a wrapper around the actual plugin. The wrapper would
intercept all method calls and perform a check to see if the real plugin
has been reloaded. The major problem with this method would be that the
platform would need to generate a class that subclasses the original
plugin with the specialized public methods. This would not be possible if
the original plugin class was defined as final.
Other more subtle problems could involve the mysterious changing of state
of the original plugin. If the client of the plugin registered for a
callback on the initial plugin instance, the reloaded instance would
likely loose the registration.
> It kind of depends on the nature of the dependency. If the dependency
> is based on class visibility, like so:
> SomePlugin p = (SomePlugin)Platform.getPlugin("some.plugin.id");
> p.someMethod();
> Then if the SomePlugin class gets unloaded and reloaded, the above code
> will no longer be valid and would also have to be reloaded. If the
> dependency is indirect and only through platform API's:
> Plugin p = Platform.getPlugin("some.plugin.id");
> p.setDebugging(true);
> Then this code MAY be decoupled, so long a it doesn't try to statefully
> retain the reference 'p'. I.E., 'p' should be a local (method)
> variable and never stored in a class or instance variable. A way of
> working around that limitation is to use the Observer pattern to notify
> dependents via events that SomePlugin is about to be unloaded. An event
> listener callback method could then be used to release (nullify) any
> instance or class references to the plugin (or any class provided by the
> plugin). Another alternative is to write your code ready and willing to
> deal with ClassDefNotFound and NullPointerExceptions. :-) Not a bad
> idea in general, really.
> > My initial assumption is that somehow the engine must "pause" or completely
> > unload all dependent plugins as well. My concern here if it is done in this
> > manner is the time to reload a single plugin could be noticeable. However,
I
> > guess the question to be asked is, how often is any plugin reloaded at
> > runtime anyway? I can't think of any application, other than perhaps an
> > application during development/debug cycles, that would require plugins to
> > be reloaded at runtime, with the exception of an application that may check
> > for updates via a menu item click or button click, and if found, would
> > auto-reload the new version of the plugin. In most apps, like Photoshop, 3D
> > applications, even Eclipse, the most common place to reload a plugin is
> > actually at the start of the app, where it may load the plugin the first
> > time if a new version exists. I really don't see a strong need for
reloading
> > during an application execution.
> >
> My group has a very very strong interest in the ability to add/remove
> functionality during runtime with varying degrees of integration. I'm
> not sure I want to or should get into the specifics of our particular
> use cases. However, consider the analogy to broadly-purposed
> application platforms such as a web-browser, which can run a variety of
> independent thin-client applications (html pages, javascript, applets,
> flash) that are loaded/unloaded/reloaded independent of each other, yet
> still gain additional utility through consistency of the platform and at
> least a thin layer of integration. Perhaps a better example might be
> Lotus' Notes, which provides a vehicle for the deployment of a great
> variety of much richer, full-featured (thick) applications that can be
> added/removed from the user's environment yet still have a high level of
> consistency and integration.
> Mel
|
|
|
| Re: How are dependent plugins handled with unloading/reloading? [message #23227 is a reply to message #23199] |
Fri, 18 April 2003 15:22 |
| Eclipse User |
|
|
|
Dave Wegener wrote:
>
>>Kevin wrote:
>>
>>>Hi am curious, if a plugin is unloaded or reloaded at runtime, how are all
>>>dependent plugins treated? Do they all get unloaded by the engine, then
>>>reloaded and reconnected when the requested reload operation is completed?
>>>Or do they just sit idle, hoping that events or what have you do not come
>>>to them that require their code to work with a plugin that may be in the
>>>middle of a reload (or might have been unloaded completely)?
>>>
>
> One possible way to deal with this would be to have the plugin object that
> gets returned be a wrapper around the actual plugin. The wrapper would
> intercept all method calls and perform a check to see if the real plugin
> has been reloaded. The major problem with this method would be that the
> platform would need to generate a class that subclasses the original
> plugin with the specialized public methods. This would not be possible if
> the original plugin class was defined as final.
Actually this is possible using the java.lang.reflect.Proxy class and
the Decorator pattern. So long as all the methods of the target are
available through interfaces, you can simply drop the target inside a
Proxy object created using all the relevant interfaces. The result is
an object that passes the 'instanceof' test for those interfaces.
Method calls to those interfaces get mapped to an 'executeMethod()'
method provided by the Proxy class that you (the developer) override to
do what you will. Typically, if the method is implemented by the
target, you might pass it straight through (this is the simple Proxy
pattern). You also might do some preprocessing before passing it on to
the target. The really cool thing is that you can also handle methods
that don't exist in the target, in effect 'extending' the original
target's class whether it was declared final or not (note that you of
course do not have access to protected internals, though). This is the
decorator pattern. Finally, you can actually map different method calls
to multiple targets, hiding complex delegations and interactions behind
one object. This is the Facade pattern.
I've used the Proxy class a lot. It's a very powerful tool that was
added in java 1.3.
>
> Other more subtle problems could involve the mysterious changing of state
> of the original plugin. If the client of the plugin registered for a
> callback on the initial plugin instance, the reloaded instance would
> likely loose the registration.
>
It depends on how the callback registration is maintained. If it is
maintained as a stateful, heavyweight reference to the callback target,
then yes, that would be a problem. If it is maintained in a
lightweight, indirect manner such as by index in a registry, then if the
registry is updated the plugin that is keeping the index for purposes of
a callback should still be able to use that index to make the callback
against whatever currently is registered under that index.
|
|
|
| Re: How are dependent plugins handled with unloading/reloading? [message #23595 is a reply to message #23227] |
Sat, 26 April 2003 10:23 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Mel Martinez wrote:
> Actually this is possible using the java.lang.reflect.Proxy class and
> the Decorator pattern.
It also incorporates a significant performance overhead ...
Kind regards,
Peter Kriens
So long as all the methods of the target are
> available through interfaces, you can simply drop the target inside a
> Proxy object created using all the relevant interfaces. The result is
> an object that passes the 'instanceof' test for those interfaces. Method
> calls to those interfaces get mapped to an 'executeMethod()' method
> provided by the Proxy class that you (the developer) override to do what
> you will. Typically, if the method is implemented by the target, you
> might pass it straight through (this is the simple Proxy pattern). You
> also might do some preprocessing before passing it on to the target.
> The really cool thing is that you can also handle methods that don't
> exist in the target, in effect 'extending' the original target's class
> whether it was declared final or not (note that you of course do not
> have access to protected internals, though). This is the decorator
> pattern. Finally, you can actually map different method calls to
> multiple targets, hiding complex delegations and interactions behind one
> object. This is the Facade pattern.
>
> I've used the Proxy class a lot. It's a very powerful tool that was
> added in java 1.3.
>
>>
>> Other more subtle problems could involve the mysterious changing of state
>> of the original plugin. If the client of the plugin registered for a
>> callback on the initial plugin instance, the reloaded instance would
>> likely loose the registration.
>>
>
> It depends on how the callback registration is maintained. If it is
> maintained as a stateful, heavyweight reference to the callback target,
> then yes, that would be a problem. If it is maintained in a
> lightweight, indirect manner such as by index in a registry, then if the
> registry is updated the plugin that is keeping the index for purposes of
> a callback should still be able to use that index to make the callback
> against whatever currently is registered under that index.
>
>
>
>
>
|
|
|
| Re: How are dependent plugins handled with unloading/reloading? [message #23810 is a reply to message #23595] |
Wed, 30 April 2003 16:14 |
| Eclipse User |
|
|
|
This goes off topic, but the main performance hit is for proxy class
creation. Once you've created (and cached) the class, the overhead
during actual execution for the method intercept is not really that
high, at least not with recent JRE's from sun. It is also possible to
reuse the same proxy object for multiple targets so one can even avoid
creating new proxy objects for each target. If the executeMethod does
nothing but pass through, then the overhead is just a couple of
pass-through method invocations. This penalty is generally pretty tiny
compared to other considerations (especially if remote calls are
involved). Anything overhead beyond that depends entirely on what you
want to do at the intercept point.
Everything is relative, of course, and I would never suggest that it is
a non-existent penalty. This overhead may be way too much for some
applications. It is just another tool in the toolbox.
Cheers,
Mel
pkriens wrote:
>
>
> Mel Martinez wrote:
>
>> Actually this is possible using the java.lang.reflect.Proxy class and
>> the Decorator pattern.
>
>
> It also incorporates a significant performance overhead ...
>
> Kind regards,
>
> Peter Kriens
>
>
> So long as all the methods of the target are
>
>> available through interfaces, you can simply drop the target inside a
>> Proxy object created using all the relevant interfaces. The result is
>> an object that passes the 'instanceof' test for those interfaces.
>> Method calls to those interfaces get mapped to an 'executeMethod()'
>> method provided by the Proxy class that you (the developer) override
>> to do what you will. Typically, if the method is implemented by the
>> target, you might pass it straight through (this is the simple Proxy
>> pattern). You also might do some preprocessing before passing it on
>> to the target. The really cool thing is that you can also handle
>> methods that don't exist in the target, in effect 'extending' the
>> original target's class whether it was declared final or not (note
>> that you of course do not have access to protected internals,
>> though). This is the decorator pattern. Finally, you can actually
>> map different method calls to multiple targets, hiding complex
>> delegations and interactions behind one object. This is the Facade
>> pattern.
>>
>> I've used the Proxy class a lot. It's a very powerful tool that was
>> added in java 1.3.
>>
>>>
>>> Other more subtle problems could involve the mysterious changing of
>>> state
>>> of the original plugin. If the client of the plugin registered for a
>>> callback on the initial plugin instance, the reloaded instance would
>>> likely loose the registration.
>>>
>>
>> It depends on how the callback registration is maintained. If it is
>> maintained as a stateful, heavyweight reference to the callback
>> target, then yes, that would be a problem. If it is maintained in a
>> lightweight, indirect manner such as by index in a registry, then if
>> the registry is updated the plugin that is keeping the index for
>> purposes of a callback should still be able to use that index to make
>> the callback against whatever currently is registered under that index.
>>
>>
>>
>>
>>
>
|
|
|
Goto Forum:
Current Time: Sun Jun 08 08:57:56 EDT 2025
Powered by FUDForum. Page generated in 0.08429 seconds |
Home