You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Toadie <to...@gmail.com> on 2008/02/22 02:32:02 UTC
Custom Extension Function resolver ?
Hello
I am interested in whether or not it would be possible to extend or
write a customer Extension Element Resolver (extend is ideal).
My use case is as follows: I'd like to have XSLT invoking custom java
extension functions whereby the java extension functions are created
via Spring factory instead of just standard class.forName as it is
used in org.apache.xalan.extensions.XPathFunctionResolverImpl
My questions are:
1. If I were to extend XPathFunctionResolverImpl , how would I
register my custom FunctionResolverImpl with Xalan (2.7.1)
2. Or alternatively, do I have to write a custom XPathFactory and
register that via javax.xml.xpath.XPathFactory property as per JAXP
way?
Thanks in advance for any insights
T.
RE: Huge file transform problems..
Posted by ke...@us.ibm.com.
> As regards this snippet:
>
> >>>(Note: If you're passing in a DOM, ****STOP***
> -- instead, pass in a SAX stream, and let us construct a DTM.)<<<
>
> If you already have a DOM in hand, is there any benefit in
> serializing it into a stream?
If you pass us a DOM, all we can do right now is wrap a DTM adapter around
it -- which is unavoidably going to be larger than the DOM and probably
make any memory constraints that much worse.
Serializing out and parsing into a DTM is going to be expensive, but *may*
reduce memory thrash during transformation and thus may be a net win.
(Moreso if you release the DOM from memory before building the DTM, of
course.)
RE: Huge file transform problems..
Posted by Robert Houben <Ro...@fusionware.net>.
As regards this snippet:
>>>(Note: If you're passing in a DOM, ****STOP***
-- instead, pass in a SAX stream, and let us construct a DTM.)<<<
If you already have a DOM in hand, is there any benefit in serializing it into a stream?
Re: Huge file transform problems..
Posted by jimmy Zhang <jz...@ximpleware.com>.
In addition to DTM, there is VTD (virtual token descriptor) :)
----- Original Message -----
From: "Eric J. Schwarzenbach" <Er...@wrycan.com>
To: <unlisted-recipients:>; <no To-header on input>
Cc: <xa...@xml.apache.org>
Sent: Wednesday, February 27, 2008 3:45 PM
Subject: Re: Huge file transform problems..
>
> keshlam@us.ibm.com wrote:
>> (Note: If you're passing in a DOM, ****STOP***
>> -- instead, pass in a SAX stream,
> Or simply an InputStream.
>
>> and let us construct a DTM.)
>>
>
>
Re: Huge file transform problems..
Posted by ke...@us.ibm.com.
> > -- instead, pass in a SAX stream,
> Or simply an InputStream.
True; thanks for the generalization.
______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish
(http://www.ovff.org/pegasus/songs/threes-rev-11.html)
Re: Huge file transform problems..
Posted by "Eric J. Schwarzenbach" <Er...@wrycan.com>.
keshlam@us.ibm.com wrote:
> (Note: If you're passing in a DOM, ****STOP***
> -- instead, pass in a SAX stream,
Or simply an InputStream.
> and let us construct a DTM.)
>
Re: Huge file transform problems..
Posted by ke...@us.ibm.com.
Since XSLT has full random access to the document., we do have to store it
all in memory. We use our own DTM data model, which is significantly more
space-efficient than a traditional Java DOM implementation... but data
unavoidably takes up space. (Note: If you're passing in a DOM, ****STOP***
-- instead, pass in a SAX stream, and let us construct a DTM.)
Depending on what you're doing with the document, you may want to recode
your transformation as custom code. A SAX-based application can be written
so it stores only those pieces of data it intends to come back to,
discards data as soon as it knows it will never be referenced again, and
otherwise optimizes memory use.
Yes, it is theoretically possible for an XSLT processor to apply many of
those same optimizations. If you search the archives of this mailing list,
and the Xalan developers' list, for the key words "streaming" and
"pruning" you'lll find some past discussion of what would be involved in
making that work. There has been some promising research done in this
area... but we haven't yet had the resources needed to attempt
incorporating that work into Xalan.
______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish
(http://www.ovff.org/pegasus/songs/threes-rev-11.html)
"Burman Michael" <mi...@wmdata.fi>
02/26/2008 07:43 AM
To
<xa...@xml.apache.org>
cc
Subject
Huge file transform problems..
Hi,
Is there a solution how to reduce memory footprint of Xalan? In case I
have a document, that's way too big to process in the memory (eating up
to 6GB of memory with single-process) ?
I'm using TRAX to transform the file these days, so would changing to
StAX-transform solve this issue? My doubt is, that Xalan itself stores
it in the memory.
Or does someone have any better ideas? It's already a split file (from
7GB incoming XML-document..), and can't be splitted to smaller files
anymore in our process. The processing file would be size of ~400MB, and
this seems to eat huge amounts of memory when done with DOM+TRAX
transform.
- Micke
Huge file transform problems..
Posted by Burman Michael <mi...@wmdata.fi>.
Hi,
Is there a solution how to reduce memory footprint of Xalan? In case I
have a document, that's way too big to process in the memory (eating up
to 6GB of memory with single-process) ?
I'm using TRAX to transform the file these days, so would changing to
StAX-transform solve this issue? My doubt is, that Xalan itself stores
it in the memory.
Or does someone have any better ideas? It's already a split file (from
7GB incoming XML-document..), and can't be splitted to smaller files
anymore in our process. The processing file would be size of ~400MB, and
this seems to eat huge amounts of memory when done with DOM+TRAX
transform.
- Micke
Re: Custom Extension Function resolver ?
Posted by Toadie <to...@gmail.com>.
Actually I found a partial (?) answer to my question at
http://xml.apache.org/xalan-j/xpath_apis.html
On Thu, Feb 21, 2008 at 5:32 PM, Toadie <to...@gmail.com> wrote:
> Hello
> I am interested in whether or not it would be possible to extend or
> write a customer Extension Element Resolver (extend is ideal).
>
> My use case is as follows: I'd like to have XSLT invoking custom java
> extension functions whereby the java extension functions are created
> via Spring factory instead of just standard class.forName as it is
> used in org.apache.xalan.extensions.XPathFunctionResolverImpl
>
> My questions are:
> 1. If I were to extend XPathFunctionResolverImpl , how would I
> register my custom FunctionResolverImpl with Xalan (2.7.1)
> 2. Or alternatively, do I have to write a custom XPathFactory and
> register that via javax.xml.xpath.XPathFactory property as per JAXP
> way?
>
> Thanks in advance for any insights
>
> T.
>