[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Deployment cleanup & modifications

[alesj]

"alesj" wrote : "adrian at 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#4206010

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206010