Steve Downey wrote:
>
> I've been looking at Jasper because it is severly broken on NT, or any other
> filesystem that has limited length filenames. The prefix encoding of the
> servlet path extends the filename of the .java and .class files well past
> the limit. This is actually preventing me from using Tomcat in developement
> and production right now.
>
> Putting all of the files in the unnamed package worries me. For the reasons
> that Craig mentioned, as well as the unforseen side effects, since the
> unnamed package is imported by default.
>
> Also, I suspect that it further diverges the behaviour of the
> CommandLineCompiler and the JSPCompiler.
These are for two different purposes and already are signicantly different.
>
> The CommandLineCompiler is supposed to produce classes that, with some
> additional support classes, can be installed in any servlet container. If
> all of the classes are in the same package, namespace collisions are an
> issue. The prefix mangling is an attempt to get around the collision
> problem. However, it is working against the language itself. The Java
> mechanism for distinguishing classes is the package mechanism. Avoiding
> packages because they require opening directories, and opening directories
> is inefficient, is somewhat perverse, and is the direct cause of [for me] a
> show stopping bug.
>
I am still working on JspC, but its ability to put the generated servlet
classes in a package will be retained.
The class name mangling was needed to get around the problem of Jasper
having one single class loader for ALL jsp pages in a web app context.
This is not a problem in the new jasper because each individual jsp page
has its own URLClassLoader designed to only allow loading of that pages
JSP servlet, all other class load requests are delegated to the parent
class loader. This way their is no possiblity of any class naming collisions.
If jasper were using the default java class loader then the naming collison
problems you mentioned would be a concern.
> [eg
> ./workflow/mynetfolio/openorders/openordersdetails/openorder_detail_cancel_c
> ontent.jsp
> turns into
>
> C:\netbeans\temp\jspwork\1c7b23dd\workflow\mynetfolio\openorders\openordersd
> etails\_0002fworkflow_0002fmynetfolio_0002fopenorders_0002fopenordersdetails
> _0002fopenorder_0005fdetail_0005fcancel_0005fcontent_0002ejspopenorder_0005f
> detail_0005fcancel_0005fcontent_jsp_0.java
> which overflows the 256 char path limit
> ]
> [Don't bother discussing the various ways the NT file system is brain
> damaged. I'll agree, but it doesn't fix my problem <g>]
>
> Getting back to Glenn's work. I believe that the classes generated need to
> be in a package related to the path the jsp was compiled from. It's the most
> natural mapping, and works around the mangling except in perverse borderline
> cases.
>
There can be problems with using the context directory path.
What if you have the context /examples with the following jsp
/examples/org/apache/catalina/some.jsp? It would want to put the
jsp in the same package as org.apache.catalina, this is a security problem.
> And yes, to answer the obvious question, I don't expect someone else to fix
> this for me.
The new Jasper does fix this for you.
>
> -----Original Message-----
> From: Glenn Nielsen [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 25, 2001 5:46 PM
> To: [EMAIL PROTECTED]
> Subject: Tomcat 4 Jasper ClassLoading changes to support SecurityManager
>
> In order to make it easier to integrate the SecurityManager into Jasper
> for Tomcat 4 and to change some of Japsers annoying behaviours, I have
> been working on switching Jasper over to the URLClassLoader.
>
> I have the class loading changes in place and Jasper passes all watchdog
> tests. I wanted to run these changes past everyone before I finish
> cleaning up the changes and committing it. (I still have some work to
> do on JspC and still need to add support for the SecurityManager.)
>
> Jasper now creates a URLClassLoader for each JSP page and defers any other
> class loading to the web app context class loader. Using a single class
> loader per JSP allowed me to remove all the code that increments the
> class version number, i.e. the work directory no longer has multiple
> *.java and *.class files for the same JSP page. These changes also made
> it easy for me to put the java source and class files in the same directory
> tree as found in the web app context. When Jasper is run in a servlet
> container it no longer puts the class files in a package, they are now
> in the default package.
>
> These changes simplified the code quite a bit and also gave a performance
> improvement.
>
> When running watchdog tests the new jasper was ~25% faster than the current
> jasper on a first compile or on first jsp class access after restart.
> On recompile of a jsp page it was 37% faster. Execution of JSP servlet
> after it had already been compiled and loaded was slightly faster.
>
> Regards,
>
> Glenn
>
> ----------------------------------------------------------------------
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> <><><><><><><><><><><><><><><><><><><><><>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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
