Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <2962FDBAFD8ED41196C100D0B73E7B380F5F60@COLEXCH>
From: Mel Martinez <MMartinez@G1440.com>
To: "'tomcat-dev@jakarta.apache.org'" <tomcat-dev@jakarta.apache.org>
Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
Date: Tue, 27 Mar 2001 10:02:06 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"


--- cmanolache@yahoo.com wrote:
> Hi Mel,
> 
> In my view, jasper is composed from at least 5 big
> components:
> 
> 1. The jsp->java translator. 
> 
> 2. The java->class compiler
> 
> 3. The Mangler ( managing name mappings )
> 
> 4. Runtime - that should be completely independent
> of all other pieces, 
> since jasper-generated servlets should run without
> jasper ( as simple 
> servlets ) 
> 
> 5. Interface with the serlvet container (
> JspServlet, JspInterceptor and
> the associated classes). ( putting all other
> components togheter )
> 
> My understanding is that your proposal is related
> with (5), and it seems
> it has the great property that it can be done as a
> proper refactoring -
> without chaning any functionality, just by providing
> better communication
> and code organization ( as the first stage ), and
> then by creating one
> module ( that will eventually replace JspServlet ).
> 

Yes, my main concern here is with (5) although I would also like to refactor
the mangler as well.

> Since this is my favorite "modus operandis" I can't
> say anything than a
> big +1...
> 
> There are few issues:
> 
> - Impact on 3.3 release cycle. I hate delaying it -
> it's clear we
> need another milestone, but I believe in the
> "release early and often"
> ( and on schedule :-). I tried very hard to decouple
> the components as
> much as possible, so development on any component
> shouldn't affect the
> overall release ( and the rest of the code ). 
> 
> That would be resolved by your proposal to use a
> separate package name -
> the new ( "in development mode" ) code can be
> developed in a proposal
> space and released separately and be included in a
> 3.3.1 for example. 
> 
> I think keeping "old, stable" code in paralel with
> "new,
> better" implementations and doing a gradual
> replacement is a very good
> strategy ( AJP1.1 -> AJP1.2 -> Ajp1.3 -> Ajp1.4,
> mod_jserv -> mod_jk ->
> mod_jk+webapp,  facade22 -> facade23, etc ).
> 

I'm agreeable with this strategy.  What package name should we use?  This
is primarily a 'replacement' of what is in org.apache.jasper.servlet.
Should we just name it "org.apache.jasper.servlet33"?  Suggestions?


> - Class loading and other interfacing problems. As I
> said many times, I
> don't think JspServlet is the right way to plug
> jasper in a container, but
> a richer interface exposing more of jasper. Having a
> working JspServlet
> for quick-plugin is great, but I think we should
> rather focus on keeping
> it just a small facade to a  better designed and
> more powerfull internal
> API.  
> 

1) I don't off-hand know of any other generalized way to make a portable JSP
compiler that can be plugged into any servlet 2.2 engine other than as a
servlet.  I'm not sure how that limits us feature-wise, other than the fact
that it adds a layer of indirection between the request on the container and
the actual ultimate jsp servlet.  A small performance price to pay for
portability.

2) One major point of the refactoring is to minimize the role that the
JspServlet plays.  In the model I'm advocating it only does a couple of
things: initializes jasper (i.e., creates the JspFactory) and maintain a
cache of JspPageHandlers to which it passes the requests.  Given this, the
same role could be played by other entry mechanisms.


> In any case, a refactoring can only help, and you
> have my +1 ( i.e. I
> think it's a good idea and I'll help !).
> 
> ( BTW, I'm looking into an alternative/experimental
> implementation for the
> jsp->java component, probably after 3.3 - as a
> standalone add-on
> module. I have few ideas - but I want to first do a
> prototype )
> 
> 

Dr. Mel Martinez	mailto:mmartinez@g1440.com
Software Architect	phone:410-423-3931
G1440, Inc.	http://www.g1440.com