Re: [users@httpd] Can I keep Java VM running?

[Christopher R Newman <christopher.newman@xxxxxxxxxxx>]

Thanks.  I didn't realize Saxon had a servlet.  It looks good since I can
change some of my XSLs to output everything to the client.  But there are
still some XSLs that need to be used inside a CGI so I can manipulate the
output.

How transparent is the Tomcat method?  Can a CGI running in Apache hand off
the Saxon process to the servlet and get back the output (in the same CGI)
for further processing?

Would the FastCGI method be better since I wouldn't have to have a separate
Tomcat process running?

Any hints/links on how to do either would be appreciated.

Chris

P.S.  Thanks for all the other tips.  I am actually thinking about compiling
XSLs but we use lots of them and I'm sure a great deal is wasted on Java
VM starting up each time.

spage wrote:
> >    I have a website that runs a Java app called Saxon to execute XSLs 
> > on the server.  Each time Saxon is called, it takes a good while for 
> > the Java VM to start up.  Does anyone know how to have Java VM run in 
> > the background with Apache so every time a user causes Saxon to run it 
> > can do so without a huge startup time?
> >   
>
> Java "running in the background" sounds like an Java servlet container 
> such as Apache Tomcat.  Apache passes Web requests on to the servlet 
> container where an XSLT Java servlet acts on them.  Saxon has a servlet 
> implementation, 
> http://www.saxonica.com/documentation/samples/servlet.html
>
> This involves several pieces and maybe some Java servlet programming 
> :-(  There's probably a way to use the Apache FastCGI interface to talk 
> to a persistent external Java VM running Saxon but I don't know if 
> it'll be any simpler.  There are XSL processor modules for Apache like 
> mod-xslt2 and AxKit, but I believe neither uses a Java-based XSLT 
> engine.
>
> XSL transform is always going to be a heavyweight operation.  You can 
> investigate caching the results of the transform, precompiling the 
> XSLs, etc.  Perhaps that's why this simple problem seems to evolve into 
> something more complex like AxKit|Cocoon|XSP|XTP etc. running on a 
> full-blown app server.
>
> Cheers,
> --
> =S Page