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.
> Regards,
>
> Glenn
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
