Tamu, Based simply on the code sample that Brian provided in his original post over a year ago, the XSL will only be "compiled" when the class containing that static initializer is loaded. That class won't be loaded until it's used, so your first run is always going to include both compilation and transformation time while subsequent runs will just include transformation. Couple that with the fact that even after compilation there is undoubtedly other caching and potential class loading going on by both the JVM and OS when you do the first transformation. And finally, Brian's original post coupled the XSLT transformation with the FOP rendering; these are separate processes and FOP does not control how you use the XSLT to get to the XSL-FO it needs.
Assuming your code is like Brian's, it's doing what it's supposed to do (though I personally don't like static initializers myself because of the exception-eating that goes on if there's an error in the stylesheet that causes it to not compile). If you want to perform the stylesheet compilation before the first run you need to put it in a method that gets called from the lifecycle hooks in your application. Assuming this is in a web application, you can do it in the ServletContextListener.contextInitialized method. Sean -----Original Message----- From: tamugrg [mailto:[email protected]] Sent: Friday, January 22, 2010 6:34 AM To: [email protected] Subject: RE: XSL caching question Hi, I am facing exactly the same issue. The first time the XSL gets used, it takes quite a bit of time to do the transformation. After that the transformations happen much faster. I am using templates as described in this thread & assume the style sheet should be cached. But from the behaviour that it takes longer the first time the XSLs are being used & subsequently takes lesser time indicates that probably it's not been catched. Any suggestions/experience on this is very much appreciated. Cheers, tamu Brian Trezise wrote: > > Silly me, going to be hard for you guys to answer my question if you don't > have a code sample to look at J > > > > > static > > { > > try > > { > > cyberTron = TransformerFactory.newInstance(); > > Config config = (Config) > ConfigManager.getInstance().getConfig(Config.class); > > Source xslt = new StreamSource(new > File(config.getXSLTemplateURL())); > > allSpark = cyberTron.newTemplates(xslt); > > } > > catch(Exception e) > > { > > logger.error(e); > > } > > } > > > > ~Brian > > ___________________________________________________ > Brian Trezise > Staff Software Engineer > IntelliData, Inc > 22288 E Princeton Dr > aurora, colorado 80018 > T: 720.524.4864 > [email protected] > > > > From: Brian Trezise [mailto:[email protected]] > Sent: Monday, August 25, 2008 2:41 PM > To: [email protected] > Subject: XSL caching question > > > > In FOP 0.95, I'm using the basic caching method to cache my XSL > transformation file, not doing anything fancy with file system monitors or > anything for the time being. The first time I run FOP on the server to > generate a pdf, it takes 10-20 seconds to generate the pdf because it's > loading up the XSL file for the first run. Afterwards it runs in the > neighborhood of 500ms per PDF. I was just wondering if there is a way to > force the XSL to fully cache statically? > > This isn't a huge issue as we don't restart our servers all that often but > it's just a little thing that's bugging me J > > Thanks, > > ___________________________________________________ > Brian Trezise > Staff Software Engineer > IntelliData, Inc > 22288 E Princeton Dr > aurora, colorado 80018 > T: 720.524.4864 > [email protected] > > > > > -- View this message in context: http://old.nabble.com/XSL-caching-question-tp19151328p27272536.html Sent from the FOP - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] ---------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
