You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Hans Bergsten <ha...@gefionsoftware.com> on 2000/11/03 21:34:50 UTC

Re: TC3: moving jasper

cmanolache@yahoo.com wrote:
> 
> In order to test and integrate the new jasper ( from catalina ) we
> need to move src/share/org/apache/jasper to src/jasper3/org/apache/jasper,
> and import jakarta-tomcat-4.0/jasper into jakarta-tomcat.

Do you plan to keep the JSP 1.1 version of jasper as the default for
TC 3.x? I think we should, because TC 3.x is the reference implementation
for Servlet 2.2/JSP 1.1. jasper from TC 4.x may also use JDK 1.2 features,
while TC 3.x is supposed to not rely on anything but JDK 1.1.

I'm not all that comfortable with adding features from the new specs
into TC 3.x. It only confuses the users. It's much easier to explain that
TC 3.x is the reference implementation for Servlet 2.2/JSP 1.1 and
TC 4.x is the RI for Servlet 2.3/JSP 1.2.

I like to hear others opinion about this, before we end up with a
very confusing message. I'm not -1 this yet, but I may do that if I
don't hear a good story about keeping TC 3.x as a clean RI for the
current specs.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: TC3: moving jasper

Posted by cm...@yahoo.com.
> > In order to test and integrate the new jasper ( from catalina ) we
> > need to move src/share/org/apache/jasper to src/jasper3/org/apache/jasper,
> > and import jakarta-tomcat-4.0/jasper into jakarta-tomcat.
> 
> Do you plan to keep the JSP 1.1 version of jasper as the default for
> TC 3.x? I think we should, because TC 3.x is the reference implementation
> for Servlet 2.2/JSP 1.1. jasper from TC 4.x may also use JDK 1.2 features,
> while TC 3.x is supposed to not rely on anything but JDK 1.1.

Servlet2.2 and Jsp1.1 will be the default for tomcat3 - at least that's
the naming convention. 

The core, facade22, jasper are supposed to work with JDK1.1. You should be
able to get a working server - but not all features will be supported.

All JDK1.2 features are part of modules that are not required for "2.2/1.1
reference implementation". 

As for facade23 and jasper4 - I don't think it's a good idea ( or we can 
) to keep them at JDK1.1 level ( I remember that servlet2.3 has a mention 
about JDK1.2, I don't know if it's still there). That doesn't affect the
core in any way - you'll get servlet2.2 only if you have jdk1.1.


> I'm not all that comfortable with adding features from the new specs
> into TC 3.x. It only confuses the users. It's much easier to explain that
> TC 3.x is the reference implementation for Servlet 2.2/JSP 1.1 and
> TC 4.x is the RI for Servlet 2.3/JSP 1.2.

Well, that's because the naming convention is bassed on the assumption
that a new rewrite will happen for each servlet version.

Tomcat3.x can support any servlet version - including 2.0 or 2.4 (
whenever that'll happen ), but it'll continue to be the reference
implementation for 2.2 because that's the convention, and will continue
to have 2.2 as default. 

We can even build a version of 3.3 that have _only_ 2.2 built in, or we
can find a new name for tomcat3 if that will confuse people, but I can't
see any reasonable reason to stop the development on tomcat3 and just
throw it away ( well, thanks to Apache licence I don't think anyone can
stop people from working on it ). 

> I like to hear others opinion about this, before we end up with a
> very confusing message. I'm not -1 this yet, but I may do that if I
> don't hear a good story about keeping TC 3.x as a clean RI for the
> current specs.

Again, the core has no dependency on any servlet version.
The facade2.3 is independent, as is the facade2.2.

I don't remember any vote or rule that tomcat 3 must implement _only_
servlet2.2 - after all it's an open source implementation of an API, and
as soon as servlet2.3 will become final all servlet containers should
implement it - and that includes tomcat3.

Tomcat4 is a different code base, and except for the first 6 letters of
the name it has almost nothing else in common with tomcat3.

Costin