From: Anthony C. <to...@ve...> - 2005-07-28 18:59:05
|
Niclas Hedhman wrote: > On Thursday 28 July 2005 22:17, Anthony Cook wrote: > >>My position is that the Expect >>header, regardless of attribute, is to be passed to the servlet >>unhandled (the servlet is, afterall, the server "extension"). This I >>based on my own testing with Tomcat (as the "reference implementation"), >>and Resin (the most widely used OSS implementation per Netcraft) > > Ok. The Servlet spec does not explicitly mention this, and IMNSHO that means > that it is "unspecified" and *not* something a portable user can depend on. > Ok. The Servlet spec. is ''intended to be a clear and complete explanation of /Java servlets/'', not of HTTP, of which the "clear and complete explanation" is left to the HTTP specification(s), to which the Servlet spec. makes reference. However, to provide a "clear and complete" explanation of Java servlets by necessity entails specifying how a servlet or container is to respond to certain aspects of the referred to specification(s), where such might otherwise be ambiguous. Is that an unreasonable statement? Is it too "lawyer-like"? In this regard, the specification explicitly states ("specifies") what the container does handle or do. What it does not say the container does is presumed to be left to the servlet. Or, IYNSHO, is that also incorrect? > You make an lawyer-like line of reasoning that; > > 1. Servlet containers must implement HTTP. > No, my reasoning, based on what the specification says, as well as on historical perspective and intention, is as already stated: the container handles what is explicitly specified for it to do so, and the rest is left to the servlet. Servlet containers, per the specification, are extensions of a Web server and ''must support HTTP as a protocol for requests and responses''. Per the specification, those requests and responses are handled by the servlet, excepting those aspects which are not explicitly specified for the container to handle. > 2. Servlets are extensions of the Servlet container (are they?). > No, servlets "extend the functionality of a /Web server/", just as do, for example, CGI scripts and proprietary extension APIs. This at least is what the spec. informed us up until version 2.2, when "servlet engines" became "servlet containers" and part of not just Web servers but also "application servers". Now, based on my "lawyer-like" reading of the current specification, it is the "servlet container" which extends the Web server, or application server, by providing ''the network services over which the requests and responses are sent'' and by ''manag[ing] servlets through their lifecycle''. However, the historical perspective of the /servlet/ as being that which actually provides the server's "extended functionality" has not changed and is still also maintained by the spec. > 3. Therefor all aspects of HTTP should be accessible to the Servlet. > No, only those aspects not specifically directed to the container, such as... > Well, that is plainly not true for other aspects of the HTTP protocol, port to > be connected to, virtual hosting, forced disconnects between requests and so > forth. > ...er, these things, for example. > So, the simple answer is that I think you are wrong about your stance, that > compliant implementations must mimic the RI at all times. Bad example of > highlighting the absurdity of requiring independent implementations to > mimickk the RI; > Then you must also think Sun to be wrong in their stance, no? ''A reference implementation (RI) has been made available which provides a /behavioral benchmark/ for this specification. Where the specification leaves implementation of a particular feature open to interpretation, implementors may use the reference implementation /as a model of how to carry out the intention of the specification/.'' -- Servlet Specification 2.4, SRV.P.1, "Additional Sources" [emphasis mine] > Assuming for a second that Tomcat exposed (for instance, bad classloading > strategy and class is sitting visible in system classloader) some nifty > little util class; > > org.apache.tomcat.util.DoWhatINeed > > Does that mean all independent implementations must implement/provide that? If > No, this is an example of /how/ the specification is being implemented not /what/ it specifies is to be implemented. The specification makes no assumptions on /how/ implementors implement the specification and, in fact, plainly leaves such details to the implementors. As well, as is implied in the preface to the spec, the 'what' of implementation ("behaviors") is intended to be interpreted from the viewpoint of "Java servlets". "Java servlets" are written to the specified APIs, not to any one implementor's APIs. Implementors APIs, also refered to as "proprietary extension APIs", are to be avoided by "servlet programmers", or risk loss of portability. > not, then I can write a Servlet that won't run in another container but the > RI. > Which is an example of writing to an implementation, and not to the specification. Such is, of course, at the discretion of the servlet writer, but is also recommended against by the specification with portability in mind. As J2EE application developers, we are "encouraged" to use the J2EE SDK, the "reference implementation", as both a platform for developing our applications and as a benchmark for ensuring specification compatibility; and, thus, compatibility with "certified" implementations. So assuming I do so (use the RI), and my application works as expected (on the RI), but upon deploying it to a non-RI implementation it "breaks", with whom do you suggest I raise the issue? Or are you suggesting that, in this case, the RI be assumed "faulty" and I simply start rewriting those aspects of my application which are broken on the non-RI implementation to "fix" it? > Where do you draw the line in the sand, between the above absurd example and > your own interpretation of things that may or may not be implied in the spec > With regard to "intention" and "historical perspective" for both servlets and their "predecessors"; which, interestingly enough, are also relevant to reading and interpreting the laws of one's society. I'm accused of being "lawyer-like" in my reading and interpretation of the specification, though I rebut that as, rather, simply paying attention to details. Yet, the specification is, if I may be indulged the analogy, the "law" with regard to what it explicitly "intends to clearly and completely explain". Conversely, one could say that a societal "law" -- say, with regard to driving, or paying taxes -- is a "specification" for how members of its target "community" are to "behave" with respect to those things which /it/ "intends to clearly and completely explain". I don't think someone would accuse me of being too "technician-like" in reading and interpreting those, though you are welcome to be the first. :) Yet, amusingly enough, when trying to point out "specifics" of behaviour within this "technical community", several are quick to label me "lawyer-like". :-/ |