About 'file.getChild() -> getChildren() madness' ...
getChildren() is only getting called when no handler is found in handler's childCache
for the given name. But that does happen a lot (WEB-INF probing ...)
The reason getChildren() is being called is because of the specifics of how .vfslink
mechanism works.
** How links mechanism works **
FileSystemContext supports a linking mechanism. You create a properties file and put it in
a directory that's somewhere under a FileSystemContext root.
This properties file has to conform to a naming convention - something.vfslink.properties.
The first part of the name ('something') is irrelevant - it plays no role.
An example content of this file:
| vfs.link.name=extras
| vfs.link.name.0=extra1.jar
| vfs.link.target.0=${jboss.server.home.url}extra/extra1.jar
| vfs.link.name.1=extra2.jar
| vfs.link.target.1=${jboss.server.home.url}extra/extra2.jar
|
Let's say this file is inside 'deploy' directory. This would create a
LinkHandler named 'extras' under 'deploy' FileHandler. And this
LinkHandler will contain two children - 'extra1.jar' and 'extra2.jar'.
The result of placing this file are therefore the following additional virtual files:
| deploy/extras
| deploy/extras/extra1.jar
| deploy/extras/extra2.jar
|
Detecting if LinkHandler (the virtual directory containing links) was removed
Link handler can be removed by a) removing .vfslink.properties file that caused its
creation, b) changing vfs.link.name property of this same file.
Detecting if link was added
Link handler can be added by a) adding a new .vfslink.properties file, b) changing
vfs.link.name property of existing .vfslink.properties file.
The main problem of this design is that there is no one-to-one mapping between LinkHandler
name ('deploy/extras' in our example), and the properties file that created it
('something.vfslink.properties' in our example). If we want to determine the
current configured state of links we _have to_ find all .vfslink.properties files in
parent directory ('deploy' in our case), and process them. That's why
getChildren() gets called. We could for example just check the file from which the link
was created (LinkHandler contains that info) but that's not enough. This file may have
disappeared due to being renamed into something else, which shouldn't affect links
configuration - nothing substantial changed.
If we want to optimize this, we need to change the implementation. The simplest change
would be to cancel vfs.link.name property and tie LinkHandler name to the first component
of .vfslink.properties file - in our example it would have to be called
extras.vfslink.properties.
This little change is enough to now be able to avoid having to call getChildren() on the
parent in order to process all .vfslink.properties files in parent directory.
I've commited a fix along these lines.
- marko
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168305#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...