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

[alesj]

"adrian at jboss.org" wrote : Why are you trying to "destroy" the Deployment object?
  | 
I'm not or I'm only destroying it if I created it.
As does the ProfileService.

"adrian at jboss.org" wrote : 
  | All the book keeping for temp data of a VFS file should be inside the VFS itself.
  | 
It is.
As much as it can be, since temp/modifications 
were completely left out from initial/original design.

"adrian at jboss.org" wrote : 
  | I said this before WRT to the horrible explicit VFS Cache you did, but I was ignored.
  | 
Where was this?
I never (or I must really missed it) heard any idea/feedback about vfs cache.
When things were horribly slow, I thought of something.
And even then there was no feedback.

Good, bad, horrible ... whatever ... it still only has a few lines to change if you wanna ditch that.

"adrian at jboss.org" wrote : 
  | The "simplist" solution to this problem should be that when somebody creates a root
  | VFSContext it is against that object that the "temp" information should be stored or at least linked.
  | 
  | That root VFSContext should always be "live" while somebody holds a
  | link to the root VirtualFile.
  | 
  | Then when somebody asks to cleanup a VirtualFile within that context, it can workout which parts of the temp information need to be removed.
  | 
  | The context should still be usable, its just removed the temp data which would need to be
  | reconstructed. Which is why close() or destroy() is a bad name/semantic.
This makes sense.
But it should have been there 2 years ago. :-)

All these problems and your suggestions make
me wonder if we wouldn't be better off rewriting the whole stuff.
Perhaps even moving jar/zip handling to what DML plans to use.

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

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