> Date: Wed, 22 Jan 2003 13:20:48 -0600 > From: Glenn Nielsen <[EMAIL PROTECTED]> > Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java > To: Tomcat Developers List <[EMAIL PROTECTED]> > > > > Kin-Man Chung wrote: > > See below. > > > > > >>Date: Wed, 22 Jan 2003 19:03:08 +0100 > >>From: Remy Maucherat <[EMAIL PROTECTED]> > >>Subject: Re: cvs commit: > > > > jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java > > > >>To: Tomcat Developers List <[EMAIL PROTECTED]> > >> > >>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 [EMAIL PROTECTED] | /* Spelin donut madder | > MOREnet System Programming | * if iz ina coment. | > Missouri Research and Education Network | */ | > ---------------------------------------------------------------------- > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
