Jasper: Using a non-File based environment

[Felix Meschberger <fm...@gmail.com>]

Hi,

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
execution.

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
JspLoader.
  * 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
Felix

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Jasper: Using a non-File based environment

[Felix Meschberger <Fe...@day.com>]

Hi,

Sorry to not have replied earlier - I was very much distracted into the
underwoods ....

On 11/17/06, Remy Maucherat <re...@apache.org> wrote:
>
> File abstraction is already present in Tomcat (for example, JSP used to
> run on top of Slide), so you can have all webapp resources loaded from a
> repository of your choice, rather than the filesystem.


Agreed.

If you want generated source and classes to be stored in the repository,
> then I really don't see the point. For starters, it's an implementation
> detail which could go away.


I agree with the second point. For the first point - why not storing the
java sources and class files in the filesystem: We are building a system
ontop of JCR which supports staging with replication. We will have separate
development, author and publishing systems, where JSP development generally
take place on the development system. There are use cases, where we would
not want to replicate the JSP sources but the JSP class files. In these
cases, having the class files in the repository would allow us to use the
same mechanics for this.

Regards
Felix

Re: Jasper: Using a non-File based environment

[Remy Maucherat <re...@apache.org>]

Felix Meschberger wrote:
> Hi,
> 
> 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
> execution.
> 
> 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
> JspLoader.
>  * 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 ?

File abstraction is already present in Tomcat (for example, JSP used to 
run on top of Slide), so you can have all webapp resources loaded from a 
repository of your choice, rather than the filesystem.

If you want generated source and classes to be stored in the repository, 
then I really don't see the point. For starters, it's an implementation 
detail which could go away.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org