or VFS needs a re-deploy notion.
What goes on and where does it go wrong?
* some ProfileService part finds modified deployment
* it returns list of Modifications to HDScanner
* HDScanner for MODIFIED deployment does this:
* MainDeployer::addDeployment <-- (W)
* HDScanned invokes mainDeployer::process()
* MainDeployer --> DeployersImpl::process(undeploy, deploy)
* DeployerImpl::process --> undeploys modifed deployment, (re-)deploys modifed deployment
The wrong part is this:
In (W) we find existing deployment context, hence this means that addition is actually a re-deploy.
We add existing deployment context to undeploy, and then we create/recognize new one to be deployed.
And this is what's wrong --> we are actually doing new structure recognition on a deployment that's about to be undeployed --> its temp are gonna be cleared.
This already reads some VirtualFile refs into the DeploymentContext.
This refs can point to ZipEntryHandlers (VirtualFileHandler impl) whos underlying temp file is about to be deleted.
But the actual temp deletion only happens in DeployersImpl:process, its undeploy part.
So, we end up with parts from old VirtualFile refs and a few new ones.
e.g. from my test, the classpath was and old ref
In VFS on VirtualFile::clear I delete possible temps and reset jar VirtualFileHandlers (actually it's its contexts).
This reset enables that owning jar handlers are gonna re-initialize its contents, hence re-creating nested temp jars.
That this clearly works I added the following change to HDScanner:
case MODIFIED: mainDeployer.removeDeployment(ctx); // change mainDeployer.process(); // change mainDeployer.addDeployment(ctx); break;
But this is not the right solution, since it's MainDeployer that should transparently handle re-deploys.
What would be the right way to do this?
We're probably have to break existing 2 phase deployment for re-deploys.