tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kin-Man Chung <Kin-Man.Ch...@Eng.Sun.COM>
Subject Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
Date Wed, 22 Jan 2003 21:13:04 GMT

> Date: Wed, 22 Jan 2003 13:20:48 -0600
> From: Glenn Nielsen <glenn@mail.more.net>
> Subject: Re: cvs commit: 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
> To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> 
> 
> 
> Kin-Man Chung wrote:
> > See below.
> > 
> > 
> >>Date: Wed, 22 Jan 2003 19:03:08 +0100
> >>From: Remy Maucherat <remm@apache.org>
> >>Subject: Re: cvs commit: 
> > 
> > jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
> > 
> >>To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> >>
> >>Costin Manolache wrote:
> >>
> >>>Remy Maucherat wrote:
> >>>
> >>>Then why not default to the context path ?
> >>
> >>Can you give examples ? It's very hard to determine the context path 
> >>from JSPC IMO.
> >>
> >>
> >>>I think the naming conventions for the generated servlets should be 
> >>>settled down, documented - and treated as APIs ( i.e. no change unless 
> >>>absolutely needed ).
> >>
> >>Ok, but in the meantime, we must not allow non packaged classes.
> >>
> >>
> >>>>>When I wrote my patch, I also felt that a default package prefix
was
> >>>>>a good idea, but I dropped it in the end due to the package/directory
> >>>>>structure mismatch. If it's really important to, you should also
make
> >>>>>sure the class files are generated in a directory structure that
starts
> >>>>>with "org/apache/jsp/"
> >>>>
> >>>>I was wondering about that, actually, and thought this was inconsistent.
> >>>
> >>>
> >>>JSPC does generate the right package directory structure. I think 
JspServlet
> >>>should do the same - if it doesn't already.
> >>
> >>Well, I don't think we care. JspServlet generates in the workdir, and 
> >>uses one CL per page. So packaging is not relevant IMO.
> >>OTOH, JSPC may generate the classes in /WEB-INF/classes, so we would 
> >>need to create the full package structure. I'd like to point out that 
> >>you admin precompilation example does include an extra "admin" subfolder 
> >>in the output directory path.
> >>
> >>Remy
> >>
> > 
> > 
> > Well, there is one case that generating the classes with the same package
> > name would cause problem, and that is when you have two JSP pages with the
> > same file name (but in different directories).  Still not a problem in
> > class loading, since the class files are placed in different directories,
> > but you cannot debug them anymore since you cannot identify the classes by
> > name - they have the same name.
> > 
> > Anyone knows why it was done this way?
> > 
> 
> I did some refactoring of the JasperClassLoader and the package naming
> over a year ago.  The code for all this in Jasper had been very convoluted
> and added a great deal of overhead.  The refactoring improved runtime JSP
> performance by 33% and compilation by 25%.  If you search the tomcat-dev
> archives you can find the detailed description of what was changed and why.
> 
> I am -1 for changing the default package name for JSP pages compiled at 
runtime
> from org.apache.jsp to something else until all the implication of doing this
> are thought through.
> 
Agreed.  But I don't think changing the package name to one that reflects
the directory structure of the jsp files is going to have much performance
impact.

> Jean-Francois mentioned that there are SecurityManager issues related to
> changing the package name.
> 

Yea, I saw.  And having an unique package name seems to solve that too.

> Glenn
> 
> 
> 
> ----------------------------------------------------------------------
> Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
> MOREnet System Programming               |  * if iz ina coment.      |
> Missouri Research and Education Network  |  */                       |
> ----------------------------------------------------------------------
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message