Ales Justin wrote:
>> Why exactly is ZEC-B created?
>> It should be only one, as that's the point of having a cache.
>
> It looks like nested zip entries are never registered in the cache
> (see mountZipStream) in ZipEntryContext.
I still don't see how that could happen.
As the only api to get a VirtualFile is over VFS class.
And VFS goes over VFSRegistry, which knows about the cache.
New mounted ZEC should be a child of some already cached context.
And when someone asks for URL --> VirtualFile,
it should actually hit that parent context,
(see your newly added VFSContext::getFurthestParentTemp(String path))
which would then know about that newly mounted ZEC.
Found it! The context root is registered properly (/deploy), the ear
context is however duplicated, which leads to eventual duplicate nested
war ZECs.
1. ProfileService calls VFS.getRoot() on the ear
2. The VirtualFile is passed to MainDeployer.addDeployment
3. Structure scanning is performed, which holds on to the roots.
4. MainDeployer.process()
5. Undeploy is performed which invalidates the EAR ZEC
6. Deploy is performed which *reuses* the root in 2, so everything using
the VDF gets the old ZEC
7. VFSRegistry.getFile is called by the JSR77 deployment code
(J2EEDeployment)
8. Since the EAR was undeployed a *new* EAR ZEC is created
--
Jason T. Greene
JBoss, a division of Red Hat