The standard make a series of provisions for the case in which there is no 'pathname' corresponding to some resource in a web application. These provisions were intended to support a model where a WAR file is never exploded into a native file system. Conceptually, you can model this as supporting unexploded WAR, but that's just a conceptual model. The conspicuous practical case is Oracle, which unpacks the WAR into the database.
However, I respecfully submit that all of this is beside your original point. I think that the important point is that the specifications only deal with self-contained web applications, whether or not anyone ever assembles one into a WAR file. Tomcat is not trying to be a full J2EE container (c.f. jboss). The designers are willing to add functionality to permit the use of the J2EE resource model, but they are very protective of Tomcat's status as a relatively tight, lightweight device. The META-INF/server.xml thing isn't, currently, a WAR feature. It's narrower than that. It's restricted to a particular tool for deploying from a WAR. This very narrow view is much more a reflection of the desire to avoid feature bloat than any particular tilt to or from WAR files. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
