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?

> 
> --
> 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]>

Reply via email to