[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Dynamic Loading/Unloading of Plugins (was: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted)
|
Christophe,
Well, I'm not aware of a doc that refers to loading/unloading specifically. JMX is a specification that focuses on instrumentation of networked components, and it, like many Java Specifications, has a limited focus, with few implementation details described in the specification. It has noetheless become apparent to some that JMX is useful as a "backbone" for a modular plugin architecture.
I'm copying the JBoss development list on this thread, as there are a lot of JMX implementors there that could give more insight on the loading/unloading mechanism. Perhaps one of them knows about a concise document that explains the process?
You might be interested in the following short description of JBoss/JMX which mentions classloading. The book mentioned on this page is also an excellent resource.
http://jboss.org/developers/projects/jboss/jbossmx.jsp
A more lengthy (but helpful) read is the JMX Specification itself.
http://java.sun.com/products/JavaManagement/download.html
The following developerworks articles don't really discuss loading, but I found them useful in evaluating JMX.
http://www-106.ibm.com/developerworks/java/library/j-jmx1/
The reason I think of JBoss/JMX is its deploy folder. Drop in a module, and the server loads it automagically. Delete the module, and the server unloads it. Everything is configured with XML. It seems to me that this might be where Eclipse wants to go in terms of dynamic loading/unloading.
- Matt
-----Original Message-----
From: celek@xxxxxxxxxx [mailto:celek@xxxxxxxxxx]
Sent: Fri 12/20/2002 4:03 PM
To: eclipse-dev@xxxxxxxxxxx
Cc:
Subject: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted
Ed,
I see the following item in the list: Allow plug-in deactivation. Not sure
how far we can go
Matt,
Can you point us to some short-concise JMX doc about loading/unloading ?
I want to know how far the Update Manager can reuse some of the techniques
Christophe Elek
Eclipse Platform - IBM Toronto Lab.
(905) 413-3467
Friday, December 20, 2002 4:09 PM
To: <eclipse-dev@xxxxxxxxxxx>
cc:
From: "Matt Munz" <mmunz@xxxxxxxxxx>
Subject: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted
Ed & eclipse-dev,
> One item that I think should be on the 2.2 plan is dynamic loading and
unloading of Eclipse plugins...
Is there any interest in using Java Management eXtensions and/or the JBoss
microkernel for this purpose?
It seems to me that the differences between server-side dynamic module
loading and client side dynamic module loading are few, if any.
Based on my experience with Eclipse and JBoss I see a lot of similarities
in architecture and approach. JMX is also generally gaining acceptance,
and comes with a lot of useful features beyond dynamic loading.
- Matt
-----Original Message-----
From: Ed Burnette [mailto:Ed.Burnette@xxxxxxx]
Sent: Friday, December 20, 2002 3:23 PM
To: eclipse-dev@xxxxxxxxxxx
Subject: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted
One item that I think should be on the 2.2 plan is dynamic loading and
unloading of Eclipse plugins. This would allow the user to install and
uninstall features and plugins without restarting Eclipse. Currently
Eclipse exits with a special return code and the native Eclipse executable
re-invokes the java part. If there's not currently an open feature request
on this (I didn't find one on a search) I'll be happy to open one. Thanks.
> -----Original Message-----
> From: John Wiegand [mailto:John_Wiegand@xxxxxxx]
> Sent: Friday, December 20, 2002 1:06 PM
> To: eclipse-dev@xxxxxxxxxxx
> Subject: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted
>
>
> The initial draft of the Eclipse 2.2 plan is available for review at
> http://www.eclipse.org/eclipse/development/eclipse_project_pla
> n_2_2.html.
>
> ...
> Please send comments about this draft plan to the
> eclipse-dev@xxxxxxxxxxx
> developer mailing list. We will be reviewing your feedback in the new
> year.
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/eclipse-dev
<<winmail.dat>>