Deployment cleanup & modifications
alesj Jan 28, 2009 4:47 AMAn exception I got yesterday while testing new MC releases
gave me plenty to think about in the evening.
WRT:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=148563
Doing just DeploymentContext::cleanup is not enough.
Why?
Since we have a notion of modifying a deployment (X):
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=149077
What does this actually do?
If using 'temp' directive we create a temporary copy of deployment's file,
hence the actual Deployment::root != DeploymentContext::root.
In other words:
* Deployment == client view
* DeploymentContext == server view
But while we're trying to recognize the structure, to create a DeploymentContext instance,
we already potentially do some temp unpacking, ...
That's why a need to do cleanup also on client side Deployment.
How to do this?
1) Deployment::cleanup - add new method
2) DeploymentFactory::destroyDeployment - add new method
3) usage specific, e.g. in Profile Service code: VFSDeployment::getRoot::cleanup
Which one to use/impl?
Also a few observations/issues about modification usage.
There might be more, but this are the one's I scrapped together.
(a) When to replace a handler when doing a modification?
I actually forgot about this issue and changed how this behaved in VFS. :-(
In my opinion 'temp' and 'explode' should not replace handler.
As this changes client behavior.
e.g. server/deploy/myapp.ear --> server/temp/some-uuid/myapp.ear
If I did a replacement on a parent (= deploy/), then deploy/ would actually see both deployments at update.
Only unpack should replace it. As it only applies to nested resoruces,
hence doesn't change client view that much. At least not in a confusing fashion.
(b) direct URL usage
Although we use modification, the URL's are still the same as non modified.
So, if you use direct URL (any of its ops), the vfs cache is gonna navigate you to non-temp view.
Meaning even though you're using things on server side,
it's gonna drive you off into client side.
It's still gonna be somehow the same, as modifications don't modify the resource itself,
but it's just conceptually wrong, since you did modifications for a reason.
(c) Even if you use modifications, all undeploy (see (X)) issues don't go away
e.g. if you use a direct VFS URL, at undeploy, it's gonna go to VFS cache,
and try to navigate to previously deleted file (aka client view).
Since VFS cache has no idea that you actually created a temp version of your deployment.
If you use other mechanisms, e.g. classloaders, deployers,
they are gonna work, as they transparently know about the temp.
(d) tmp and VFSCache
How to apply vfs cache to tmp directory so that we don't hit vfs-nested.tmp dir,
which will be massive memory drawback.
How to actually make usage of it, as temp should be impl detail/hidden.
Really uncharted territory ...