One problem with this approach is that the official storage format for a
J2EE webapp is a
WAR File. Your resources, when in a WAR wouldn't be accessible as filesystem objects, thus any attempt to access them using java.io.File would fail. You could do so if the WAR had been "exploded" (unzipped), but exploded form is not part of the J2Ee standard, so doing so would violation the J2EE standard. Also, since webapp servers have no concept of "current directory", whether within a WAR or not, a relative pathname would be extremely risky to use, assuming it ever functioned at all.
The safer way to get at WAR resources is to use the HttpServletRequest getResource methods, which take as their pathnames an "absolute" resource location. Absolute relative to the root of the WAR, that is. So a resource path of "/WEB-inf/classes/log4j.xml" would return access to the log4j.xml "file" (see above) in a J2EE-compliant way. Note that the leading slash is mandatory, since it's an absolute path.
I'm not sure that theres a method that will enumerate WAR resources or not without reading the docs. Since a WAR is
supposed to be read-only, you could always create a resource that contains the list of resources in it. If, on the other hand, the list of resources is subject to change, you might find it better to place them in a real directory somewhere outside both the WAR and the webapp server.