Some problems have already been reported regarding to undeployment, where classloaders would still be kept in memory and would prevent correct removal of jars.
I have not had much time yet to investigate this issue, unfortunately. However, this should not affect the ability to redeploy a SA, as it will be deployed in another directory. .\wdir\service-assemblies\sa-name\version_2 for example. On 10/2/06, William Blackburn <[EMAIL PROTECTED]> wrote:
We have an issue which seems to occur only on Windows. We are using servicemix 'pojo' components deployed against the lwcontainer as a sort of hot-deployable extension framework for our service. When deploying our SAs (by copying the zip files into the 'deploy' dir) everything works without error - we can start sending them exchanges immediately. When we remove the SA zip file from the 'deploy' directory - the servicemix logs indicate a successful 'undeploy', however, when looking into the 'wdir/service-asssemblies' directory, the content of the sus is still there. Windows appears to believe all the jar files are in use. This, of course, wrecks the possibility of deploying the SA again, and Tomcat must be stopped and 'service-assemblies' manually cleaned out to proceed. Undeploying in this way under Linux and OS X works as expected. One developer here believes that we have a classloading conflict, perhaps a reference held between two different classloaders. I've experimented by configuring the SU to load all of its classes from the container, then reconfigured it with 'inverse=true' and bundled all the dependencies. The problem occurs regardless. I don't use Windows myself, so now I am completely stumped - anyone seen this before, ideas? Thanks, BJ
-- Cheers, Guillaume Nodet
