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.
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.
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
