On Wed, Jan 23, 2002 at 02:28:52AM -0800, Remy Maucherat wrote: > > On Tue, Jan 22, 2002 at 06:14:18PM -0800, Remy Maucherat wrote: > > > > Do you mean you're spawning another process to do compilation? I > > thought that javac's core class had been fixed so that it'd be possible > > to run it in a thread in an existing server ... for a number of reasons, > > including performance and the awkwardness of spawning processes on > > win32. (I know there was talk about that years ago, when I last worked > > on a page compilation system, but I don't know what happened with it.) > > Jasper uses the javac API which doesn't spawn a process, but it still > behaves the same way it does if you actually spawn a process.
You said the reason that we can't do what I suggested is that it would "make JSPs behave differently from servlets" -- so I went to look at Jasper to see how similar the behavior is right now, in terms of classloading. It looks like there's no guarantee at all about consistency: Jasper already assumes that the classpath for JSP compilation may be different from that used in servlets. There are a number of inconsistencies, including at least the following: 1) jars accessed by URLs using protocols other than the file protocol will be silently left out (JspEngineContext.java:155) 2) the order of classname resolution does not match the special logic in WebappClassLoader, since the webapp classloader's jars aren't ever preptended to the system classpath, they're always appended (Compiler.java:233). I haven't yet followed the logic all the way back in terms of how the data gets into the context for use by JspServlet -- it is possible that the order is reversed somewhere else ... but if so, the logic isn't in WebappClassLoader, which is the only class which will know if delegation is true or false. So I suspect it's not being done. Note that #2 may mean that excluding the jars from the classpath to Jasper might not be such a big deal, as the only reason for the filtering of those jars in WebappClassloader is the fact that they could override classes defined in their parent classloaders. I can imagine that there may be other good reasons not to allow the changes which I suggested, but AFAICT there's very little consistency left to be preserved, when comparing classpath handling for JSP pages and servlets. > Also, you can't change the delegation and still be spec compliant. We could > avoid implementing the requirement of preventing loading core libraries, if > it turns out it's not implementable. I don't mind configuring tomcat so that my install isn't spec compliant (that's already possible, with the setDelgate toggle). I tend to feel as Daniel said -- the spec is broken. But I can understand wanting to build tomcat in such a way that it satisfies the spec as well as is possible. It is possible to be compliant with the specification, but I don't think the current implementation is. I can override classes in each of the "protected" packages, so long as I take care to leave out the trigger class, for which tomcat looks, in my .jar files -- so if it's tomcat's job to avoid loading core libraries in the webapp classloaders, I don't think it's doing it reliably. Anyway -- one possibility would be to do filtering of .jars before handing them to the JSP engine (much as it's being done now, thought it might make more sense to read through the contents of the jars and look for any classes which are in packages they're not allowed to be in), but to do the kind of filtering which I described in my first message, in loadClass. And I'd suggest adding one or more toggles, to configure how filtering is done. (I'm not sure if one or two is appropriate because I'm not sure if #2 -- up above -- should be fixed.) thanks -- Ed -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
