You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Glenn Nielsen <gl...@voyager.apg.more.net> on 2000/05/22 00:50:23 UTC
Proposal: Jasper, JspLoader, SecurityManager and class names/loading
I have made good progress implementing a SecurityManager for Tomcat.
The SecurityManager is working great with servlets.
But I have run into some problems implementing a SecurityManager with
Jasper. The work is being done using the Tomcat 3.1 release version.
Jasper itself, because it is loaded as a servlet, uses the Tomcat
AdaptiveClassLoader.
The jasper JspLoader will first attempt to load a class using the
parent ClassLoader (great), in this case the AdaptiveClassLoader
which already has support for the SecurityManager built in.
So the easiest solution for implementing a SecurityManager for Jasper
(or any other JSP engine servlet), is to let the parent ClassLoader
(AdaptiveClassLoader) handle loading of JSP classes.
AdaptiveClassLoader has had the Context workDir added to its Class
repository so that it can find and load JSP classes.
The problem is that Jasper does not use the correct class name
when it calls loadClass(), ( it does some string manipulations to
construct a class name within JspLoader.findClass() ) and it does
not follow Class directory conventions when compiling JSP class files.
As an example, for the following Context
<Context path="/test" docBase="webapps/test" debug="0" reloadable="true" >
when Jasper compiles the file test/jsp/classTest.jsp it creates the
following class heirarchy in work/localhost_8080%2Ftest
$ ls -1R
_0002fjsp_0002fclassTest_0002ejspclassTest.class
_0002fjsp_0002fclassTest_0002ejspclassTest_jsp_0.java
jsp
jsp:
_0002fjsp_0002fclassTest_0002ejspclassTest_jsp_0$JSPTest$Inner.class
_0002fjsp_0002fclassTest_0002ejspclassTest_jsp_0$JSPTest.class
But the class _0002fjsp_0002fclassTest_0002ejspclassTest.class in
work/localhost_8080%2Ftest is in package jsp, yet it is in the root
of the directory, not in the jsp sub directory. This prevents the
parent class loader from ever being able to load the above class.
Unless you modified AdaptiveClassLoader to understand how Jasper
manipulates class names (Not worth considering).
This means that all JSP's compiled into servlets would reside in a
single flat directory, instead of in a normal class sub directory tree,
and a parent ClassLoader could never load the JSP class files.
PROPOSAL:
Modify Jasper so that JSP's located in subdirectories of the docBase
are compiled and placed into packages and sub directories in workDir
following normal class directory conventions.
And once the above is accomplished, Jasper may not need its own
ClassLoader.
I can't think of any downside to making this change. But there may be
historical reasons I am not aware of for this design.
Implementing the proposed change to Jasper will make implementing
a SecurityManager which works with JSP much simpler.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Proposal: Jasper, JspLoader, SecurityManager and class names/loading
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
I no longer need to change the Jasper JspLoader in order to implement
a SecurityManager with Tomcat.
The problem I was having is that when using a SecurityManager
the ClassLoader when doing defineClass() has to pass the security
ProtectionDomain. Since Jasper is supposed to be seperate from Tomcat,
I saw no easy way for Jasper to know what the ProtectionDomain was.
Hence, I wanted to modify Jasper so that it would defer to the
parent ClassLoader, and let the parent ClassLoader which knows about
what ProtectionDomains to apply when calling defineClass() load the
JSP class.
I found a simple way to add conditional support to Jasper so that
it knows what ProtectionDomain to apply when doing defineClass().
It uses a Context Attribute to get the ProtectionDomain.
The changes are relatively minor and should allow Jasper to still
work with JDK1.1 and without a SecurityManager being used.
My current focus is implementing a SecurityManager, not changing
Jasper class naming/loading. The more I looked at Jasper, the
JspLoader, etc. the less enthused I was about changing how it
currently works. I would still like to see the below change made
to Jasper, but it can wait for another time.
Regards,
Glenn
After diving into the Jasper code,
Anil Vijendran wrote:
>
> Glenn Nielsen wrote:
>
> > As an example, for the following Context
> >
> > <Context path="/test" docBase="webapps/test" debug="0" reloadable="true" >
> >
> > when Jasper compiles the file test/jsp/classTest.jsp it creates the
> > following class heirarchy in work/localhost_8080%2Ftest
> >
> > $ ls -1R
> > _0002fjsp_0002fclassTest_0002ejspclassTest.class
> > _0002fjsp_0002fclassTest_0002ejspclassTest_jsp_0.java
> > jsp
> >
> > jsp:
> > _0002fjsp_0002fclassTest_0002ejspclassTest_jsp_0$JSPTest$Inner.class
> > _0002fjsp_0002fclassTest_0002ejspclassTest_jsp_0$JSPTest.class
> >
> > But the class _0002fjsp_0002fclassTest_0002ejspclassTest.class in
> > work/localhost_8080%2Ftest is in package jsp, yet it is in the root
> > of the directory, not in the jsp sub directory. This prevents the
> > parent class loader from ever being able to load the above class.
> > Unless you modified AdaptiveClassLoader to understand how Jasper
> > manipulates class names (Not worth considering).
> >
> > This means that all JSP's compiled into servlets would reside in a
> > single flat directory, instead of in a normal class sub directory tree,
> > and a parent ClassLoader could never load the JSP class files.
>
> My memory is fading about a lot of this stuff but here's what I can remember
> in terms of history.
>
> The parent class loader (servlet class loader) did not use to have the work
> directory as part of its classpath. That is why the parent classloader could
> not be used to load classes.
>
> Also there is one JSP class loader is per web app. There are more garbage
> classes (old classes that were updated because the JSP was modified) that are
> there in the JSP class loader than in the servlet class loader. It is
> important you don't keep them around for any stretch of time. By isolating
> JSP loading into a class loader that exists one per web app, if that web app
> is brought down, that loader would be garbage collected.
>
> The reason <workdir>/a/b/c/foobar_0.class is renamed to
> <workdir>/foobar.class is because I didn't want to search a directory at page
> request time to find out which is the most updated class. Instead I wanted to
> always be able to compare foobar.class with foobar.jsp and decide if it needs
> recompilation or not. (As you might have seen figuring out the actual class
> name is done by reading the class file, foobar.class...)
>
> I still am not clear why all this stuff affects implementing a
> SecurityManager. Can you explain more?
>
> Thanks.
>
> > PROPOSAL:
> >
> > Modify Jasper so that JSP's located in subdirectories of the docBase
> > are compiled and placed into packages and sub directories in workDir
> > following normal class directory conventions.
> >
> > And once the above is accomplished, Jasper may not need its own
> > ClassLoader.
> >
> > I can't think of any downside to making this change. But there may be
> > historical reasons I am not aware of for this design.
> >
> > Implementing the proposed change to Jasper will make implementing
> > a SecurityManager which works with JSP much simpler.
> >
> > Regards,
> >
> > Glenn
>
> --
> Peace, Anil +<:-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 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 | */ |
----------------------------------------------------------------------
Directory Listing
Posted by Trent Wheeler <tr...@ZeroG.com>.
I've scanned through the notes and the code, but I can't seem to answer this
question. I'd like to turn off the default directory listing behavior of
org.apache.tomcat.servlets.DefaultServlet (or simply turn off this servlet).
Is there some way to stop tomcat from returning directory lists?
Trent.
Re: Proposal: Jasper, JspLoader, SecurityManager and class names/loading
Posted by Anil Vijendran <An...@eng.sun.com>.
Glenn Nielsen wrote:
> As an example, for the following Context
>
> <Context path="/test" docBase="webapps/test" debug="0" reloadable="true" >
>
> when Jasper compiles the file test/jsp/classTest.jsp it creates the
> following class heirarchy in work/localhost_8080%2Ftest
>
> $ ls -1R
> _0002fjsp_0002fclassTest_0002ejspclassTest.class
> _0002fjsp_0002fclassTest_0002ejspclassTest_jsp_0.java
> jsp
>
> jsp:
> _0002fjsp_0002fclassTest_0002ejspclassTest_jsp_0$JSPTest$Inner.class
> _0002fjsp_0002fclassTest_0002ejspclassTest_jsp_0$JSPTest.class
>
> But the class _0002fjsp_0002fclassTest_0002ejspclassTest.class in
> work/localhost_8080%2Ftest is in package jsp, yet it is in the root
> of the directory, not in the jsp sub directory. This prevents the
> parent class loader from ever being able to load the above class.
> Unless you modified AdaptiveClassLoader to understand how Jasper
> manipulates class names (Not worth considering).
>
> This means that all JSP's compiled into servlets would reside in a
> single flat directory, instead of in a normal class sub directory tree,
> and a parent ClassLoader could never load the JSP class files.
My memory is fading about a lot of this stuff but here's what I can remember
in terms of history.
The parent class loader (servlet class loader) did not use to have the work
directory as part of its classpath. That is why the parent classloader could
not be used to load classes.
Also there is one JSP class loader is per web app. There are more garbage
classes (old classes that were updated because the JSP was modified) that are
there in the JSP class loader than in the servlet class loader. It is
important you don't keep them around for any stretch of time. By isolating
JSP loading into a class loader that exists one per web app, if that web app
is brought down, that loader would be garbage collected.
The reason <workdir>/a/b/c/foobar_0.class is renamed to
<workdir>/foobar.class is because I didn't want to search a directory at page
request time to find out which is the most updated class. Instead I wanted to
always be able to compare foobar.class with foobar.jsp and decide if it needs
recompilation or not. (As you might have seen figuring out the actual class
name is done by reading the class file, foobar.class...)
I still am not clear why all this stuff affects implementing a
SecurityManager. Can you explain more?
Thanks.
> PROPOSAL:
>
> Modify Jasper so that JSP's located in subdirectories of the docBase
> are compiled and placed into packages and sub directories in workDir
> following normal class directory conventions.
>
> And once the above is accomplished, Jasper may not need its own
> ClassLoader.
>
> I can't think of any downside to making this change. But there may be
> historical reasons I am not aware of for this design.
>
> Implementing the proposed change to Jasper will make implementing
> a SecurityManager which works with JSP much simpler.
>
> Regards,
>
> Glenn
--
Peace, Anil +<:-)
Re: Proposal: Jasper, JspLoader, SecurityManager and class names/loading
Posted by Danno Ferrin <sh...@earthlink.net>.
Hans Bergsten wrote:
>
> Glenn Nielsen wrote:
> > [...]
> > PROPOSAL:
> >
> > Modify Jasper so that JSP's located in subdirectories of the docBase
> > are compiled and placed into packages and sub directories in workDir
> > following normal class directory conventions.
> >
> > And once the above is accomplished, Jasper may not need its own
> > ClassLoader.
> >
> > I can't think of any downside to making this change. But there may be
> > historical reasons I am not aware of for this design.
> >
> > Implementing the proposed change to Jasper will make implementing
> > a SecurityManager which works with JSP much simpler.
>
> I would love for this change to be done, and would do it myself if I
> only had the time. In addition to the problem you like to solve with
> this change, it would also make it easier (possible?) to take all the
> generated JSP class files, put them in a JAR file, and add appropriate
> servlet mappings for all pages. This is great for distributing ready-made
> JSP based applications, especially on platforms with file name length
> limits (e.g. Mac), but it's tricky to do today due to the non-standard
> naming convention for the generated class files.
Actually jspc has most of this, all that is needed is to wire in the
compiler, have a flag to delete the source code, make it copy non jsp
stuff, and then wire up some stuff so that the servlet mapping created
by -webinc and -webxml get merged into the existing web.xml info. Not
too difficult if I could just get motivated to work with it after work
some day. (since the odds of a job existing in Colorado Springs that
would have me work on it at work are pretty low)
--Danno
> I'm also curious about why it wasn't implemented like this from the
> beginning. Please, Anil or Mandar (or someone else involved in the
> original implementation), can you give us the background and let us
> know if you see any problems with the proposed change?
>
> Hans
> --
> Hans Bergsten hans@gefionsoftware.com
> Gefion Software http://www.gefionsoftware.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Proposal: Jasper, JspLoader, SecurityManager and class names/loading
Posted by MANDAR RAJE <ma...@pathfinder.eng.sun.com>.
I agree that the current implementation of "computing the class
name" for the generated servlet and "JSP reloading" is somewhat
complicated and can be simplified. I like the idea of creating
directory structures based on package names and then using
AdaptiveClassLoader to load the servlets (instead os using the
JspLoader). This will make the class names lot shorter (don't
have to include the path information).
I have a couple of questions/concerns:
1) Will this not make Jasper completely Tomcat dependent? Right
now Jasper delegates work of loading Beans and TagHandlers to
Tomcat (which is fine given that they are part of a web-app).
But it loads the generated servlets itself (requires some
hack). If we were to generate classes in a way only
AdaptiveClassLoader could load, would it not make Japser difficult
to port across different Servlet containers?
2) How are we going to support JSP reloading? Right now the
JspLoader and the JspCompiler are inter-dependent for the class
name. The JspLoader is aware of the fact that the class
and class file don't have same names. We will need some other
mechanism to get it to work if we move away from the JspLoader.
Thanks,
Mandar.
Hans Bergsten wrote:
>
> Glenn Nielsen wrote:
> > [...]
> > PROPOSAL:
> >
> > Modify Jasper so that JSP's located in subdirectories of the docBase
> > are compiled and placed into packages and sub directories in workDir
> > following normal class directory conventions.
> >
> > And once the above is accomplished, Jasper may not need its own
> > ClassLoader.
> >
> > I can't think of any downside to making this change. But there may be
> > historical reasons I am not aware of for this design.
> >
> > Implementing the proposed change to Jasper will make implementing
> > a SecurityManager which works with JSP much simpler.
>
> I would love for this change to be done, and would do it myself if I
> only had the time. In addition to the problem you like to solve with
> this change, it would also make it easier (possible?) to take all the
> generated JSP class files, put them in a JAR file, and add appropriate
> servlet mappings for all pages. This is great for distributing ready-made
> JSP based applications, especially on platforms with file name length
> limits (e.g. Mac), but it's tricky to do today due to the non-standard
> naming convention for the generated class files.
>
> I'm also curious about why it wasn't implemented like this from the
> beginning. Please, Anil or Mandar (or someone else involved in the
> original implementation), can you give us the background and let us
> know if you see any problems with the proposed change?
>
> Hans
> --
> Hans Bergsten hans@gefionsoftware.com
> Gefion Software http://www.gefionsoftware.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Proposal: Jasper, JspLoader, SecurityManager and class names/loading
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Glenn Nielsen wrote:
> [...]
> PROPOSAL:
>
> Modify Jasper so that JSP's located in subdirectories of the docBase
> are compiled and placed into packages and sub directories in workDir
> following normal class directory conventions.
>
> And once the above is accomplished, Jasper may not need its own
> ClassLoader.
>
> I can't think of any downside to making this change. But there may be
> historical reasons I am not aware of for this design.
>
> Implementing the proposed change to Jasper will make implementing
> a SecurityManager which works with JSP much simpler.
I would love for this change to be done, and would do it myself if I
only had the time. In addition to the problem you like to solve with
this change, it would also make it easier (possible?) to take all the
generated JSP class files, put them in a JAR file, and add appropriate
servlet mappings for all pages. This is great for distributing ready-made
JSP based applications, especially on platforms with file name length
limits (e.g. Mac), but it's tricky to do today due to the non-standard
naming convention for the generated class files.
I'm also curious about why it wasn't implemented like this from the
beginning. Please, Anil or Mandar (or someone else involved in the
original implementation), can you give us the background and let us
know if you see any problems with the proposed change?
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com