From: Anthony C. <vs...@mi...> - 2005-07-27 00:54:20
|
David Jencks wrote: > This might be nitpicking but "standalone J2EE compliant Web-container" > is a contradiction in terms. If it is J2EE compliant, it has ejbs, > You're right, it is "nitpicking". My implication was that it is compliant with Web-container side of the J2EE stack, being certain "standard services" compatible with HTTP as well as several other explicit and implicit APIs. I was not suggesting that it is "fully J2EE compliant", which I'm also quite sure I implied where I wrote ''though it is otherwise an incomplete implementation of the full J2EE "application server" stack''. "J2EE" is a meta-specification which specifies several "standard services" and APIs found in a "J2EE compliant" server, whether that server is a full or only partial implementation of the complete meta-spec. [[ Note that, though not explicitly correct usage, by "J2EE compliance" here I refer to adherence to one or more of the underlying specifications of J2EE, not to passing a full TCK battery or qualifying for the "J2EE" logo appellation. ]] A complete list of those "standard services" is found in section J2EE.2.6. of the current 1.4 specification... > connectors, app clients, etc etc. If its standalone, as defined by the > standalone servlet tck, which is what tomcat is the reference > implementation of, it doesn't need these things. > "Apache Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies." -- Jakarta Tomcat home page "Tomcat is a free, open-source implementation of Java Servlet and JavaServer Pages technologies developed under the Jakarta project at the Apache Software Foundation. Sun adapts and integrates the Tomcat code base into the J2EE Reference Implementation." -- Sun J2EE download pages /At its core/, Tomcat is the "official Reference Implementation" for the Servlet and JSP specifications. At their cores, these two specifications explicitly provide the HTTP and HTTPS "J2EE standard services", along with the Servlet and JSP APIs. The "Security" standard service is also an indicated requirement of the Servlet (and by inheritance, JSP), APIs. However, looking beyond the bare explicits, the Servlet /specification/ also specifies /Web Applications/. Concerning /Web Applications/, the Servlet specification provides that: "A Web application is a collection of servlets, HTML pages, classes and _/other resources/ that make up a /complete application/_ on a Web server." -- Servlet 2.4, SRV.9 Historically (a history which the specification explicitly acknowledges), those "other resources" include access to data sources, messaging systems, mail servers, etc., all of which the Servlet specification implicitly abstracts into "Utility classes". In any case, a "stand-alone" Web-container can not be presumed to provide support for "complete Web applications" if access to such "other resources" are not somehow supported. > I think Greg's comment about difference of focus is very accurate. > Although I still have some minor issues, it is not hard to install jetty > into an alternative component framework, using the frameworks wiring > rather than jetty's. Trying to do the same with tomcat is many orders > of magnitude harder, due to tomcat's desire to be the universal > framework controlling everything, i.e. an app server. It's just not a > J2EE app server. > Per its intended purpose, and specification adherence, Tomcat is indeed an "application server", at least with regard to "Web applications". At its core, /Jetty/ is an HTTP server and "Servlet container". Just what /Jetty/ means by "Servlet container" is questionable, since /Jetty/ certainly does not implement the full /Servlet specification/ (as implied in SRV.9). When /Jetty/ is compared to /Tomcat/ the comparison is "apples to oranges", due to the breadth of "Tomcat"; but if only "names" are to be considered then, in this vein, I agree that Greg's comments are accurate, their "foci" are different. However, a more correct comparison for /Jetty/ is to Coyote+Catalina, which are no more "orders of magnitude" harder to embed in an application framework than /Jetty/. Conversely, when comparing "Tomcat" to "Jetty", it is more correct to compare to /Jetty-Plus/ which, like /Tomcat/, also "desires to be an application server", at least with regard to "Web applications". > thanks > david jencks > Regards, Anthony Cook |