tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
Date Mon, 26 Mar 2001 18:08:16 GMT
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 ).

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 ).

- The other 4 components of jasper are also in a big need for a
refactoring. I think we'll see a lot of improvements in jsp->java
generation, and it would help a lot to be able to modularize it even more.

We clearly need a refactoring to allow you to plug the new JspServlet, and
we should extend it to at least the point where we cleanly separate the

- Jasper 4. This will increase the divergence between jasper3 and jasper4. 
I spent some time trying to find a way to merge the 2, and I gave up
because of the current complexity. If a similar refactoring is done in
both sides ( since at least 90% of the code is still common ), and as
result of refactoring we can merge the common code in a set of common
components - then we might get more people involved and avoid a lot of
time waste. 

- 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

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 )


On Mon, 26 Mar 2001, Mel Martinez wrote:

> As hinted at last week, I'd like to propose
> refactoring some of the classes in Jasper to improve
> the OO model a bit, make maintenance/extendability a
> bit easier and hopefully help the performance a bit as
> well for those of us using jasper as the JSP engine in
> other servlet engines (other than tomcat, that is). 
> There are problems with using the current Jasper in
> other ServletEngines that do not show up with the
> tomcat JspIntercepter that need to be addressed.
> I'd like to refactor JspServlet, JspServletWrapper,
> JasperLoader, JasperEngineContext and JasperCompiler
> to better divide responsibilities along the following
> lines:
> JspServlet - entry point for JSP page (*.jsp),
> initialize Jasper and maintain cache of jsp servlet
> wrapper/handlers, otherwise do very little but pass on
> the request to the handler.  I.E. represents the scope
> of the jasper engine.  Possibly rename this to
> JasperServlet or just 'Jasper'.
> JspServletWrapper - rename as 'JspServlet/PageHandler'
> (or similar) and make this a full class (i.e. take it
> out of JspServlet).  This class manages the life cycle
> of a single Jsp file, including methods to resolve
> relevant file paths (i.e. to .jsp file, .java file,
> .class file), package/class name mangling and
> modification checking.  This class would be
> responsible for managing dynamic reloading of an
> out-of-date page.  Only one instance of this class is
> created per page for the life JVM (or more accurately,
> for the life of the JspServlet).
> JspRequestWrapper/Handler/Context - encapsulate
> information relevant to one request - this would
> implement JspCompilationContext, since a compilation
> would be one possible event during the request. 
> However, we'd remove some of the current behavior in
> JasperEngineContext that is really page-lifecycle
> behavior that belongs in the JspServlet/PageHandler.  
>  This class should be a lightweight information
> payload used by the page handler, loader and compiler
> for fullfillment of the request.  By reducing the
> number of fields to only those that are
> request-specific and possibly by object pooling, the
> impact of instance creation (necessary for each
> request) can be greatly reduced.
> JasperLoader, Compiler, and a few other classes would
> be refactored (actually simply extended slightly
> through subclassing) to support these mods.  Some of
> the current behavior would be refactored out to the
> page life-cycle handler.  Compilers can probably be
> pooled for reuse.
> Along with the above class refactoring, we would add
> recursive modification checking and dynamic reloading
> to JspServlet, miscelaneous bug and performance fixes
> (ex: mangled filename caching), and factory methods to
> make it easier to  modify behavior by pluging in
> replacement classes (such as the name mangler, loader
> and compiler).  I'd like to improve the way classpaths
> are handled to make things more apparent to the
> developer using Jasper standalone how to set things
> up.
> The beauty of this is that this can all be done
> without rewriting much if any of the existing code in
> TC3.3. We can simply create a separate implementation
> of JspServlet, called 'Jasper' (or JasperServlet or
> whatever) or place the changes in a separate package
> and thus folks working with the current version would
> not be impacted by API changes.  We can then deprecate
> the current classes gradually.
> It is imporant to note that this proposed refactoring
> would be to the standalone JspServlet page and request
> life-cycle management.  This does not address any
> possibly needed refactoring of the actual Jasper
> compiler, which will remain the common element used by
> all three entry points: JspInterceptor, the current
> JspServlet and the proposed new jsp servlet.
> Maintaining runtime compatibility with JspInterceptor
> is, of course, mandatory.  No changes should cause
> JspInterceptor to break.  Maintaining consistency with
> JspInterceptor in terms of how it might do some
> ancillary things (name mangling, caching
> optimizations, classpath resolution etc.) should also
> be desired, but not required since, after all,
> JspInterceptor represents value-added for the tomcat
> servlet engine.
> To facilitate development, I can donate the bulk of
> this as finished code I've already written that simply
> needs to have appropriate package and class renaming
> applied.
> This proposal should be considered a rough draft.  I
> need feedback, especially from others also using
> Jasper as standalone in other servlet engines (such as
> WebLogic Server, JRun, Jserv, etc.) on what problems
> they'd like to see solved.  I'd also like suggestions
> on whether to put this into a separate package in
> Jasper (ex: org.apache.jasper.embedded) or to simply
> insert it into the existing org.apache.jasper.servlet
> package using new class names.  I think I'm in favor
> of the latter approach.  I don't think there will be
> much conflict or confusion with the approach I'd like
> to take.
> That said, I will have actually some time later this
> week to actually implement most of this.  So feedback
> now is better than feedback later.
> Cheers,
> Mel
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail. 

View raw message