"Craig R. McClanahan" wrote:
>
> Glenn Nielsen wrote:
>
> > "Craig R. McClanahan" wrote:
> > >
> > > Glenn Nielsen wrote:
> > >
> > > > 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.
> > > >
> > >
> > > I'm a little uncomfortable with making Jasper's servlets not belong to a package
> > > any longer. My issue relates to developers who (mistakenly) try to reference
> > > beans in <jsp:useBean> that are not in any package -- currently, that does not
> > > work in Tomcat, or in any other container that uses an implicit package. But,
> > > with this change, such an incorrect bean usage would work in Tomcat, but would
> > > cause portability problems for apps that depend on that behavior.
> > >
> > > I'd much rather see the generated servlets that Jasper creates continue to be
> > > placed in a package, to protect developers from themselves on this issue.
> > >
> >
> > The class name used is the mangled jsp file name with the .jsp replaced with _jsp.
> > For /examples/jsp/date/date.jsp the class name would be "date_jsp.class" located
> > in "${tomcat.home}/work/localhost/examples/jsp/date/".
> > The URLClassLoader for the JSP page will only load the class "date_jsp" or inner
> > classes like "date_jsp$SomeClass". All other classes will be delegated to the
> > parent web app context class loader.
> >
> > >From looking at the current JasperLoader, they behave the same way.
> >
> > If jsp:useBean requires that a Bean class exist in a package it should handle
> > that. (I haven't found that in the JSP1.1 spec yet)
> >
>
> I'm sorry ... I wasn't clear enough. My concern is not with the JSP page class, it's
> with the bean class.
>
> Consider that you have a bean class Foo.java (no package). If your JSP page says:
>
> <jsp:useBean id="foo" class="Foo"/>
>
> this will fail under current Tomcat implementations, but succeed with your suggested
> change. The reason relates to the way that Java interprets an "unpackaged" class
>name
> -- it assumes the same package as the calling class.
>
Does this mean that all "unpackaged" classes loaded by a JSP page should fail with
CNFE?
If so, that is easy to implement in the ClassLoader without putting the servlets
generated
for the JSP pages in a package.
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]
