Re: Saxon as the default XSLT procesor
Stefano Mazzocchi wrote: ... I've done some tests on my machine using the XSLTBench and here is what I got: Saxon 6.5.3 - 49.52 XalanJ 2.5.2 19.89 couldn't test XSLTC So, +1 to change to Saxon. I'm +1 to change to anything compatible that is faster than Xalan. But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-( -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Saxon as the default XSLT procesor
Nicola Ken Barozzi wrote: But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-( That's not unusual. Did you use the most recent Cocoon? I suppose there are no document() calls in the style sheet, because at least in the Cocoon releases I used it gets passed null as Source quite often for no obvious reason. Xalan tends to ignore this, while Saxon barfs. J.Pietschmann
Re: Saxon as the default XSLT procesor
J.Pietschmann wrote: Nicola Ken Barozzi wrote: But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-( That's not unusual. Did you use the most recent Cocoon? Almost. It's some quite recent dev version. I suppose there are no document() calls in the style sheet, There are. I'm gonna remove them soon, nut for now they are there, and will the possibility to use them will remain some time for backward compat. because at least in the Cocoon releases I used it gets passed null as Source quite often for no obvious reason. Xalan tends to ignore this, while Saxon barfs. Wierd... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Saxon as the default XSLT procesor
Nicola Ken Barozzi wrote: document() calls in the style sheet, There are. I'm gonna remove them soon, nut for now they are there, and will the possibility to use them will remain some time for backward compat. because at least in the Cocoon releases I used it gets passed null as Source quite often for no obvious reason. Wierd... I think it's a Cocoon bug. The first invocation of the pipeline is ok, but in followup incovations the XSLT processor often gets a null SourceResolver (not Source, sorry). Xalan uses its own URIResolver in this case, while Saxon (6.x series) takes it literally. That's one of the dark corners of the TrAX spec, I couldn't find any regulations guiding the behaviour. The null is not a MT problem, it happens even for low load. I think it has something to do with incorrect re-initialization of the pipeline after the SourceResolver has been recycled and the reference had been nulled. Given the added problem that document() referenced stuff doesn't influence cache validity, I switched to aggregation. If the document() gets the URI from source XML, this can be painful (XSLT to an XInclude source, then Xinclude, the the final XSLT instead of just one XSLT). The worst thing is that you can't easily test the XSLT any longer with command line tools, even though none of the dynamic features (like cocoon: URIS) are used. If you've to ftp the damn sources to the app server, this really slows down development :-/ . J.Pietschmann
DO NOT REPLY [Bug 25879] New: - directory generator caching bug
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25879. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25879 directory generator caching bug Summary: directory generator caching bug Product: Cocoon 2 Version: 2.1.2 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Cache validation of DirectoryGenerator seems not to check if there are any new files in the directory. If you add new file to directory DirectoryGenerator [with caching] would never noticed that, as if there wouldn't be any new files.
DO NOT REPLY [Bug 25879] - directory generator caching bug
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25879. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25879 directory generator caching bug --- Additional Comments From [EMAIL PROTECTED] 2004-01-04 04:28 --- If you've added a file to the directory, directory's modification time should change and this should invalidate cache entry. Can you verify that directory generator's validity includes modification time of the directories?
