Hi Scott,
[EMAIL PROTECTED] wrote:
>Morten Jorgensen <[EMAIL PROTECTED]> wrote:
>
>>and
>>we don't want to compile such classes more often than we have
>>to, and this is the reason why we want cache translets.
>>
>
>My position is that the XSLT processor should not be doing caching. I have
>said this many times and I will continue to say it.
>
>>Please let me first make a
>>distinction between caching javax.xml.transform.Transformer
>>objects and caching Translet classes.
>>
>
>What I don't hear you talking about is the javax.xml.transform.Templates
>class. I can't find where this object is implemented in the XSLTC source,
>which surprises me.
>
This is documented here :
http://xml.apache.org/xalan-j/xsltc/xsltc_trax.html#templatescreation as
sems to fit your model.
>
>
>In my mind:
>
>The Templates implementation object is a very thin wrapper around a
>Translet *class*. It probably just contains the Class object.
>The Transformer is an instance of a Translet class (which it is now, so
>this much is done).
>
>Here's how it should work in my opinion:
>
>org.apache.xalan.xsltc.compiler.XSLTC should implement javax.xml.transform.
>TransformerFactory.
>org.apache.xalan.xsltc.compiler.XSLTC#newTemplates(Source source) should
>compile the source object into a Translets, and create a small wrapper
>class, org.apache.xalan.xslt.TemplatesImpl that contains the Class object,
>or perhaps just the class name (or, perhaps you get fancier than that and
>it holds the actual bytecodes... dunno).
>
>Everytime the caller calls TransformerFactory#newTemplates(Source source),
>org.apache.xalan.xsltc.compiler.XSLTC#newTemplates(Source source) will
>compile a new Translet, period. Caching that object is the responsibility
>of the caller, which can use whatever mechanisms are suitible.
>
The current implementation from the docs above is
public class TransformerFactoryImpl extends SAXTransformerFactory {
...
public Templates newTemplates(Source stylesheet) throws
TransformerConfigurationException
{
Transformer translet = newTransformer(stylesheet);
return new TransletTemplates(translet);
}
}
If XSLTC added support for a newTemplatesHandler() method which uses a
TemplatesHandlerFactory and added a corresponding method to set a
TemplatesHandlerFactory then an app could call newTemplatesHandler to
get the default handler, then set a factory of their own (which also
stores the default handler) which tries to determine by a means useful
for that app if the stylesheet has changed and if not use
Class.forName/newInstance etc to retrieve a cached Translet and then
returns 'new TransletTemplates(translet);'. If the stylesheet has
changed it could chain to it's stored templatesHandler.
This means that an app could implement it's own caching mechanism
for Templates/translets.
Does this make sense ?
Regards,
Padraig
>
>
>org.apache.xalan.xslt.TemplatesImpl#newTransformer() should simply call
>Class#newInstance() on the the contained Translet class object.
>
>This seems really simple to me. Applications that are already caching
>Templates objects then start caching XSLTC translets automatically, with
>the same mechanism.
>
>>Our main concern is where to store the translets (a simple Java
>>property file pointing to a directory may do)
>>
>
>Does the class have to be put on disk? (A question... I simply don't
>know). If it does, I guess I would use a system property to indicate the
>storage directory.
>
>>and how to
>>make sure that a translet in the cache is still valid
>>
>
>This is one of the reasons you really shouldn't muck with caching.
>Whatever you do will cause somebody problems. Put this responsibility at
>the application level where it belongs.
>
>-scott
>
>
>
>
>
>
> Morten Jorgensen
>
> <morten.jorgense To: xalan dev
><[EMAIL PROTECTED]>
> [EMAIL PROTECTED]> cc: (bcc: Scott Boag/CAM/Lotus)
>
> Sent by: Subject: Transparent caching with
>JAXP/TrAX
> Morten.Jorgensen
>
> @sun.com
>
>
>
>
>
> 07/09/01 12:24
>
> PM
>
> Please respond
>
> to xalan-dev
>
>
>
>
>
>
>
>
>
>Tom/Dick/Harry/anybody,
>
>We are trying to come up with a decent design for transparent
>translet caching with JAXP/TrAX. Please let me first make a
>distinction between caching javax.xml.transform.Transformer
>objects and caching Translet classes. A Transformer object can
>be instanciated (using a factory class) and then kept in
>memory (ie. cached) for a sequence of similar transformations.
>
>A translet is a Java class and not an instance of a class, and
>we don't want to compile such classes more often than we have
>to, and this is the reason why we want cache translets. The
>best way of doing this using JAXP is to make the XSL->translet
>compilation transparent, similar to the way JSPs are compiled
>into servlets. This could be done by having the Transformer
>object check for the existance (and validity) of an already
>compiled translet, and then either use the existing translet
>or create a new one if needed, and then run the transformation
>using this translet:
>
> +-------------+ +----------+
> | XSLTC | -> | Translet |
> | compiler | | storage |
> +-------------+ +----------+
> ^ |
> | v
> xsl/xml +-------------+ +----------+
>JAXP ----------> | JAXP/TrAX | -> | XSLTC |
>user <---------- | Transformer | <- | Translet |
> *ml +-------------+ +-----------
>
>Our main concern is where to store the translets (a simple Java
>property file pointing to a directory may do) and how to
>make sure that a translet in the cache is still valid (the
>Source interface does not give much info on the XSL source).
>
>Any suggestions are welcome!
>
>Thanks
>Morten
>
>
>
>
>
>
