TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Mel Martinez <me...@yahoo.com>]

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/

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cm...@yahoo.com]

> 1.  In general the Java SecurityManager implemenation in Tomcat 4
> and Jasper has significant improvements and is much cleaner.

True. The SecurityManager in 3.3 is working fine for now ( Glenn is also
the main author for the 3.x sandboxing ), with all watchdog passing - but
a refactoring will help cleaning up the code.

> 2.  Jasper class loading is much simpler in the Tomcat 4 version.
> It uses a single URLClassLoader for each JSP page, this allowed
> me to simplify a great deal how Jasper handles generation of class
> and package names (no more need to do incremental .java and .class files).
> And it removed alot of overhead at both JSP translation and runtime
> when Jasper tries to figure out which incremental class file to use/check.
> This sped up JSP compiles by 33% and runtime execution by 25%.

Well, I have to disagree here :-) It is indeed much simpler than the  3.2
jsp class loading, and using URLClassLoader is a step in the right
direction.

Tomcat 3.3 is also using URLClassLoader ( for everything - except the
JDK1.1 replacement that has the same interface and replicates
URLClassLoader ). 

I would say the incremental .java is not a bad idea, and the code to
support that is reasonably simple ( and provide some unique benefits
related with reloading and avoiding some special cases ) - it should be
trivial to make it optional ( if anyone feel the need ). 

We don't use a class loader per jsp page ( since it isn't needed - given
the versioning ), but again it would be easy to add it.

In any case - at least the class loading is just fine in 3.3, no need to
fix it ( but I think everyone would be happy to have more options - like
what you mention about one class loader per jsp and no versioning - as
long as this is not mandatory and doesn't replace the other scheme ). 


> And before you ask, I just don't have the time to back port these
> changes in TC3.3.

Well, it would help a lot if you could at least take a look and review the
sandboxing for 3.3 :-) Security and sandboxing are very difficult, and you
probably have the most experience with that.

On a related issue, I would be very interested in re-commiting some of the
original patches ( defining the permissions in server.xml in addition to
the policy file ), this would help a lot in the future admin
interface. Again, we might need your help ( if you still have them
around ) :-)  

Costin

> 
> Regards,
> 
> Glenn
> 
> 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/
> 
> 

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Mel Martinez <me...@yahoo.com>]

--- Glenn Nielsen <gl...@voyager.apg.more.net> wrote:
> I have made some changes to the Jasper code in
> Tomcat 4 that
> you might want to look at.
> 

I will definitely be looking at TC 4.

> 1.  In general the Java SecurityManager
> implemenation in Tomcat 4
> and Jasper has significant improvements and is much
> cleaner.
> 

I copied some of this in my current implementation. 
Shoudn't be too hard to keep it in when I port.

> 2.  Jasper class loading is much simpler in the
> Tomcat 4 version.
> It uses a single URLClassLoader for each JSP page,
> this allowed
> me to simplify a great deal how Jasper handles
> generation of class
> and package names (no more need to do incremental
> .java and .class files).
> And it removed alot of overhead at both JSP
> translation and runtime
> when Jasper tries to figure out which incremental
> class file to use/check.
> This sped up JSP compiles by 33% and runtime
> execution by 25%.
> 

The refactoring I propose would indeed use one
class-loader per page.  My current implementation does
this leveraging a subclass of JasperLoader but I'll
explore using URLClassLoader.  I would need to make
sure that it is compatible with jdk1.1 (a tc3.3
requirement) so if I used URLClassLoader, I'd need to
provide a jdk1.1 replacement ala the way tomcat
startup does.  This actually should be pretty easy
since I'm getting the loader via a factory method.

> And before you ask, I just don't have the time to
> back port these
> changes in TC3.3.
> 

Don't worry - I totally understand this!  :-)

mel

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Glenn Nielsen <gl...@voyager.apg.more.net>]

I have made some changes to the Jasper code in Tomcat 4 that
you might want to look at.

1.  In general the Java SecurityManager implemenation in Tomcat 4
and Jasper has significant improvements and is much cleaner.

2.  Jasper class loading is much simpler in the Tomcat 4 version.
It uses a single URLClassLoader for each JSP page, this allowed
me to simplify a great deal how Jasper handles generation of class
and package names (no more need to do incremental .java and .class files).
And it removed alot of overhead at both JSP translation and runtime
when Jasper tries to figure out which incremental class file to use/check.
This sped up JSP compiles by 33% and runtime execution by 25%.

And before you ask, I just don't have the time to back port these
changes in TC3.3.

Regards,

Glenn

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/

-- 
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cm...@yahoo.com]

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/
>