a problem JSP Containers face is to compile generated JSP Page Servlets
against the classpath that makes up a web application. There is no way
to find out the locations of the classes that make up the classpath.
While it is possible for WEB-INF/classes and WEB-INF/lib, the JSP
container needs intimate knowledge of the servlet container's class
loading mechanism to add the rest (for example, the location of the
servlet-api jar).

This dependency on the servlet container has hindered the community to
develop a portable, drop-in JSP container. While you can argue that JSP
and Servlet containers are intimately coupled, any web framework that
wants to compile code would face the same problem.

An alternative, pioneered by the Cocoon community, and which I believe
is being pursued by Jasper in Tomcat 5.5, is to use a compiler that
resolves its classpath against a _classloader_ instead of a
_filesystem_, using ClassLoader#getResource instead of java.io.File.
Eclipse's Compiler has successfully been used to do this.

While the JavaFileManager in principle looks like it could be adapted to
a ClassLoader, it requires the "list" operation, an operation a
ClassLoader cannot fulfill. Is listing all classes in a package
necessary for this compiler to work? If so, a "Compile in current
classloader", or more specific, "Compile in this webapp" will not be
possible with JSR 199 which would be a shame. I remember that I once
tried to make javac do this and I stumbled over this exact requirement
before; eclipse's jdt did not need it.

References:

http://mail-archives.apache.org/mod_mbox/jakarta-tomcat-dev/200307.mbox/%###@###.###%3e

http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html

###@###.### 2005-07-15 14:41:52 GMT