tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Jasper Changes
Date Thu, 21 Sep 2000 22:59:47 GMT
> > 1) jakarta-tomcat/jasper
> > 2) jakarta-tomcat-4.0/jasper
> > 3) jakarta-jasper/
> >
> > I vote for 3.  How hard is it to set up a new repository?
> >
> Does 3 accomplish something fundamentally important that 2 doesn't, or is this just
> for show?  :-)

A simple solution is to make a symlink on locus (
i.e. jakarta-tomcat-4/jaseper to jakarta-tomcat/jasper ), and everyone can
use whatever name it prefers.

> > (or, instead of catching an exception, it could switch on the results
> > of context.getMajorVersion()/getMinorVersion() -- taking the context
> > at its word what version it supports)
> >
> Ask Costin (and others) how easy it has been to support JDK 1.1 and JDK 1.2 in the
> same container :-).  It is really hard to do this right, without substantial
> impacts on your performance (i.e. having to use reflection) or code maintenance
> (two versions).


So far the only "hard" thing is to get people that use JDK1.1 and tomcat (
like Jason on SGI, or me on locus ). As long as the code is modular the
1.2 ( and servlet 2.3 ) specific features can easily be implemented in
modules ( that are conditionaly compiled ).

Regarding the impact on performance - all reflection happens on startup (
and it's insignifiant compared with other startup tasks ). ( tomcat still
supports 1.1 and doesn't seem too slow because of that - I never saw any
1.1-specific code in any profiling )

> > In other words, are there any backwards-incompatible features of the
> > JSP-1.2 spec?  Or will any JSP-1.1 compliant .jsp file run identically
> > in a JSP-1.2-compliant JSP container?
> As things stand right now (and as is currently true of Tomcat 4.0 for everything
> I've tested so far), 100% of servlet 2.2 / JSP 1.1 applications should run under
> containers implementing the new specs, unless they depend on bugs in the
> implementation of their existing container.  Failure to do this is a bug.

Tomcat-3.3 will probably implement servlet2.2 also ( or 3.4 if 3.3 freezes
before we have a chance to do it ), and we're trying to make it support
both versions and interpretations.

> Which, going back to the earlier point, raises the question that we are all
> tiptoeing around:  what is the future of the Tomcat 3.x code base after 3.2 goes
> final?  While bug fix support (and perhaps 3.2.1 or 3.2.2 releases) might be needed
> before Tomcat 4.0 is production quality (it undoubtedly has bugs that need to be
> shaken out, but nearly all of the bug reports recently on 3.1 and 3.2 are for
> things that already work correctly in 4.0 :-), I have no personal time or energy or
> interest in continuing down the current path (although there's a bunch of good
> ideas on performance tuning that can be harvested).

I don't know about future, but 3.3 will have significant performance
enhancements over 3.2 and will likely support servlet 2.3 API in paralel
with 2.2, plus many enhancements in the core.

Other goals: real support for foreign charsets and improvements in

3.4 will probably focus on modules - and will probably result in another
performance boost.

My goal: be able to run sandboxed webapps on a public server with decent


View raw message