tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danno Ferrin <>
Subject Re: [PROPOSAL] <Servlet> tag
Date Sat, 12 Feb 2000 06:23:27 GMT
"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?
> > 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.  ;)

Yes, adding tags wiout prefixes are explicitly forbidden by the spec. 
There are also some other issues, like what if more than one taglib
wants to use the nonprifix space, naming colisisons, what if a name of
an action has a colin in it (I think that is forbidden too not sure).  

And what about plain old html tags?  If an action lib is assigned to the
no-prefix space then any action that is not in the lib it ecomes a
runtime error, so a special excepion would need to be made in that case
or else bringing in a taglib where there is no prefix would break the
rest of the html in the page, since the next html tag will be an action
in the un-named space. 

All in all it just becomes a mess real quick, so the action mechanism is
as simple as possible, but no simpler.

> > But Tomcat is just the core implementation.  There is nothing to prevent
> > anyone from forking the tomcat code base and adding these features.  In
> > fact the license practically encourages it! (just as long as the name
> > makes it unmistakably separate from apache names).  Once Tomcat reaches
> > performance parity with JServ and other implementations you will see
> > some of this forking happening, perhaps even on a commercial level (like
> > apache->stronghold).  If you want to add those extensions go ahead, go
> > to town on it.  Let us and other people know because I am sure that
> > there are other people who would love to see it.  But as for the apache
> > core it won't be put in the code base, because the very premise of the
> > jakarta project essentially forbids it.
> I'd rather not fork the Tomcat code.  I don't have the resources or time
> to deal with maintaining that.  An add-on module sounds like a good
> compromise, though I still think that this belongs in Tomcat (if it
> doesn't go against the spec.)

Actually, after thinking about it a while, makeing the jsp sevlet handle
diffrent files diffrently (like say based on extension) may be
implementable.  In the main dist it is only wired for jsp but a seperate
dist or other modules would wire in for their page language.  What the
JspServlet would do is based on it's configuration marshal a compielr
that would use the compiler context to determine what and how the stuff
gets fed into the JspParseEventListener.  

For jhtml that would entail sending most <JAVA> tags as scriptlets and
<servlet> becomes an equivilant jsp:include.  The code still lives in a
jsp, but there is a hypothetical intermediart jsp page that doesn't get
realized.  Actually a JspParseEventLister could be written that would
just dump out the jsp insted of compiling it.  This would work to make
the mythical xml representation of section 7 of the spec work to.  

For more exotic translations like PHP, at the top of the page we could
imply a "<%@ page language='jzope' %>"  and for .cfm files there could
be a "<%@ taglib uri='...' prefix='cfm' %>" implied and all the parser
does is treat the cold fusion tags as if they appeard with the prefix
(of course the taglib would need to be written).  Man, if my employer
would just let me work on tomcat all day the pluming jhtml and the
jsp-xml would all be there by june.  Big clinets can be so particular


View raw message