Re: HTTP Server to serve classes

"Guijarro, Julio" <[email protected]> Fri, 31 Aug 2007 09:29:40 +0100
Newsgroups gmane.comp.java.smartfrog.user
Message-ID <[email protected]>
The sfCodeBase is used for the dynamic class loading but it has the
limitation that I described. Once the classes are loaded in the JVM
there is no way to replace/unload them. What I suggested is to use
sfCodeBase for dynamic class loading but in subprocesses so that you can
remotely terminate them. 

 

Julio

 

From: Robinson, Gary [mailto:[email protected]] 
Sent: 31 August 2007 09:26
To: Guijarro, Julio; smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: RE: [Smartfrog-support] HTTP Server to serve classes

 

Hi Julio, 

 

I was wondering if it would be sufficient to just use the attribue
sfCodeBase in my component description i.e.

 

sfCodeBase "http://serverip:8080/SmartFrog/sfuserhomejartoload.jar";

 

Would this avoid having to worry about subprocesses?

 

Cheers,

 

Gary

 

________________________________

From: Guijarro, Julio [mailto:[email protected]] 
Sent: 30 August 2007 15:01
To: Robinson, Gary; smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: RE: [Smartfrog-support] HTTP Server to serve classes

Hi Gary,

 

 

With the last stable release  it is possible to use dynamic classloading
to deploy NEW classes from jars hosted on an HTTP server but once they
are loaded it is not possible to replace/unload those classes to upgrade
them. What is possible, though, is to deploy your classes (using dynamic
classloading) in a subprocess and then when you want to refresh them you
can restart the subprocess that in turn will load the latest version.
The caveat is that you have to be careful not you deploy any component
that uses "replaceable" classes in the daemon process because you cannot
replace them unless you restart the daemon.

 

The good news is that we have been changing the way classloading works
to make it more flexible and dynamic and we have integrated SmartFrog
with OSGi so that you can even use OSGi to manage different versions of
the same jar for different applications. 

 

All this new classloading infrastructure  is more or less ready to be
shipped and will be part of the next release of SmartFrog but it is not
yet merged into the Trunk and lacks of proper documentation. In any
case, if you want to start using it you can get it from SVN in the OSGi
branch. 

 

One thing that you can do to mitigate the restart of the daemon is to
run your application on a subprocess with a name and then you terminate
all this subprocesses when you want to reload a new version of your jar
files 

 

Julio

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
Smartfrog-support mailing list
Smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/smartfrog-support