Ok, let me explain this one more time.
What you are saying is indeed part of the servlet spec, and the container may actually read and care about what's in the WAR manifest, however code running in the application context doesn't know, and doesn't care.
It doesn't care because for things to be working, the webapp must be working properly already and if it wasn't the code running in the context would have other problems anyway.
By allowing a user to jar up and add a manifest for the *application code* you allow the user to specify all sorts of meta information about the code at runtime (as mentioned in the versioning spec). The application code runs in the containers context but the versioning information *for the war* means nothing to the application itself, in fact the versioning API can't even get the WARs versioning information (at least not in any container I use), but it *can* get versioning information for the libraries it depends on which means the user code that was JAR'ed up.
An example of where I specifically use this information:
I'm sure you've seen how you have have log4j output the file and line number of a log message. Now using the versioning API you can also output other information as well as the file and line number, such as what version it is, the module or company it came from... you can even tell things like what dependencies it has etc.
As you can see it would be pretty useless to anything but the webapp container to have all this in the WAR file. Not only would it no longer be relevant to the runtime code, but all libraries in the context would have the same information.
I hope I am being clear here because I can't think of a simpler was to describe this.
For those interested in more detail, the versioning spec is at: http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html
As an aside, Maven might be able to use this to determine the dependency structure of a library which I know if a holy-grail for the first release, but I leave that to the folks working on the artifact stuff.
- Brill Pappin
Maczka Michal wrote:
Here is what spec says:
"Web containers are recommended to have a mechanism by which web applications can learn what JAR files containing resources and code are available, and for making them available to the application. Containers should provide a convenient procedure for editing and configuring library files or extensions. It is recommended that Application developers provide a META-INF/ MANIFEST.MF entry in the WAR file listing extensions, if any, needed by the WAR. The format of the manifest entry should follow standard JAR manifest format. In expressing dependencies on extensions installed on the web container, the manifest entry should follow the specification for standard extensions defined at http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. Web Containers should 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. If a web container is not able to satisfy the dependencies declared in this manner, it should reject the application with an informative error message."
So realy the spec makes no difference between any of the manifest files
which are provided inside wars
and clearly defines where they can be placed. But for strange reason it says: "It is recommended that Application
developers provide a META-INF/MANIFEST.MF entry in the WAR file listing
extensions".
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
