Re: [Smartfrog-support] HTTP Server to serve classes

[Robinson, G. <gar...@sa...>]

Hi Julio,=20
=20
I was wondering if it would be sufficient to just use the attribue
sfCodeBase in my component description i.e.
=20
sfCodeBase "http://serverip:8080/SmartFrog/sfuserhomejartoload.jar";
=20
Would this avoid having to worry about subprocesses?
=20
Cheers,
=20
Gary

________________________________

From: Guijarro, Julio [mailto:jul...@hp...]=20
Sent: 30 August 2007 15:01
To: Robinson, Gary; sma...@li...
Subject: RE: [Smartfrog-support] HTTP Server to serve classes



Hi Gary,

=20

=20

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.

=20

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.=20

=20

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.=20

=20

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=20

=20

Julio