You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Bill Barker <wb...@wilshire.com> on 2002/05/25 08:00:15 UTC

[PROPOSAL] Change to the 3.3 API

I'd like to add a new method (for now called 'preInitCheck') to the API to
be called before the check for calling the init method.  The current
JspInterceptor.requestMap would be split between the new preInitCheck method
(which would handle the compile), and the requestMap (which would register
the servlet).  In light of bug #7654, we may want to have a 'preInitCheck'
and 'postInitCheck', but I'm still not convinced on how important this case
is.

This is a proposal, since there was a consensus to freeze the API.  I'm not
looking for people to help (although volunteers are always welcome), since
the changes are simple enough.  The only known bug that this fixes is the
rather obscure one that currently a JSP page that is accessed from a
NamedDispatcher will not be re-compiled.  More importantly (IMHO), this will
separate the JSP logic from ServletHandler and put it firmly into
JspInterceptor where it belongs.

Of course, I'm expecting that Pier will veto this on the grounds that he
can't be bothered to keep up with the 3.3 development. ;-)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PROPOSAL] Change to the 3.3 API

Posted by co...@covalent.net.
+1. 

Adding new methods is perfectly fine and backward compatible.

BTW, my proposal to freeze the API was based on the fact that 
I felt it is good enough and I couldn't think any significant improvement
that would be worth the change. 
 
If you think different or have some good ideas - we can reopen the 
issue ( but I would like to keep backward compat as long as 
possible ).

Costin

On Fri, 24 May 2002, Bill Barker wrote:

> I'd like to add a new method (for now called 'preInitCheck') to the API to
> be called before the check for calling the init method.  The current
> JspInterceptor.requestMap would be split between the new preInitCheck method
> (which would handle the compile), and the requestMap (which would register
> the servlet).  In light of bug #7654, we may want to have a 'preInitCheck'
> and 'postInitCheck', but I'm still not convinced on how important this case
> is.
> 
> This is a proposal, since there was a consensus to freeze the API.  I'm not
> looking for people to help (although volunteers are always welcome), since
> the changes are simple enough.  The only known bug that this fixes is the
> rather obscure one that currently a JSP page that is accessed from a
> NamedDispatcher will not be re-compiled.  More importantly (IMHO), this will
> separate the JSP logic from ServletHandler and put it firmly into
> JspInterceptor where it belongs.
> 
> Of course, I'm expecting that Pier will veto this on the grounds that he
> can't be bothered to keep up with the 3.3 development. ;-)
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>