You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Steve Downey <st...@netfolio.com> on 2001/01/26 17:32:40 UTC
RE: Tomcat 4 Jasper ClassLoading changes to support SecurityManag
er
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:glenn@voyager.apg.more.net]
Sent: Thursday, January 25, 2001 5:46 PM
To: tomcat-dev@jakarta.apache.org
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 glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
<><><><><><><><><><><><><><><><><><><><><>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. <><><><><><><><><><><><><><><><><><><><><>
Re: Tomcat 4 Jasper ClassLoading changes to support SecurityManager
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
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:glenn@voyager.apg.more.net]
> Sent: Thursday, January 25, 2001 5:46 PM
> To: tomcat-dev@jakarta.apache.org
> 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 glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
> <><><><><><><><><><><><><><><><><><><><><>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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------