Ales Justin wrote:
> The VDF code creates new nested ZECs rooted at the old EAR ZEC.
This
> is the true owner of the temp.
Yes, old .ear ZEC was reset, hence it needs to re-initialize.
Creating new nested ZEC + new temp copy is expected.
We could actually leave some thing if we knew it was a re-deploy,
but this is done per VDF bases, which is outside the VFS goal.
> The scan in the middle of the deployment process gets the new EAR ZEC,
> and thus creates a new nested entry under that.
I don't see why a new EAR ZEC is created.
If we're not explicitly using VFS::createNewRoot,
then .ear's ZEC should always come off cached deploy/ root (its cached
VFSContext).
The cache on the FileSystemContext(/deploy) is wiped because undeploy
calls cleanup on the EAR VF, and that calls removeChild on the
DelgateHandler's parent, which is the FSC(/deploy).
I should be able to do a VFS deployment test that simulates this now.
Although I still want to try out the multiple handle change to tempinfo.
--
Jason T. Greene
JBoss, a division of Red Hat