tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper
Date Wed, 07 Feb 2001 19:53:29 GMT
Steve Downey wrote:
> Placing all generated servlet classes into the same package only works if
> the loader cooperates. If the container does not use a separate, special,
> classloader for each page, it will not be able to distinguish the different
> instances of MyJSP.class, or in my case of index.class.

JSP pages are portable between containers and JSP engines.  But there is no
requirement that a runtime servlet compiled by a specific JSP engine be
with other JSP engines.  The class loading for a compiled jsp page is done by
jasper for a page compiled by jasper.

> That implies that the command line compiler must produce distinguishable
> class names for each jsp that is produced, as it is a requirement that the
> servlet class be portable among containers, as long as support classes the
> jsp implementation depends on are packaged in the WAR file (section 2.1.5
> Compiling JSP Pages). The interface contract is supposed to be the only
> dependency between the container and the servlet.

It still can, just tell JspC what package to put the generated servlets in
on the command line.

> Following on to this, I would prefer that the classes that the command line
> compiler and the runtime compiler, differ as little as possible. It should
> be possible to make them identical. That way, the code that is developed and
> tested can be identical to the code that is shipped to QA and to production.

It doesn't matter what package jasper puts compiled runtime servlets in, it is
all internal to jasper.



> -----Original Message-----
> From: Glenn Nielsen []
> Sent: Tuesday, February 06, 2001 9:48 PM
> To:
> Subject: Re: cvs commit:
> jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper
> Mel Martinez wrote:
> >
> > The package naming solution I've opt'ed for in my own
> > enhancement to Jasper (which I'll gladly share) is to
> > derive package names that are related to the location
> > of the jsp relative to the server context.  This is
> > simple, flexible and should avoid collisions.
> >
> There is no need for all this complexity to generate a package name
> in the new Jasper.  The way jasper now loads jsp pages, each page is
> completely isolated from all other pages.  Every jsp page compiled
> could be a class named "org.apache.jsp.MyJSP" without
> any concern whatsoever about conflicts because each individual page
> has its own class loader.  I will modify the current jasper class loader
> to support putting the jsp pages in a package, but this is just to comply
> with the JSP 1.2 spec.
> All of the previous code in jasper to do all the package and class name
> mangling was to overcome the limitations of how the Jasper class loader
> for jsp pages was designed.
> The new jasper makes it very easy to find and view the java source for
> a translated jsp page, it is located in
> work/somehost/someapp/some/context/path/
> Regards,
> Glenn
> ----------------------------------------------------------------------
> Glenn Nielsen    | /* Spelin donut madder    |
> MOREnet System Programming               |  * if iz ina coment.      |
> Missouri Research and Education Network  |  */                       |
> ----------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:
> <><><><><><><><><><><><><><><><><><><><><>This
electronic mail transmission
> may contain confidential information and is intended only for the person(s)
> named.  Any use, copying or disclosure by any other person is strictly
> prohibited.  If you have received this transmission in error, please notify
> the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

Glenn Nielsen    | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |

View raw message