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
components.
- 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
API.
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 )
Costin
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.
> http://personal.mail.yahoo.com/
>
