You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2001/01/05 19:04:37 UTC
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
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
Revision Changes Path
No revision
No revision
1.19.2.4 +19 -3 jakarta-tomcat/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.19.2.3
retrieving revision 1.19.2.4
diff -u -r1.19.2.3 -r1.19.2.4
--- Compiler.java 2000/12/22 14:19:12 1.19.2.3
+++ Compiler.java 2001/01/05 18:04:36 1.19.2.4
@@ -1,7 +1,7 @@
/*
- * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/Compiler.java,v 1.19.2.3 2000/12/22 14:19:12 pierred Exp $
- * $Revision: 1.19.2.3 $
- * $Date: 2000/12/22 14:19:12 $
+ * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/Compiler.java,v 1.19.2.4 2001/01/05 18:04:36 marcsaeg Exp $
+ * $Revision: 1.19.2.4 $
+ * $Date: 2001/01/05 18:04:36 $
*
* ====================================================================
*
@@ -374,6 +374,22 @@
}
return null;
}
+
+ /**
+ * Remove generated files
+ */
+ public void removeGeneratedFiles()
+ {
+ try{
+ // XXX Should we delete the generated .java file too?
+ String classFileName = mangler.getClassFileName();
+ if(classFileName != null){
+ File classFile = new File(classFileName);
+ classFile.delete();
+ }
+ }catch(Exception e){
+ }
+ }
}
Re: cvs commit:
jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
"Scott M. Stirling" wrote:
> On 05 Jan 2001 16:35:09 -0800, Hans Bergsten wrote:
> > "Scott M. Stirling" wrote:
> > > 1. Doesn't it seem a bit sloppy to leave a bunch of classes loaded that
> > > will never get dumped unless the server is shutdown? Just a matter of
> > > elegance, I suppose.
>
> [Hans Bergsten]
>
> > Yes, it does. But AFAIK there's no way you can just unload a class
> > from the JVM; you would have to drop the class loader for the
> > context and reload all classes that are still valid. That doesn't
> > seem like the right thing to do in this situation IMHO.
>
> It depends how class loading in Tomcat works. I'm familiar with JRun
> 3.0, which works like this (I'm not giving away any family secrets, this
> stuff is documented in various places in Allaire docs):
>
I'm not giving away family secrets either ... it's all out there in the source
code :-)
>
> - servlets & JavaBeans (even those called by JSPs) - loaded by a
> classloader with web-app scope. If a single servlet changes, the whole
> web-app's classloader is dumped so the servlet can be dynamically
> reloaded. No need to actively reload the other classes that got dumped
> with the classloader. They'll be reloaded as needed when requests come
> in for them.
>
Tomcat does pretty much the same thing. How reload checking is implemented
depends on which version you're talking about (assuming you've marked your app
for reload checking):
* Tomcat 3.2 - on each request, it checks the servlet you asked
for, and reloads the entire webapp if it's been updated. This is
why it sometimes misses changes to bean classes.
* Tomcat 4.0 - a background thread checks for updated classes
(default interval is 15 seconds), and reloads the wbapp if any have
been changed.
In neither case are classes loaded from the shared library directory
($CATALINA_HOME/lib), or any higher-level classloader, checked for updates. The
reason is that we cannot throw those classes away anyway, without throwing away
*all* of the current webapps.
When Tomcat reloads a webapp, it also attempts to save all the current sessions
(and their attributes, if they are Serializable) and reloads them again. This
is necessary because the bean classes were loaded by the "old" webapp class
loader, so attempting to reference them from a bean class loaded by the "new"
webapp class loader (after the reload has been completed) would cause a
ClassCastException (even though the class names are the same).
>
> - JSPs are each loaded in their own classloader. So if a JSP is changed
> and reloaded, the old classloader is dumped and a new one created.
> JavaBeans are delegated to the web-app classloader, for whatever reason.
>
Jasper does the same, and makes the webapp classloader the parent of the JSP
page classloader so that a page can reference beans and other classes known only
to the webapp. For Tomcat 3.2, which has to run under JDK 1.1, the Java2
delegation model is essentially faked by custom ClassLoader implementations to
reproduce the "parent" relationship.
Jasper also plays some wierd games with the classnames of the generated pages --
this is an area I think needs to be cleaned up in the 4.1 time frame, as Jasper
is migrated to using Java2 facilities directly (because servlet 2.3 and JSP 1.2
require a Java2 platform).
>
> All this may change in future versions, when JRun reloads tag handlers
> dynamically. I have no idea how Tomcat handles these classloader
> issues, but it would be interesting to hear about if anyone can distill
> it briefly.
>
Right now, Tomcat will treat changes to tag library classes just like it does to
bean or servlet classes, and chucks the whole webapp. It might be worth looking
at whether you can get away with doing less than that for tags.
>
>
> --
> Scott Stirling
> West Newton, MA
>
Craig McClanahan
Re: cvs commit:
jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"Scott M. Stirling" wrote:
>
> On 05 Jan 2001 16:35:09 -0800, Hans Bergsten wrote:
> > "Scott M. Stirling" wrote:
> > > 1. Doesn't it seem a bit sloppy to leave a bunch of classes loaded that
> > > will never get dumped unless the server is shutdown? Just a matter of
> > > elegance, I suppose.
>
> [Hans Bergsten]
>
> > Yes, it does. But AFAIK there's no way you can just unload a class
> > from the JVM; you would have to drop the class loader for the
> > context and reload all classes that are still valid. That doesn't
> > seem like the right thing to do in this situation IMHO.
>
> It depends how class loading in Tomcat works. I'm familiar with JRun
> 3.0, which works like this (I'm not giving away any family secrets, this
> stuff is documented in various places in Allaire docs):
>
> - servlets & JavaBeans (even those called by JSPs) - loaded by a
> classloader with web-app scope. If a single servlet changes, the whole
> web-app's classloader is dumped so the servlet can be dynamically
> reloaded. No need to actively reload the other classes that got dumped
> with the classloader. They'll be reloaded as needed when requests come
> in for them.
>
> - JSPs are each loaded in their own classloader. So if a JSP is changed
> and reloaded, the old classloader is dumped and a new one created.
> JavaBeans are delegated to the web-app classloader, for whatever reason.
>
> All this may change in future versions, when JRun reloads tag handlers
> dynamically. I have no idea how Tomcat handles these classloader
> issues, but it would be interesting to hear about if anyone can distill
> it briefly.
>
Tomcat has a webapp classloader and Jasper has a class loader for JSP pages.
The webapp classloader is caching everything loaded from the WEB-INF/classes
or WEB-INF/lib directories.
Since Jasper is running within the web app, if the webapp context gets
reloaded, jasper gets reloaded. Jasper IMHO is convoluted in the way
it loads JSP's. It munges the names when creating the java source and
class, and increments each of these files each time the JSP is compiled.
All those old versions of the classes stay resident in the Jasper
class loader and all the old java and class files clutter up the work dir.
While I am implementing the Java SecurityManager in Tomcat 4 I am also
going to cleanup how Jasper loads classes so that there is one URLClassLoader
per JSP page. And that URLClassLoader gets reinstantiated when the JSP
page gets recompiled.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: cvs commit:
jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
Posted by "Scott M. Stirling" <ss...@mediaone.net>.
On 05 Jan 2001 16:35:09 -0800, Hans Bergsten wrote:
> "Scott M. Stirling" wrote:
> > 1. Doesn't it seem a bit sloppy to leave a bunch of classes loaded that
> > will never get dumped unless the server is shutdown? Just a matter of
> > elegance, I suppose.
[Hans Bergsten]
> Yes, it does. But AFAIK there's no way you can just unload a class
> from the JVM; you would have to drop the class loader for the
> context and reload all classes that are still valid. That doesn't
> seem like the right thing to do in this situation IMHO.
It depends how class loading in Tomcat works. I'm familiar with JRun
3.0, which works like this (I'm not giving away any family secrets, this
stuff is documented in various places in Allaire docs):
- servlets & JavaBeans (even those called by JSPs) - loaded by a
classloader with web-app scope. If a single servlet changes, the whole
web-app's classloader is dumped so the servlet can be dynamically
reloaded. No need to actively reload the other classes that got dumped
with the classloader. They'll be reloaded as needed when requests come
in for them.
- JSPs are each loaded in their own classloader. So if a JSP is changed
and reloaded, the old classloader is dumped and a new one created.
JavaBeans are delegated to the web-app classloader, for whatever reason.
All this may change in future versions, when JRun reloads tag handlers
dynamically. I have no idea how Tomcat handles these classloader
issues, but it would be interesting to hear about if anyone can distill
it briefly.
--
Scott Stirling
West Newton, MA
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
Compiler.java
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Scott M. Stirling" wrote:
>
> OK, I am thinking this is a pretty good idea now too, since seeing your
> and Marc's emails. My last two thoughts on the matter (just playing Devil's
> advocate):
That's good. It's easy to overlook some problems.
> 1. Doesn't it seem a bit sloppy to leave a bunch of classes loaded that
> will never get dumped unless the server is shutdown? Just a matter of
> elegance, I suppose.
Yes, it does. But AFAIK there's no way you can just unload a class
from the JVM; you would have to drop the class loader for the
context and reload all classes that are still valid. That doesn't
seem like the right thing to do in this situation IMHO.
> 2. What unforseen problems might arise in a large application with
> interdependencies, such as included files that are overlooked -- if an
> included file is deleted but the includer is not, what happens?
If it's included with the JSP directive, the includer will still
exist and be served, since the directive include works at translation
time. Tomcat (Jasper) doesn't keep track of the relationship to
included files, so it's similar to what happens if you change the
included file; nothing ;-)
If it's included using the JSP include action, a request for the
includer will fail, hopefully with a 404-like message. It's the
same as if you use an include action to include a JSP page or
servlet that has never existed.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: cvs commit:
jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
Posted by "Scott M. Stirling" <ss...@mediaone.net>.
OK, I am thinking this is a pretty good idea now too, since seeing your and Marc's emails. My last two thoughts on the matter (just playing Devil's advocate):
1. Doesn't it seem a bit sloppy to leave a bunch of classes loaded that
will never get dumped unless the server is shutdown? Just a matter of
elegance, I suppose.
2. What unforseen problems might arise in a large application with
interdependencies, such as included files that are overlooked -- if an
included file is deleted but the includer is not, what happens?
--
Scott Stirling
West Newton, MA
On 05 Jan 2001 15:58:07 -0800, Hans Bergsten wrote:
> Scott Stirling wrote:
> >
> > 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.
>
> It shouldn't; if you want to distribute JSP pages without source,
> you compile them to servlet classes and add mappings for the
> paths to the servlets in web.xml. The spec may be vague on this,
> but that's still what I believe is the recommendation stated in
> the section about precompilation.
>
> > 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,
>
> Not necessarily unload, but remove all internal (automatic) mappings
> so that a request for the JSP always results in a 404.
>
> > 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?
>
> Hmmm... I think that's overkill.
>
> Hans
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
Compiler.java
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Scott Stirling wrote:
>
> 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.
It shouldn't; if you want to distribute JSP pages without source,
you compile them to servlet classes and add mappings for the
paths to the servlets in web.xml. The spec may be vague on this,
but that's still what I believe is the recommendation stated in
the section about precompilation.
> 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,
Not necessarily unload, but remove all internal (automatic) mappings
so that a request for the JSP always results in a 404.
> 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?
Hmmm... I think that's overkill.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
RE: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
Posted by Marc Saegesser <ma...@apropos.com>.
> -----Original Message-----
> From: Scott Stirling [mailto:sstirling@mediaone.net]
> Sent: Friday, January 05, 2001 3:58 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: cvs commit:
> jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
>
>
> 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.
To deploy an app without the JSP source using Tomcat involves the following
steps (taken from Hans Bergsten's excellent O'Reilly book):
1) Compile the .jsp files into servlets
2) Copy the .class files into the apps WEB-INF/classes directory. The
filenames for the class files need to be altered to match the name of the
actual class included in them.
3) Edit the app's web.xml to map url-patterns for the JSPs into the
appropriate servlet class.
Step 3 is the key. Because we're mapping the urls directly to a servlet we
bypass Jasper completely. There is no timestamp checking, if the servlet
class doesn't exist no attempt will be made to translate a .jsp (you'll just
get a 500 error), etc.
Also note that deploying a WAR like this is not portable across JSP
containers (possibly even different version of the same container).
> 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?
Actually, the JSP servlet class will still be loaded it just won't ever be
executed. Any associated classes will remain in memory and any instances of
them will remain. Other pages that reference these classes will continue
work as expected.
Re: cvs commit:
jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
Posted by Scott Stirling <ss...@mediaone.net>.
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:
> >
> > marcsaeg@apache.org 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
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
Compiler.java
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
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:
>
> marcsaeg@apache.org 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
Compiler.java
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Marc Saegesser wrote:
> The problem with that is that there is then *no* way to get rid of a JSP
> page without manually deleting the .class files. This requires knowing
> where they are stored *and* the class name mangling scheme. Neither of
> these are intuitively obvious.
>
> The *only* thing that the JSP developer really knows about is the .jsp file
> he created (and maybe removes). Forcing him to know the internal details of
> how a .jsp is turned into a .class doesn't seem right.
>
> Since the spec is silent there is no absolutely correct implementation,
> however, returning a 404 after the .jsp is removed seems much more intuitive
> then the alternative. It already bit one user and know I'll get calls from
> my customers with the previous implementation.
>
Thinking further, that makes more sense. Change my "sorta -0" vote to a +1.
>
> I'll send a note to jsp-spec-comments@eng.sun to see if this can be
> clarified JSP1.2.
>
I already asked as well :-), but that's exactly the right thing to do.
Craig
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> > Sent: Friday, January 05, 2001 1:16 PM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: cvs commit:
> > jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
> >
> >
> > marcsaeg@apache.org 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: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
RE: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
Posted by Marc Saegesser <ma...@apropos.com>.
The problem with that is that there is then *no* way to get rid of a JSP
page without manually deleting the .class files. This requires knowing
where they are stored *and* the class name mangling scheme. Neither of
these are intuitively obvious.
The *only* thing that the JSP developer really knows about is the .jsp file
he created (and maybe removes). Forcing him to know the internal details of
how a .jsp is turned into a .class doesn't seem right.
Since the spec is silent there is no absolutely correct implementation,
however, returning a 404 after the .jsp is removed seems much more intuitive
then the alternative. It already bit one user and know I'll get calls from
my customers with the previous implementation.
I'll send a note to jsp-spec-comments@eng.sun to see if this can be
clarified JSP1.2.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: Friday, January 05, 2001 1:16 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: cvs commit:
> jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
>
>
> marcsaeg@apache.org 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
Compiler.java
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
marcsaeg@apache.org 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