Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java

["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