-
15. Re: Cleanup path for Structure Deployers
alesj wrote:
In regards to the question of what do non-deployers do, the structure scanning/processing phase should ensure that all relevant mounts have been created meaning they work with the vfs handles much as they did before. If they are to work out of the deployment phase (e.g. standalone code), then they will need some setup and cleanup code to create the mounts.
OK, I came to peace with this attempt. :-)
Let's try to impl this in StructureDeployer(s), but as some helper methods in AbstractStructureDeployer.
And we'll see how far this takes us.
Sounds like a good idea.
Also, the deployers framework seems to be the natrual home for the registry, as its whole reason for existence is to serve the complex deployment lifecycle in AS. Although portions of it could be moved to some other module (perhaps VFS tiself), if there was some desire to resuse it.
I still don't agree with this, but I'll let you have the benefit of the doubt.
We still have long read ahead -- making all the tests work in various sub-projects -- which will show who's right.
I don't feel as strongly about it as you, so let's just move the registry back to VFS then. David, John?
I agree about the tests. Nothing is getting merged until the new approach is proven.
-
16. Re: Cleanup path for Structure Deployers
Sorry it has taken me all day to reply to this, I have been in orientation all day.
I plan to move forward with the following in the deployers-vfs project:
1. Change VFSHandleRegistry to Automounter, and update to the mount/cleanup API
2. Change the basis of the Automounter to be an ownership set for a given VirtualFile
3. Assure mount calls are idempototent to support calls from both StructureDeployer(s) and StructureBuilder
4. Move the Automounter to the VFS3 project
5. Integrate the calls to the Automounter into the following locations:
a. StructureDeployer(s) - This will be done with abstract helpers (I have already written most of it)
b. VFSStructureBuilder
c. VFSClassLoaderClassPathDeployer
6. Update the DeploymentContext::cleanup to correctly invoke the cleanup operation
7. Continue to update required tests to work with integrated VFS3 (about 70% complete)
I realize this will not yet be true auto-mounting, but it will at a minimum identify all the locations that require an archive to mounted. Once identified we can take some time to discuss whether or not the calls are too intrusive. If the prove to be too intrusive, and true auto-mounting is needed we will at least know the amount of exposure and identify the locations where ownership will need to be tracked through some kind of context (ThreadLocal or something).
Ales, do you have any ideas on how we can track who would be the correct owner at the time the auto-mount would occur?
-
17. Re: Cleanup path for Structure Deployers
Ales, do you have any ideas on how we can track who would be the correct owner at the time the auto-mount would occur?
Who would/do you consider an owner?
But your plan sounds like a plan. :-)
Let's try that first and then we'll see if we even need auto-mount.