Hi, In short: - Yes some of the spec parts use weak wording, e.g. "may", take that up with the spec JSR group (there's contact info on the JSR web page) - It's clear that supporting a packed WAR is required - It's clear that supporting open file system structure is optional - No one is saying open file system support is forbidden, but it's clearly not required, and therefore developers can't count on it being available - I don't know what server you had in mind that blew up a war and broke it apart, but I do know that some Oracle servlet containers in the past put the WAR in the database, and a filesystem was not available at all: this is often cited as a compliant server that does not allow for exploded WAR deployment.
Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: Mike Curwen [mailto:[EMAIL PROTECTED] >Sent: Friday, May 28, 2004 11:58 AM >To: 'Tomcat Users List' >Subject: RE: Tomcat 5: default unpackWARs bahaviour? > >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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
