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?

From: Guijarro, Julio [mailto:julio_guijarro@hp.com]
Sent: 30 August 2007 15:01
To: Robinson, Gary; smartfrog-support@lists.sourceforge.net
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