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.
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.
[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.
And yes, to answer the obvious question, I don't expect someone else to fix
this for me.
-----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]
