"alesj" wrote : "adrian(a)jboss.org" wrote :
| | This avoids also trivially allows you to avoid unpacking them again, since you can
ask this cache.
| ... since it solves (b), (c) and (d).
Actually this is not true by default.
This is as bad as replacing existing handler with temp.
We need a temp notion when asking for resources.
e.g. (your solution wouldn't know how to do this or would be inconsistent)
* deploy/ (the context root)
** myapp.ear (packed)
We then ask to temp this myapp.ear, which would create CacheInfo in deploy/'s context
under myapp.ear path.
How do you then handle these two calls:
I would expect for (1) not to use temp, otherwise I won't know when my original
myapp.ear was deleted.
For (2) and (3) I would like to use all the existing temps I could get in order not to
I see two solutions:
(a) keep two copies of the same context root; one would be fully temped, the other one not
temped at all - and trying to synch them somehow
(b) when asking for resources, push in temp notion somehow (no idea right now, apart from
ThreadLocal hack :-()
View the original post :
Reply to the post :