"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:
(1) root::getChildren()
(2)
root::getChild("myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class")
(3) VFS::getRoot(new
URL("${jboss.deploy}/myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class"))
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
re-unpack something.
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 :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206010#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...