Return-Path: <cmcclanahan@mytownnet.com>
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 14486 invoked from network); 12 Feb 2000 03:51:43 -0000
Received: from easystreet.com (HELO easystreet01.easystreet.com)
 (206.26.36.40)
  by locus.apache.org with SMTP; 12 Feb 2000 03:51:43 -0000
Received: from mytownnet.com (dsl-208-151-245-220.easystreet.com
 [208.151.245.220])
	by easystreet01.easystreet.com (8.9.1/8.9.1) with ESMTP id TAA01967
	for <tomcat-dev@jakarta.apache.org>; Fri, 11 Feb 2000 19:51:42 -0800 (PST)
Sender: cmcclanahan@easystreet.com
Message-ID: <38A547FD.37CC73CF@mytownnet.com>
Date: Sat, 12 Feb 2000 03:46:05 -0800
From: "Craig R. McClanahan" <cmcclanahan@mytownnet.com>
Organization: MyTown Network, Incorporated
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [PROPOSAL] <Servlet> tag
References: <48B84EAE356F0FC18625688200799EC5.0079AC7386256882@tivoli.com>
 <v04210102b4ca39e373eb@[146.84.38.126]>
 <38A48D25.EE890A2A@finemaltcoding.com> <38A49067.D44E79A6@earthlink.net>
 <38A49745.396E4B5C@finemaltcoding.com> <38A4ACD6.85EFAE44@earthlink.net>
 <38A4D612.B3115322@finemaltcoding.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Daniel L. Rall" wrote:

> > > If we are going to supply *the* servlet engine, it would be helpful to
> > > support common extensions offered by other broadly used products, thus
> > > facilitating the switch to Apache Tomcat by having these common
> > > extensions available.
>
> > Tomcat does not want to be the one and only servlet engine, much as
> > apache (to my knowledge) does not want to be the one and only http
> > server.
>
> I'd like Tomcat to be the best servlet engine (not the only), if I am to
> be using it on my projects.  (Just as I consider Apache to be the best
> web server.)  My definition of best in this context is high--but not
> necessarily highest--performace, powerful, configurable, extendable, and
> feature rich.
>
> > The tomcat core is facing a serious limitation in the regard of
> > what you want it to do by adding defacto standards to tomcat.
>
> I don't understand this.  Could you expound upon it a bit?  Does this
> have to do with the <PREFIX:TAG> syntax that Hans indicated must be
> used?
>

JSP page compilers have to parse the input page to identify custom tags, as
well as the standard tags.  In all cases (starting with JSP 1.0 at least),
the JSP tags being recognized have a prefix -- "jsp:" for the standard
actions, and whatever prefix you describe for custom tag libraries.  No other
tags will be parsed -- it is assumed that they are to be sent to the client
making the request.

Thus, implementing <servlet> as a custom tag is not going to achieve your
primary goal -- allow porting of an application based on this to run on
Tomcat, because the syntax would have to change anyway.  If that's the case,
it's just as easy to change it to <jsp:include>, which you can use without
knowing a thing about the other JSP-related stuff like beans.

But see below for a different alternative.

>
> > Tomcat is
> > a reference implementation of a published standard, servlet 2.2 and JSP
> > 1.1.  Support for defacto standards are a possibility but unfortunately
> > most of these would force tomcat to violate the spec.
>
> Such as adding a tag with no prefix?  (I'm not actively trying to beat
> this subject to death, even though it kinda looks that way.  ;)
>

Tags with no prefix are sent to the client.  That's the way it will work in
all standard implementations, so there's no point in trying to change it just
for Tomcat.

However, you can implement <servlet> tags yourself, in a servlet, if you
don't also want that page to support JSP.  The basic technique would go like
this:

* Create a servlet that does the page parsing, and
  implements the functionality of the servlet tag as
  well as is possible.  This is more work than it sounds
  like -- you'd probably be better off starting from an
  existing implementation like Apache JSSI and modifying
  it to work under Tomcat <http://java.apache.org>.

* Register this servlet in the deployment descriptor of
  your web application.

* Also in the deployment descriptor, add a <servlet-mapping>
  element that maps the "*.shtml" extension to your servlet.

I wouldn't have any objection to someone contributing such a servlet to the
Tomcat code base as an add-on feature, or adding it as a default so you don't
have to explicitly map it.  But, in the big picture, applications that depend
on this should really be migrated to use <jsp:include>, or converted to some
other template system's mechanism.  The <servlet> tag was never (and I'd bet
never will be) an official standard -- it was only a defacto one -- and it's
functionality is limited compared to the current alternatives.

Craig McClanahan