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

[alesj]

Thinking about it even more ...

"alesj" wrote : 
  | How do you then handle these three 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 guess this shouldn't be such a huge problem as I see it. :-)
If you have a handle to some VirtualFile, use it as it is
- be it client view or temp, it's up to the type of the handle.

If I get an URL, try to use as much as possible.
Hence treating URLs as server side objects.

The 'inconsistency' will always be there.
e.g. VirtualFile that was fetched via navigation vs. direct URL access

"alesj" wrote : 
  | So, during structure recognition, we already get a few unpacked nested jars.
  | Then it turns out that the user requested this app to be temped.
  | 
  | To be true to our unpacking/temp performace reasons (= reuse as much as possible), 
  | 
This is also quite easy to avoid (to some extent). :-)
The existing unpack/temp info should just hold the ref to the new File,
which should be later on re-used.

Here we would still have two versions of wiring,
one from client the other from temp,
since incorporating re-wiring would perhaps even be wrong.
But at least it would be done on the same unpacked/temped copies,
hence no need to spend any time doing that.

But this two new 'findings' shouldn't stop you from 
adding some content to this problems. ;-)


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206131#4206131

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