[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.
Why would anyone bother to use compiled stylesheets if they have to
be compiled for every transformation (or sequence of transformations)?
There is not reason at all to use XSLTC if translets are not pre-
compiled and stored. XSLTC spends ca. 4 times as long to compile a
translet as any other XSLT processor uses on a transformation. If our
JAXP implementation forces a compilation for each time a translet is
loaded we would make XSLTC the slowest XSLT processor on the market.
If XSLTC is made the slowest JAXP compliant processor there is, then
I don't think many people will bother use it - except for those that
are still using its native APIs - and there would be no reason to
add JAXP support at all.
> 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).
There are still loads of people that prefer to use the native APIs of XSLTC.
Many of these users stick to XSLTC because of its small footprint, and not
so much for performance reasons. I would like to separate the JAXP/TrAX
wrappers from the existing XSLTC source tree (leaving the existing code
untouched - for now) and putting all TrAX wrappers in a separate directory:
a) org.apache.xalan.xsltc.runtime - existing code
b) org.apache.xalan.xsltc.dom - internal DOM
c) org.apache.xalan.xsltc.trax - TrAX wrappers/etc.
There is loads of crap in TrAX that most users will never bother even looking
at. I don't want to force this stuff upon those users that are more than
happy to use just a) and b) above (this is the case for those that are using
XSLTC in applets). I know that the current code wraps the translet (or actually
the translet base class) inside a transformer object. Nowmatter how fancy this
looks on a design diagram it is not desireably/practical for many users.
> 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.
Sure, users can cache Template instances as much as they want to nomatter
what is wrapped in inside the Template. But, this means that the stylesheet
is compiled every time the user wants to instanciate a translet _object_.
This, again, undermines the whole idea of compiling stylesheets.
Most of the software I use is open-source and is distributed as source code.
I compile this software once, store it as binaries and load it into memory
when I need it. I do not compile it every time I run it and then keep it
memory for as long as I can. This is mainly for two reasons:
a) I don't want to wait for it to compile every time I load it
b) I do not have enough memory on my PC to keep it in memory at all times
This holds for translets too. A web server that uses XSLTC would proably
not be able to keep Template/Transformer objects for all stylesheets in
memory at all times. Neither would it be preferrable to compile stylesheets
every time a new Transformer/Template object is instanciated.
> > 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.
Yes, we absolutely, definately need to be able to store translet
_classes_ somewhere. A simple property could be used. If the property we
use is set, then translets can be cached in the directory (or whatever)
the property points to, otherwise caching is turned off.
> > 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.
Template/Transformer caching definately belongs at the application level.
How these objects are created is our responsibility. And we want to create
them as efficiently as we can.
Morten
