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.=20
=20
Julio
=20
From: Robinson, Gary [mailto:gary.robinson@...]=20
Sent: 31 August 2007 09:26
To: Guijarro, Julio; smartfrog-support@...
Subject: RE: [Smartfrog-support] HTTP Server to serve classes
=20
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
=20
________________________________
From: Guijarro, Julio [mailto:julio_guijarro@...]=20
Sent: 30 August 2007 15:01
To: Robinson, Gary; smartfrog-support@...
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

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:julio_guijarro@...]=20
Sent: 30 August 2007 15:01
To: Robinson, Gary; smartfrog-support@...
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