Brill,
I've been reading along, and I agree that you have a valid use case.
However, this is all academic until you send in some sort of patch. I
might even use this patch if it were sent in - but I don't have time to
develop it myself. Sorry, but you're starting to put the cart before the
horse here...submit a patch, _then_ nag (pardon the expression) the
committers [on the -dev list, BTW] for attention. If you send in a
patch, I'll look at it and discuss it with you...then, maybe I'll help
you lobby for it (I'm not certain of my status wrt committing plugins;
this is something that's been generally up for debate recently). But
understand, the only help I'll offer in any capacity will be subject to
my own availability. Just as I'm sure you have, I have a day job that
doesn't center on maven. :)
HTH,
john
On Wed, 2004-06-30 at 10:44, Brill Pappin wrote:
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]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
