tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <>
Subject Jasper: Using a non-File based environment
Date Fri, 17 Nov 2006 15:29:14 GMT

I am new to this list, so let me quickly introduce myself: I am Felix
Meschberger and am working on a Web Content Management Application
running on a Java Content Repository (Apache Jackrabbit) provding
amongst other things dynamic compilation of JSP scripts. I am also a
committer to the Jackrabbit project to which I contributed the JCR
ClassLoader and worked on the RMI layer library.

Integrating JSP support in the application is the reason for me be
here: To compile JSP, I took Jasper 5.5.20 and adapted it to my use
case, which I will explain quickly. As I said, the application will
run on Jackrabbit. Consequently, JSP source will be stored in the
repository not the OS Filesystem or the Web App Context. Also,
generated Java Source and Servlet classes will be stored in the
repository. The repository class loader will pick the servlets up for

To enable this functionality, I patched Jasper as follows:
  * Defined a new IOProvider interface, which abstracts the File
operations: getInputStream, getOutputStream, mkdirs, delete and some
more. Of course a default file based variant has also been implemented
  * Fixed all direct File uses to use the new IOProvider API
  * The IOProvider is set on JspRuntimeContext and defaults to the
File-based implementation
  * Modified JspCompilationContext.loader field to be a class loader,
as my environment has no URLClassLoader
  * To inject my custom class loader, I added API to the Options
interface to return a custom provided classloader to compile (in the
case of Eclipse Compiler) and load JspServlets instead of the
  * Another change to the Options interface: the getScratchDir method
returns a File, which is not available in my environment. In fact the
scratchDir suffices it to be a String, which may be interpreted as a
Filesystem directory in the standartd use case. Hence, I modified the
method to return a String (Yes, I know, this is a "dangerous"
modification !)

I would like to to know, whether you would be interested to see these
patches and might consider them for addition to the Jasper code ?

Thanks for your replies

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message