I agree with Craig.
The ability to run JSP apps without any source JSPs must be maintained
for app vendors who want to ship without source code. Not sure if this
patch would interfere with that or not.
A separate issue: if a user removes the source JSP, it may be OK to
remove the JSP class file, but what about the class loaded in memory
(assuming the server was running when the JSP was deleted)? To be
consistent you would have to unload that JSP class, and possibly any
associated objects (depending how JavaBeans and JSP are loaded in
classloaders in Tomcat). For example, if an application scope bean were
loaded by that JSP, would that bean be dumped with the classloader for
that JSP or not?
This reminds me of a performance feature that would be nice in Tomcat,
but I don't know if is already implemented -- adding a flag that users
can set to disable runtime checking of JSP source files. Every time you
check the class and source last-modified times you incurr a little
overhead, unnecessary for production servers.
Scott Stirling
West Newton, MA
On 05 Jan 2001 14:14:15 -0600, Glenn Nielsen wrote:
> The original PR 698:
>
> >Synopsis:
> >tomcat still allows viewing of a jsp even after the jsp file has been removed from
>webspace.
>
> If a JSP page is removed from a web application, there is clear intent that the page
> is no longer desired, Jasper has to do a check to see if the page needs to be
>recompiled
> before executing the servlet class, if the JSP page no longer exists it should
>return a
> 404
> instead of executing the generated servlet class, IMHO.
>
> Regards,
>
> Glenn
>
> "Craig R. McClanahan" wrote:
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > marcsaeg 01/01/05 10:04:37
> > >
> > > Modified: src/share/org/apache/jasper/compiler Tag: tomcat_32
> > > Compiler.java
> > > Log:
> > > Added a method to remove the generated .class file. This will be called
> > > to remove generated files in the event that the associated JSP page is removed.
> > > PR: 698
> > >
> >
> > Note that the JSP spec is silent on this topic (as is the servlet spec for the
>case where you remove a servlet class after it has been
> > loaded). Hence, this change is a Tomcat-specific feature. Application developers
>who rely on it to operate portably are going to be
> > surprised when other servlet containers may or may not act the same way.
> >
> > For that reason, I would suggest we don *not* make this change.
> >
> > Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
