[jboss-dev] VFS Temp Reuse (JBAS-6715)

[Jason T. Greene]

Jason T. Greene wrote:
> 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. 

I committed a test to deployers that reproduces this:

org/jboss/test/deployers/vfs/deployer/bean/test/VFSRedeployTestCase

It verifies that the VirtualFileHandler in the DeploymentUnit is the 
same as the one in the registry (accessed via VFS.getRoot()).

While I think the long term solution should be to make VirtualFile 
instances capable of being reused (auto resynch like we talked about 
earlier), the short term approach should be to make the deployers 
refresh the VirtualFile handlers after calling undeploy when a 
deployment is being redeployed.


> Although I still want to try out the multiple handle change to tempinfo.
> 

This doesn't work and is a hack anyway.

-- 
Jason T. Greene
JBoss, a division of Red Hat