httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher R Newman <>
Subject Re: [users@httpd] Can I keep Java VM running?
Date Wed, 30 Mar 2005 21:28:36 GMT
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.


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 
>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 
>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.
>=S Page

View raw message