[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JarEntry as VFS root does not return empty vfspath

anonymous wrote : | IIRC, the path originally was setup lazily, except for the now obsolete jar handler that went through every entry up-front? | I'd like to learn more about JarHandler being obsolete ... anonymous wrote : | I don't understand why you can't fall back to getParent().getParent().etc. | at the worst? | This is our context URI: file:/vfs/test/outer.jar!/org/jboss/test/vfs/support These are parent child relationships for handlers within JarContext: null JarHandler (represents: file:/vfs/test/outer.jar) JarEntryHandler (represents org) JarEntryHandler (represents jboss) JarEntryHandler (represents test) JarEntryHandler (represents vfs) root = JarEntryHandler (represents support) JarEntryHandler (represents CommonClass.class) JarEntryHandler (represents jar1) JarEntryHandler (represents jar2) root handler has VF handler representing 'vfs' for its parent. getParent().getParent() returns VF handler representing 'test'. The solution would be to set root's parent to null. anonymous wrote : | I don't remember the code being that difficult, but then I haven't worked on it for a while? | I've approached the problem with a simple guideline: make a fix with a minimum amount of code change. Don't change method signatures, try not to introduce additional fields ... AbstractVirtualFileHandler gets three pieces of information: VFSContext, parent, name. To properly compose pathName I have to start generating the path at root node. I need to know which node is root and I need to make this check during pathName generation. The simplest way was - let's use naming convention. Root should always have '', and it makes no sense for any normal file or directory to have '' name so we can test for root like this: isRoot = "".equals(name). But this fell through because root in this VFS implementation is not '' and shouldn't be forced to be ''. Ok, next I tried using parent: isRoot = parent == null. But turns out it's not null. There are ways to fix this - we just set it to null somewhere, but who knows what dragons this will wake up so I saved this approach for later maybe. Let's use VFSContext then. Let's get root handler from it and see if it's equal to this. This exposed infinite recursion mines. First VFSContext closed exception that calls toString() that calls getPathName(), then in equals() which again calls getPathName(), the only thing left was == comparison which is not reliable due to unreliable context root retrieval, and serialization/deserialization ... So this approach fell through as well. anonymous wrote : | Sounds like a simple solution, but maybe not so good on memory usage? | Ok, I'm trying another thing first - 'set parent to null' approach, that won't require any additional fields. I see two ways of doing it. One is to propagate some extra info based on which each handler can determine - as it's being created - if it is a root handler or not. That approach is processor intensive and requires small changes in many places. Another approach is to introduce setParent(VirtualFileHandler) or setAsContextRoot() method and call it on only one handler as it's assigned to be context root. That approach requires one extra method and one extra call - very elegant. But ... makes handler creation a two-phase process for handlers that become root and makes these handlers mutable. Looking at AbstractVirtualFileHandler I find no reliance on immutability so I don't expect problems. I'm testing a fix made using this approach, and so far everything is working nicely. In the end I'll remove more code cleaning out the current quick fix than add new code for a proper solution :) - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138835#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...