On Mon, 6 Dec 2004, Erik Hatcher <[EMAIL PROTECTED]> wrote: > Also, any requests from the client to access the resources in > WEB-INF/ directory must be returned with a SC_NOT_FOUND(404) > response."
"client" being a user of the web application, not code running in the application here. It is absolutely legal to use ServletContext#getResource[AsStream] for stuff in /WEB-INF. > "Web containers must also be able to recognize declared dependencies > expressed in the manifest entry of any of the library JARs under the > WEB-INF/lib entry in a WAR." Which could say "Class-Path: some/sub/dir/foo.jar". > So it is ambiguous, at least to me (one part says "in" another says > "under"), whether a hierarchy under WEB-INF/lib is kosher or not. I don't see anything ambiguos. You can have a hierarchy but the web app classloader is supposed to load the jars of the "top-level lib" dir - and their declared Class-Path dependencies. What else you do with the hierarchy is up to you. > On Dec 5, 2004, at 6:23 PM, Russell Gold wrote: >> It would be entirely consistent to extend its use to the >> <lib> subtask (which essentially does a copy in any case). Cake and >> eat it, too. > > <lib> is not a subtask, per se. It is a fileset datatype. The > difference currently is that datatypes don't "do" anything, but > contain data that tasks use. That's why I've always been against adding mapper as nested element to fileset. We should rather have a more generic mapper in <zip> and friends, the you could chain a flatten mapper with a glob mapper that adds WEB-INF/lib/ to the front and would be done. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
