[xalan 2] redirect extension now functional

[Scott Boag/CAM/Lotus <Sc...@lotus.com>]

The redirect extension is now functional, at least to a point.
element-available barfs with ugly error messages, and I haven't done deep
testing yet.

If folks want to give it a try, see what bugs it has, and maybe implement a
few features (like the ability to set the output format), it would be
great.

On my unit test, Xalan 2 seems to run the Cocoon 2 sitemap stylesheet
pretty well now.

I have to set extensions aside for a day and implement smart document(...)
function caching, so the thing doesn't run out of memory when processing
tons of documents when using the document(...) function in a loop.  After
that I need to implement the JDBC extension.

After that:

* Optimize XPath iterators by making very simple iterators for simple
cases.
* Make back-pointers to an originating DOM when the stylesheet is generate
from a DOM (tooling issue).
* Work on EntityResolver and TrAX URI Resolver for use with xsl:include,
etc.  (& review and incorporate Norm's EntityResolver code in Xalan 1)
* Add JAXP handling for both XalanJ 1 and XalanJ 2... at least for the DOM
builder.
* Finish remaining conformance tests wtih Myriam.
* Workout some issues with Serializers (like, figuring out how to use the
TrAX Serializer interfaces with the Xerces Serializers -- if someone wants
to work on this, it would be great).
* xml-stylesheet PI and fragment handling.
* Do a couple of things to optimize the stylesheet compilation (it's slow
right now).

If anyone want's to take one of these tasks off my hands, let me know...

-scott

Xalan (& Xerces) Server-Side Usage Patterns.

[Vincent-Olivier Arsenault <vi...@neuro6.com>]

hey folks!


i'm studying xalan (1 for now) performances and have some questions.

i'm only using sax and i want to know if keeping a processor instance along
with the StylesheetRoot objects (for successive transformation using the
same stylesheet) is the only way to have SAX events as xslt input...


this.xsltProcessor.reset();
this.xsltProcessor.setStylesheet( stylesheet );
this.xsltProcessor.setDocumentHandler( dh );
this.xsltProcessor.reset();


my problem is that i'd like to use the StylesheetRoot directly since it's
thread safe but i couldn't find a way to have it behave as a
DocumentHandler...


if keeping a processor instance is the only way, is there a processor pool
utility that i can use?


and xerces question: is there a parser pool utility included in xerces?



thanks

vincent
ps: Scott i'm reading the "XSLT without DOM" thread and will come back with
concrete ideas soon (monday or tuesday...).