Re: [PROPOSAL] tag

[Daniel Rall <dl...@finemaltcoding.com>]

> > SERVLET tag is part of the Servlet framework itself, rather than its JSP
> > extension.  (I'm not certain that the SERVLET tag is actually part of the formal
> > spec, but it *is* supported by the Java Web Server, which to date is the
> > official reference implementation for a Servlet engine.)

> ok, any specialized tags have absolutely no connection to the "servlet
> framework."  The Servlet spec has absolutely no mention of the content
> that is parses and is strictly a coding api.  The Java Web Server is a
> separate product written by Sun that uses the servlet api but is not any
> part of the servlet api.  JWS has a separate technology called jhtml
> that includes stuff like that and can parse general pages for SSI tags
> like the <servlet> tag.  --These JWS value adds have nothing to do with
> the servlet framework and are only JWS specific--

Okay, clarified.  It's *not* part of the Servlet API.  But it *is*
supported by many popular web servers and add on servlet engines
(including Apache through use of JSSI).  I would suggest that Tomcat
supports this as well, since I don't think that these other products are
going to deprecate the tag just because JSP is now available.  

Many sites that use servlets *do not use JSP* (see
http://www.sourcexchange.com or http://www.collab.net).  

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.  (Especially when they are as simple to implement
as the SERVLET tag.)

> Furthermore, the JWs has *NEVER* been the reference implementation of
> the servlet platform, the JSDK and JWSDK have been, and now tomcat is
> for Servlet 2.2 and JSP1.1.  

You're right, I didn't correctly remember what I had read.

  "Sun's Java Web Server (formerly called "Jeeves"), unofficially
considered 
  the reference implementation for how a servlet engine should support 
  servlets."  -- pg. 8, Java Servlet Programming by Jason Hunter,
O'Reilly

Of course the opperative word here is "unofficially."  My bad.

> > ...I usually don't believe in supporting mutliple interfaces.  But in
> > this case, I feel that an exception should be made.  The user would have to be
> > familiar with Java Server Pages to know about--and how to use--JSP:INCLUDE.  

> ...if the user can use tags
> like <servlet> then they can learn a tag that is now a standard part of
> the java platform for the enterprise.

See my other mail regarding data limitations in HTTP GET requests, and
above regarding the fact that not everyone uses JSP (or is willing to
switch to it).

> </rant>

I'm not trying to argue, so please don't rant at me.  I'm trying to have
a discussion.  Your input is obviously valuable (you pointed out several
things that I didn't know or was mistaken about).  I hope that you can
limit your rants in the future, as they greatly discourage my
participation in this project.  Thank you for your time and your efforts
to make this a world class piece of software.

Peace out.

Re: [PROPOSAL] tag

[Danno Ferrin <sh...@earthlink.net>]

"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
sometimes.

--Danno

Re: [PROPOSAL] tag

["Craig R. McClanahan" <cm...@mytownnet.com>]

"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

Re: [PROPOSAL] tag

["Daniel L. Rall" <dl...@finemaltcoding.com>]

> > 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.  ;)
 
> 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.)
 
Earlier today I mentioned that I might be persuaded to implement a
web-based, searchable list archive (or install one found on Freshmeat). 
Though I requested a server to put this on, I do have my own server to
offer as well.  It has poor connectivity (cable modem w/ static IP) and
intermittent reliability (I play with it all the time).  I could set
something up on it until another server can be found.

drac.finemaltcoding.com, if you want to ping or traceroute

Perhaps someone can recommend a piece of mailing list archiving
software?  If I don't find one (yeah, how likely is that ;), I'll whip
one up.
-- 

Daniel Rall (dlr@finemaltcoding.com)

Re: [PROPOSAL] tag

[Danno Ferrin <sh...@earthlink.net>]

> Okay, clarified.  It's *not* part of the Servlet API.  But it *is*
> supported by many popular web servers and add on servlet engines
> (including Apache through use of JSSI).  I would suggest that Tomcat
> supports this as well, since I don't think that these other products are
> going to deprecate the tag just because JSP is now available.
> 
> Many sites that use servlets *do not use JSP* (see
> http://www.sourcexchange.com or http://www.collab.net).
> 
> 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.  (Especially when they are as simple to implement
> as the SERVLET tag.)

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.  The tomcat core is facing a serious limitation in the regard of
what you want it to do by adding defacto standards to tomcat.  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.

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.

> > Furthermore, the JWs has *NEVER* been the reference implementation of
> > the servlet platform, the JSDK and JWSDK have been, and now tomcat is
> > for Servlet 2.2 and JSP1.1.
> 
> You're right, I didn't correctly remember what I had read.
> 
>   "Sun's Java Web Server (formerly called "Jeeves"), unofficially
> considered
>   the reference implementation for how a servlet engine should support
>   servlets."  -- pg. 8, Java Servlet Programming by Jason Hunter,
> O'Reilly
> 
> Of course the opperative word here is "unofficially."  My bad.
> 
> > > ...I usually don't believe in supporting mutliple interfaces.  But in
> > > this case, I feel that an exception should be made.  The user would have to be
> > > familiar with Java Server Pages to know about--and how to use--JSP:INCLUDE.
> 
> > ...if the user can use tags
> > like <servlet> then they can learn a tag that is now a standard part of
> > the java platform for the enterprise.
> 
> See my other mail regarding data limitations in HTTP GET requests, and
> above regarding the fact that not everyone uses JSP (or is willing to
> switch to it).
> 
> > </rant>
> 
> I'm not trying to argue, so please don't rant at me.  I'm trying to have
> a discussion.  Your input is obviously valuable (you pointed out several
> things that I didn't know or was mistaken about).  I hope that you can
> limit your rants in the future, as they greatly discourage my
> participation in this project.  Thank you for your time and your efforts
> to make this a world class piece of software.
> 


If it wasn't for the fact that this very same question has been asked a
whole bunch of times in the past week I wouldn't have been ranting (but
I was ranting in a good way, I save flames for personal mail).  Another
popular question has been where is the web archives for the list.  There
is none, which if there was one I believe there would be a lot less
duplication of questions.  Another thing is that I have a pet peeve when
people say tomcat needs to support feature X because commercial
application supports feature Y, especially when it involves violating
the spec.  You are just one of many who have and I did not direct it to
you (or it would have been in a personal mail).

One of the biggest issue with the the number of people requesting or
demanding features is increasing much faster than the number of people
willing to contribute time and effort to tomcat.  The most immediate
need is for someone to get a web based archive of the list up.  Since I
am running off of a dilaup or behind a firewall that is outside of my
resources to provide, but I would do it if I could.  

--Danno