<div dir="ltr">Hi Michael,<div>thanks for the pointer.</div><div>I am now trying out to inject a customer Transformer Factory.</div><div><br></div><div>If I am not completely wrong, there is no need to modify any Yanel code, I just have to configure the custom factory via JAVA_OPTION. That way, it gets loaded automatically via this line in BasicXMLResource:</div>
<div>SAXTransformerFactory tf = (SAXTransformerFactory)TransformerFactory.newInstance();<br></div><div><br></div><div>I will summarize my findings if there are any...</div><div>Cheers, Bas</div><div><br></div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 28, 2014 at 10:31 AM, Michael Wechner <span dir="ltr"><<a href="mailto:michael.wechner@wyona.com" target="_blank">michael.wechner@wyona.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Hi Balz<br>
      <br>
      Please see my comments inline below<br>
      <br>
      Am 28.02.14 10:08, schrieb basZero:<br>
    </div><div class="">
    <blockquote type="cite">
      <pre>Hi,

as you know, Yanel performs the XSLT (Transformation of XSL to temporary
Java Class) for EACH request.

I would like to ask, whether there is anybody out there who has played with
these two alternative approaches:

1) extend XSLT Processor in a way, that it keeps a list of XSLs including
timestamps and only does the transformation, if the XSL has changed. Hence:
reuse the java classes from earlier if nothing changed.</pre>
    </blockquote>
    <br></div>
    At the moment we use<br>
    <br>
    <dependency groupId="xalan" artifactId="xalan"
    version="2.7.0"/><br>
    <br>
    but I am not sure whether what you are asking has actually anything
    to do with Xalan itself, but<br>
    rather how we instantiate the XSLTs inside<br>
    <br>
    <br>
    src/impl/java/org/wyona/yanel/impl/resources/BasicXMLResource.java<br>
    <br>
    It seems to me that we would have to introduce so called Templates
    as described in<br>
    <br>
<a href="http://www.javaworld.com/article/2073394/java-xml/transparently-cache-xsl-transformations-with-jaxp.html" target="_blank">http://www.javaworld.com/article/2073394/java-xml/transparently-cache-xsl-transformations-with-jaxp.html</a><br>

    <br>
    Maybe you can give it a try.<br>
    <br>
    Independent of the caching the following performance hints might
    also improve your situation<br>
    <br>
    <a href="https://xalan.apache.org/old/xalan-j/faq.html#faq-N10175" target="_blank">https://xalan.apache.org/old/xalan-j/faq.html#faq-N10175</a><br>
    <br>
    HTH<span class="HOEnZb"><font color="#888888"><br>
    <br>
    Michael</font></span><div class=""><br>
    <blockquote type="cite">
      <pre>
This option would still have the advantage that you can change/patch XSL
files in the running system and see the changes immediately.

2) There is an official XSLT processor mode called "cached". In this mode,
the XSLT processor only performs the XSLT once and keeps the generated java
classes for the lifetime of the JVM. This is certainly the fastest way of
having XSLT in a system, but any changes to XSLs are of course ignored once
the XSLT has happened. So this is a disadvantage.

I would be interested in some hands-on experience for option 1).

Cheers, Bas

</pre>
      <br>
      <fieldset></fieldset>
      <br>
    </blockquote>
    <br>
  </div></div>

<br>--<br>
Yanel-development mailing list <a href="mailto:Yanel-development@wyona.com">Yanel-development@wyona.com</a><br>
<a href="http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development" target="_blank">http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development</a><br></blockquote></div><br></div>