How much of what you are thinking of would be handled by: jmx
jboss service lifecycle jboss mbean dependencies enhanced by including the version as a key in the ObjectName and using queries or filter conditions rather than equality for resolution of dependencies. BTW in jboss 4 clients using the trunk invoker already have jmx client side: others will follow when I get to work on tx propagation for the other transports. david jencks On 2002.12.22 21:35:27 -0500 James Higginbotham wrote: > Funny, I was thinking about this concept the other day, as I still have > delusions of grandjeur to build a rich client application on top of the > Jboss kernel. My thoughts on this were along the lines of the following, > based on a scenario of an upgraded component version (discovered via some > mechanism ala JNLP): > > 1) Module is downloaded into a temporary local location > 2) Existing module is "unloaded" by removing it from the JMX container > 2a) All dependent modules are therefore disabled until this removed > module is back online > 3) Current module is copied to a backup location for restoration if the > new version needs to be reverted > 4) New module is installed by copying it into the deploy directory > 4a) All dependent modules are "back on" since their dependency is now > available again with the new version > > Outstanding questions: > > 1) Should a CVS/RCS-like versioning be done locally to enable multiple > revision restoration in case of incompatible modules > 2) How to handle versioning requirements between components (i.e. I > install a new foo v1.1, which requires the Commons 1.1 lib and v. 1.4 of > the Bar module as well) > > Just some thoughts to get the discussion going. Is you considering making > all Eclipse plugins Mbeans now, or just a specific part of the platform > Mbean based? > > Regards, > James > > > -----Original Message----- > > From: Matt Munz [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, December 22, 2002 10:46 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: [JBoss-dev] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Fri 12/20/2002 4:03 PM > > To: [EMAIL PROTECTED] > > 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: <[EMAIL PROTECTED]> > > cc: > > From: "Matt Munz" <[EMAIL PROTECTED]> > > 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:[EMAIL PROTECTED]] > > Sent: Friday, December 20, 2002 3:23 PM > > To: [EMAIL PROTECTED] > > 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:[EMAIL PROTECTED]] > > > Sent: Friday, December 20, 2002 1:06 PM > > > To: [EMAIL PROTECTED] > > > 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 > > > [EMAIL PROTECTED] > > > developer mailing list. We will be reviewing your > > feedback in the new > > > year. > > _______________________________________________ > > eclipse-dev mailing list > > [EMAIL PROTECTED] > > http://dev.eclipse.org/mailman/listinfo/eclipse-dev > > _______________________________________________ > > eclipse-dev mailing list > > [EMAIL PROTECTED] > > http://dev.eclipse.org/mailman/listinfo/eclipse-dev > > > > _______________________________________________ > > eclipse-dev mailing list > > [EMAIL PROTECTED] > > http://dev.eclipse.org/mailman/listinfo/eclipse-dev > > > > > > NXu)Yg ؞HzG%zZ陨xnu떊z{˲q zضX˺~zwXϊ˝zZ > > > >ӆ+,隊X'uNggr zH^jm( n,ׯzZ)홨x%In,ׯzZ)Xy+zmbq+-bا~n,ׯzZ) ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
