Please forgive this email. It's a self-improvement exercise. I didn't
take logic in University, so I'm genuinely asking the questions below.
I'm not being sarcastic ;) Only bother reading this if you're on lunch,
and care to take a bit of a thought exercise.
I cannot find a single place in the spec (2.3 and 2.4) that states
unequivocaly that containers are only required to support archived
applications. (for interest, I used 'find' in acrobat on both versions,
to find 'WAR', 'archive' and 'required'). There's at least one place
that *might* be used to infer this, but I would disagree, which I
outline below. So before it all starts, can anyone point me to the line
in the spec that states, in other language, and unequivaocaly, that "a
servlet container is only required to support archived applications"?
Some prelude:
>From the glossary in the spec:
[b]web application[/b]
A collection of servlets, JSP pages , HTML documents, and
other web resources which might include image files, compressed
archives,
and other data. A web application may be packaged into an archive or
exist in
an open directory structure.
There's that word weak word, 'may'. So can we infer that if it MAY be A
and it MAY be B, that both A and B are *required* to be supported? Can
we infer that they *ought* to be supported? (is that middle ground even
possible; ie: if it only *ought* to support B, can you strongly say that
B is even an option?)
SRV.3.5
SRV.4.5
Both contain similar weak language in regards to archived/open files
("may")
Then, in later sections (numerous) it starts to talk about things
(filters, classes, etc) that get packaged "into the WAR" or "in the
WAR". The spec starts to adopt the assumption that your app is
archived.
But mainly, there's this in SRV.9.4, which I think is where people infer
that containers need only support archives:
"This specification defines a hierarchical structure used for deployment
and
packaging purposes that can exist in an open file system, in an archive
file, or in
some other form. It is recommended, but not required, that servlet
containers
support this structure as a runtime representation."
1 An application can be in an open file system
2 An application can be in an archive file
3 An application can be in another form
4 A container is not required to support open file system.
5 A container is not required to support another form.
6 Therefore, a container is only required to support archive file.
First of all, both #4 and #5 are not (in my mind) spelled out by the
text of the spec I quoted. But lets assume they are. Is 6 then, a valid
inference? Because with one interpretation of the above paragraph, #6
must be a valid inference, and can therefore be used to assert that
containers must only support packed applications. 'cause like I said, I
can't find the line that says "Containers are only required to support
archived web applications".
But here's how I have always read this paragraph, and please tell me how
this is wrong.
"This specification defines a [[hierarchical structure]] used for
deployment and
packaging purposes that can exist {in an open file system}, {in an
archive file}, or {in
some other form}. It is recommended, but not required, that servlet
containers
support [[this structure]] as a runtime representation."
So the [[ ]] are the matching elements. Containers should, but are not
required, to use the [[structure]] as a run-time representation. It
doesn't say anything regarding recommend/require about any of the
{representation choices}.
I'm trying to remember which one it was.. but back in the day, wasn't
there an app server (iPlanet maybe?) that would take a WAR file, and
then explode it all to hell, moving files here and there, classes over
here, etc, etc, and of course, the "runtime representation" didn't look
anything like the [[structure]]. I think that's what this paragraph is
talking about. A container is free to do whatever it wants, at runtime.
It is recommended that its runtime representation be the [[structure]]
defined, but is not *required* to be. But in this interpretation, there
is no way to infer that any of the deployment {options} are either
'required' or 'recommended' to be supported.
Lastly, there's also this:
SRV.9.6 Web Application Archive File
"Web applications can be packaged and signed into a Web ARchive format
(WAR)
file using the standard Java archive tools. For example, an application
for issue
tracking might be distributed in an archive file called issuetrack.war."
There's those weak words again ("can" and "might"). To me, this implies
that it might also be in 'open file system' format. And there's nothing
in the above that speaks to a container requirement, one way or the
other, other than:
1) it CAN be in A
2) it CAN be in B
3) Therefore, the container *must* support both A and B ??
This seems to be backed up the the glossary definition of 'web
application', where it states that it *may* exist in either 'archive' or
'open directory' format.
alright, back to real work.
> -----Original Message-----
> From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 28, 2004 7:55 AM
> To: Tomcat Users List
> Subject: RE: Tomcat 5: default unpackWARs bahaviour?
>
>
>
> Hi,
> Don't rely on a default value for unpackWARs: put it in your
> instructions that it must be true, because that's a place
> where your webapp deviates from the Servlet Specification
> (which only requires containers to support packed WARs).
>
> Yoav Shapira
> Millennium Research Informatics
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
