On Thu, Nov 19, 2009 at 2:09 AM, Rob.Conde <Rob.Conde@ai-solutions.com>wrote: > Hi David, > > I built the XalanTransformer sample and indeed the performance > seems fine there. Also I tried passing a stringstream instead of the > DOMStringPrintWriter and it seems to work fine…though I’m not sure if this > will handle encoding correctly. > As long as you treat the string as a sequence of binary bytes, you won't have any issues. The interesting thing about transforming to a XalanDOMString is that you override the output transcoding mechanism, since XalanDOMString can only contain UTF-16 code points. This can be problematic if your stylesheet doesn't specify UTF-16 as the output encoding. To parse the resulting document, you would need to explicitly force the encoding on the InputStream by calling InputStream::setEncoding() and passing in "UTF-16". > So I think you’re probably on the right track. Note that the code I posted > crashes at the end since terminate is called before the XSLTInputSource goes > out of scope – but this is unrelated to the original problem. > I will investigate the performance issues, but I suspect it has to do with re-sizing the XalanDOMString instance as it grows. You might try running your test application and adding a call to XalanDOMString::reserve() before you transform: domStr.reserve(35000000); This would reserve enough space in the instance so resizing would not occur. Dave
Hi David,
I built the XalanTransformer sample and indeed the performance
seems fine there. Also I tried passing a stringstream instead of the
DOMStringPrintWriter and it seems to work fine.though I'm not sure if this
will handle encoding correctly.
So I think you're probably on the right track. Note that the code I posted
crashes at the end since terminate is called before the XSLTInputSource goes
out of scope - but this is unrelated to the original problem.
Rob
_____
From: David Bertoni [mailto:dbertoni.apache@gmail.com]
Sent: Tuesday, November 17, 2009 9:47 PM
To: xalan-c-users@xml.apache.org
Subject: Re: Xalan performance issue on large files...
On Tue, Nov 17, 2009 at 6:39 AM, Rob.Conde <Rob.Conde@ai-solutions.com>
wrote:
Hey David,
I understand if you haven't gotten to it yet, but I wanted to make
sure you got my example file and perhaps confirmed or were unable to confirm
the performance issue with it...
Hi Rob,
I just took an initial look at this.
I built Xalan-C on an Ubuntu 9.10 VMware virtual machine on my laptop, which
is a Lenovo T60p with a Core Duo 2600 (2.16GHz) with 2GB of memory.
I then created a stylesheet that does an identity transformation and ran the
Xalan command line application to transform to a file, reporting the
timings:
dbertoni@ubuntu-vmware:~/apache/test$ Xalan -t -o copy.xml bigXml.txt
identity.xsl
Source tree parsing time: 1900 milliseconds.
Stylesheet compilation time: 0 milliseconds.
Transformation time: 3620 milliseconds.
So you can see the transformation time is trivial. I plan now to build your
sample code as an application and test it. It may be there is some
inefficiency in transforming to a XalanDOMString through PrintWriter
interface.
Can you please verify that an identity transform in your environment through
the Xalan command line executable exhibits similar performance to my Ubuntu
virtual machine?
Thanks!
Dave
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
On Tue, Nov 17, 2009 at 11:15 PM, brown wrap <gramos@yahoo.com> wrote: > unsubcribe > Unsubscribe information is available here: http://xml.apache.org/mail.html#xalan-c-users Sending email to the list doesn't work. Dave
On Tue, Nov 17, 2009 at 6:39 AM, Rob.Conde <Rob.Conde@ai-solutions.com>wrote: > Hey David, > I understand if you haven't gotten to it yet, but I wanted to make > sure you got my example file and perhaps confirmed or were unable to > confirm > the performance issue with it... > Hi Rob, I just took an initial look at this. I built Xalan-C on an Ubuntu 9.10 VMware virtual machine on my laptop, which is a Lenovo T60p with a Core Duo 2600 (2.16GHz) with 2GB of memory. I then created a stylesheet that does an identity transformation and ran the Xalan command line application to transform to a file, reporting the timings: dbertoni@ubuntu-vmware:~/apache/test$ Xalan -t -o copy.xml bigXml.txt identity.xsl Source tree parsing time: 1900 milliseconds. Stylesheet compilation time: 0 milliseconds. Transformation time: 3620 milliseconds. So you can see the transformation time is trivial. I plan now to build your sample code as an application and test it. It may be there is some inefficiency in transforming to a XalanDOMString through PrintWriter interface. Can you please verify that an identity transform in your environment through the Xalan command line executable exhibits similar performance to my Ubuntu virtual machine? Thanks! Dave
unsubcribe
Hey David, I understand if you haven't gotten to it yet, but I wanted to make sure you got my example file and perhaps confirmed or were unable to confirm the performance issue with it... Thanks, Rob Conde
On Mon, Nov 16, 2009 at 4:40 PM, GALVAN, Jean-Pierre < Jean-Pierre.GALVAN@sage.com> wrote: > Hello. > > As I am registered now in the Xalan-c mailing list, I can now send this > message so as to get help… > > > > I’m try to build sources files of Xalan-c with Xerces 3-0-1. > You will need to use the head of the Subversion repository. > The build of Xerces 3-0-1 was OK > > I ran ./runConfigure for Xalan and it was OK > > After I tried to launch make and I have un error when accessing > XalanMsgLib.cpp > > But the build stopped with error. > > * * > > *Heres my machine :* > > [root@aylinux64 c]# uname -a > > Linux aylinux64 2.6.18-92.el5 #1 SMP Fri May 23 23:40:43 EDT 2008 x86_64 > x86_64 x86_64 GNU/Linux > > > > *Here’s the output** :* > > [root@aylinux64 c]# make > > make -C src/xalanc all > > make[1]: Entering directory > `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc' > > Preparing the directory structure for a build ... > > mkdir -p ../../obj > > mkdir -p ../../lib > > mkdir -p ../../bin > > make -C Utils prepare > > make[2]: Entering directory > `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils' > > mkdir -p ../../../nls > > mkdir -p ../../../nls/include > > make[2]: Leaving directory > `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils' > > make -C Utils locale > > make[2]: Entering directory > `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils' > > make -C MsgCreator > > make[3]: Entering directory > `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator' > > g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall > -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include -I../../../../nls/include > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o > ../../../../obj/MsgFileOutputStream.o > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/MsgFileOutputStream.cpp > > g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall > -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include -I../../../../nls/include > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o > ../../../../obj/ICUResHandler.o > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/ICUResHandler.cpp > > g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall > -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include -I../../../../nls/include > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o > ../../../../obj/InMemHandler.o > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/InMemHandler.cpp > > g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall > -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include -I../../../../nls/include > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o > ../../../../obj/MsgCreator.o > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/MsgCreator.cpp > > g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall > -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include -I../../../../nls/include > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o > ../../../../obj/NLSHandler.o > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/NLSHandler.cpp > > g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall > -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include -I../../../../nls/include > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o > ../../../../obj/SAX2Handler.o > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/SAX2Handler.cpp > > g++ -DLINUX -fPIC -DXALAN_INMEM_MSG_LOADER \ > > -L/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/lib -lxerces-c > ../../../../obj/MsgFileOutputStream.o ../../../../obj/ICUResHandler.o > ../../../../obj/InMemHandler.o ../../../../obj/MsgCreator.o > ../../../../obj/NLSHandler.o ../../../../obj/SAX2Handler.o -o > ../../../../bin/MsgCreator > > make[3]: Leaving directory > `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator' > > ../../../bin/MsgCreator > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/NLS/en_US/XalanMsg_en_US.xlf > -TYPE inmem -LOCALE en_US > > make -C XalanMsgLib > > make[3]: Entering directory > `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/XalanMsgLib' > > g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall > -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src > -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include -I../../../../nls/include > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc > -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o > ../../../../obj/XalanMsgLib.o > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp > > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp:25: > error: expected â,â or â;â before ânamespaceâ > > /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp:74: > error: expected `}' at end of input > > ../../../../nls/include/LocalMsgData.hpp:34: warning: > âxalanc_1_10::msgArrayâ defined but not used > Xerces-C 3.x made some API changes that were not backwards-compatible. Although you can attempt to build Xalan-C, as you see, it is not successful. You can either use Xerces-C 2.6 with Xalan-C 1.10, or use the head of the subversion repository. Since you're using Linux, it's trivial for you to install Subversion and check out the correct sources: 1. Make sure Subversion is installed, using the appropriate package manager for your distribution. 2. Check out the head of the repository: svn co http://svn.apache.org/repos/asf/xalan/c/trunk/home/dbertoni/xml-xalan/c 3. Set the XALANCROOT environment variable appropriately: export XALANCROOT=/home/dbertoni/xml-xalan/c 4. cd into the new source tree, configure and build: cd /home/dbertoni/xml-xalan/c ./runConfigure -p linux -c gcc -x g++ make all samples tests 5. You can run the conformance tests to verify your build by checking out the test directory: svn co http://svn.apache.org/repos/asf/xalan/test/trunk<http://svn.apache.org/repos/asf/xalan/test/tests>/home/dbertoni/xml-xalan/test export LD_LIBRARY_PATH=$XERCESCROOT/lib:$XALANCROOT/lib:$LD_LIBRARY_PATH cd /home/dbertoni/xml-xalan/c/bin ./Conf ../../test/tests/conf Dave
Hello.
As I am registered now in the Xalan-c mailing list, I can now send this message so as to get
help...
I'm try to build sources files of Xalan-c with Xerces 3-0-1.
The build of Xerces 3-0-1 was OK
I ran ./runConfigure for Xalan and it was OK
After I tried to launch make and I have un error when accessing XalanMsgLib.cpp
But the build stopped with error.
Heres my machine :
[root@aylinux64 c]# uname -a
Linux aylinux64 2.6.18-92.el5 #1 SMP Fri May 23 23:40:43 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
Here's the output :
[root@aylinux64 c]# make
make -C src/xalanc all
make[1]: Entering directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc'
Preparing the directory structure for a build ...
mkdir -p ../../obj
mkdir -p ../../lib
mkdir -p ../../bin
make -C Utils prepare
make[2]: Entering directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils'
mkdir -p ../../../nls
mkdir -p ../../../nls/include
make[2]: Leaving directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils'
make -C Utils locale
make[2]: Entering directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils'
make -C MsgCreator
make[3]: Entering directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator'
g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall -fPIC -DLINUX -D_REENTRANT
-DXALAN_INMEM_MSG_LOADER -c -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include
-I../../../../nls/include -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc
-I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o ../../../../obj/MsgFileOutputStream.o
/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/MsgFileOutputStream.cpp
g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall -fPIC -DLINUX -D_REENTRANT
-DXALAN_INMEM_MSG_LOADER -c -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include
-I../../../../nls/include -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc
-I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o ../../../../obj/ICUResHandler.o /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/ICUResHandler.cpp
g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall -fPIC -DLINUX -D_REENTRANT
-DXALAN_INMEM_MSG_LOADER -c -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include
-I../../../../nls/include -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc
-I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o ../../../../obj/InMemHandler.o /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/InMemHandler.cpp
g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall -fPIC -DLINUX -D_REENTRANT
-DXALAN_INMEM_MSG_LOADER -c -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include
-I../../../../nls/include -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc
-I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o ../../../../obj/MsgCreator.o /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/MsgCreator.cpp
g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall -fPIC -DLINUX -D_REENTRANT
-DXALAN_INMEM_MSG_LOADER -c -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include
-I../../../../nls/include -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc
-I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o ../../../../obj/NLSHandler.o /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/NLSHandler.cpp
g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall -fPIC -DLINUX -D_REENTRANT
-DXALAN_INMEM_MSG_LOADER -c -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include
-I../../../../nls/include -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc
-I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o ../../../../obj/SAX2Handler.o /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator/SAX2Handler.cpp
g++ -DLINUX -fPIC -DXALAN_INMEM_MSG_LOADER \
-L/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/lib -lxerces-c ../../../../obj/MsgFileOutputStream.o
../../../../obj/ICUResHandler.o ../../../../obj/InMemHandler.o ../../../../obj/MsgCreator.o
../../../../obj/NLSHandler.o ../../../../obj/SAX2Handler.o -o ../../../../bin/MsgCreator
make[3]: Leaving directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/MsgCreator'
../../../bin/MsgCreator /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/NLS/en_US/XalanMsg_en_US.xlf
-TYPE inmem -LOCALE en_US
make -C XalanMsgLib
make[3]: Entering directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/XalanMsgLib'
g++ -O2 -DNDEBUG -DXML_BITSTOBUILD_64 -fno-elide-constructors -Wall -fPIC -DLINUX -D_REENTRANT
-DXALAN_INMEM_MSG_LOADER -c -I/home/jpgalvan/TEST/xalan/xml-xalan/c/src -I/home/jpgalvan/TEST/xalan/xml-xalan/c/include
-I../../../../nls/include -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/src/ -I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/xercesc
-I/home/jpgalvan/TEST/xerces/xerces-c-3.0.1/include/ -o ../../../../obj/XalanMsgLib.o /home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp
/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp:25: error:
expected â,â or â;â before ânamespaceâ
/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp:74: error:
expected `}' at end of input
../../../../nls/include/LocalMsgData.hpp:34: warning: âxalanc_1_10::msgArrayâ defined but
not used
make[3]: *** [../../../../obj/XalanMsgLib.o] Error 1
make[3]: Leaving directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils/XalanMsgLib'
make[2]: *** [../../../lib/libxalanMsg.so.110.0] Error 2
make[2]: Leaving directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc/Utils'
make[1]: *** [locale] Error 2
make[1]: Leaving directory `/home/jpgalvan/TEST/xalan/xml-xalan/c/src/xalanc'
make: *** [all] Error 2
[root@aylinux64 c]#
Do you have an idea ?
Thanx in advance ...
Regards.
Jean-Pierre GALVAN.
________________________________
<http://www.sage.fr>
Jean-Pierre GALVAN
Equipe Industrialisation
Division Moyennes et Grandes Entreprises
+33 (0)4 50 64 10 42
Jean-Pierre.GALVAN@Sage.com
_________________________________________
6, avenue du Pré-Félin - BP 419 - 74944 Annecy-Le-Vieux CEDEX - France
Tél. 33(0)4 50 64 02 13 - Fax. 33(0)4 50 64 03 17
www.sageadonix.fr <http://www.sageadonix.fr/> www.sage.fr <http://www.sage.fr/>
Accélérateur d'entreprises
P
Please consider the environment before printing this mail note
Hey David,
Here's an example file...~30mb unzipped...nicely zipped to 98kb. To make sure I'm not messing
up on the code side here's basically what i'm doing:
XMLPlatformUtils::Initialize();
XalanTransformer::initialize();
XalanTransformer XSLTransformer;
std::string indentityXslPath = "D:\\Identity.xsl";
XSLTInputSource xslIn(indentityXslPath.c_str());
const XalanCompiledStylesheet * compiled_xslIn;
XSLTransformer.compileStylesheet(xslIn, compiled_xslIn);
XalanDOMString domStr;
DOMStringPrintWriter domSPW(domStr);
XSLTResultTarget objectOut(&domSPW);
XSLTInputSource xmlIn("D:\\bigXml.txt");
XSLTransformer.transform(xmlIn, compiled_xslIn, objectOut);
XalanTransformer::terminate();
XMLPlatformUtils::Terminate();
It gets to the transform and goes into never never land.
Thanks for the help,
Rob
Rob.Conde wrote: > Hey David, > I'm seeing some really bad performance while attempting to transform > a 30 megabyte xml file. As a benchmark, I tried running just the identity > transformation against my file in both .NET 2.0 and in Xalan. .NET took ~3 > seconds...I killed the Xalan after 25 minutes. I didn't try digging into the > Xalan code at all, but obviously some algorithm isn't scaling very nicely. That seems strange, since the identity transformation isn't really taxing the processor. Can you provide the XML file, or an obfuscated version of it, if it contains sensitive information? Dave
Hey David, I'm seeing some really bad performance while attempting to transform a 30 megabyte xml file. As a benchmark, I tried running just the identity transformation against my file in both .NET 2.0 and in Xalan. .NET took ~3 seconds...I killed the Xalan after 25 minutes. I didn't try digging into the Xalan code at all, but obviously some algorithm isn't scaling very nicely. Rob Conde
Sarko wrote: > Hi everybody! > > I hope I'm in the right forum. I've searched, I've read but still I didn't > manage to run the Xalan examples under Windows (use Linux you will say, but > you can't change enterprises policies). I think I set the CLASSPATH > properly: > C:\Programmi\xalan;C:\Programmi\xalan\xalansamples.jar;C:\Programmi\xalan\xalanservlet.jar;C:\Programmi\xalan\xalan.jar;C:\Programmi\xalan\serializer.jar;C:\Programmi\xalan\xml-apis.jar;C:\Programmi\xalan\xercesImpl.jar You need to ask this question on the Xalan-J user list, not the Xalan-C user list. > > If I execute this command > > C:\> java SimpleTransform > > the output is: > ------------------------------------------------ > exception in thread "main" java.lang.NoClassDefFounderror: SimpleTransform > Caused by: java.lang.ClassNotFoundException: SimpleTransform > ... > ... > Could not find the main class: SimpleTransform. Program will exit. > ----------------------------------------- > Unfortunately I'm new in the magic world of Apache and I don't even > understand where the problem lies... Do you have any idea about how to solve > this issue? You might try the -cp command line option, rather than the CLASSPATH environment variable. There are also some hints in the documentation: http://xml.apache.org/xalan-j/samples.html Dave
Hi everybody! I hope I'm in the right forum. I've searched, I've read but still I didn't manage to run the Xalan examples under Windows (use Linux you will say, but you can't change enterprises policies). I think I set the CLASSPATH properly: C:\Programmi\xalan;C:\Programmi\xalan\xalansamples.jar;C:\Programmi\xalan\xalanservlet.jar;C:\Programmi\xalan\xalan.jar;C:\Programmi\xalan\serializer.jar;C:\Programmi\xalan\xml-apis.jar;C:\Programmi\xalan\xercesImpl.jar If I execute this command C:\> java SimpleTransform the output is: ------------------------------------------------ exception in thread "main" java.lang.NoClassDefFounderror: SimpleTransform Caused by: java.lang.ClassNotFoundException: SimpleTransform ... ... Could not find the main class: SimpleTransform. Program will exit. ----------------------------------------- Unfortunately I'm new in the magic world of Apache and I don't even understand where the problem lies... Do you have any idea about how to solve this issue? Thank you so much! -- View this message in context: http://www.nabble.com/-newbie--Installing-Xalan-under-Windows-tp26012670p26012670.html Sent from the Xalan - C - Users mailing list archive at Nabble.com.
naijacoder wrote: > I have a software thats uses a xml viewer for printing.And what it does is > that we pass the xml and xsl file to it. > And i'm writing up a xslt for it and i need to make use of the EXSLT like > below. > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > xmlns:xalan = "http://xml.apache.org/xalan" > exclude-result-prefixes="xalan" version="1.0"> > > Then tried to use it like below > <xsl:for-each select="xalan:nodeset($unified-data)/row[(position() mod > $page-size) = 1]"> > > i get error:XalanError: The specified function is not available: > http://xml.apache.org/xalan > :nodeset Your version of Xalan-C doesn't support this extension function. Also, this is not an EXSLT extension function -- it's a Xalan-C proprietary extension function. The EXSLT function is in the namespace "http://exslt.org/common," and has the local name "node-set". > I have setup an environment where i downloaded the latest xalan lib > including xerces-c_2_7.dll > after testing the same xsl file against the same xml file i get the the > result i want. The current version does. > Does xerces-c_1_5_1.dll works with EXSLT(Extensions Lib) is it supported. That's the DLL for Xerces-C, not for Xalan-C. Also, that's an extremely old version of Xerces, so I suspect you're also using an ancient version of Xalan-C. You should upgrade. Dave
I have a software thats uses a xml viewer for printing.And what it does is
that we pass the xml and xsl file to it.
And i'm writing up a xslt for it and i need to make use of the EXSLT like
below.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xalan = "http://xml.apache.org/xalan"
exclude-result-prefixes="xalan" version="1.0">
Then tried to use it like below
<xsl:for-each select="xalan:nodeset($unified-data)/row[(position() mod
$page-size) = 1]">
i get error:XalanError: The specified function is not available:
http://xml.apache.org/xalan
:nodeset
I have setup an environment where i downloaded the latest xalan lib
including xerces-c_2_7.dll
after testing the same xsl file against the same xml file i get the the
result i want.
Does xerces-c_1_5_1.dll works with EXSLT(Extensions Lib) is it supported.
Thanks on Advance
--
View this message in context: http://www.nabble.com/xerces-c_1_5_1.dll-does-it-work-with-EXSLT%28Extensions-Lib%29.Is-it-supported--tp25952919p25952919.html
Sent from the Xalan - C - Users mailing list archive at Nabble.com.
Albers, Michael wrote: > Dave, > > I'm using the 2 parameter version of parseXMLStream, though I'm not providing the 2nd parameter, just using the default value. Regardless, in the Xalan code I have (v1.10), ensureDOMParser is not called, but rather createDOMParser is. Ah, I was referring to the latest source code, so this is indeed a bug that's been fixed. You can either upgrade, or merge the changes into your version of the source. Dave
Dave,
I'm using the 2 parameter version of parseXMLStream, though I'm not providing the 2nd parameter,
just using the default value. Regardless, in the Xalan code I have (v1.10), ensureDOMParser
is not called, but rather createDOMParser is.
Michael Albers
-----Original Message-----
From: David Bertoni [mailto:dbertoni@apache.org]
Sent: Tuesday, September 15, 2009 12:37 PM
To: xalan-c-users@xml.apache.org
Subject: Re: Modifying behavior of XercesParserLiaison
Albers, Michael wrote:
> Hello,
>
> I've been trying to use the
> XercesParserLiaison::setExternalSchemaLocation function call and have
> found that it has no effect. Looking at the source code for
> XercesParserLiaison it appears that none of the behavior modification
> get/set functions actually have any effect because the
> XercesParserLiaison::ensureDOMParser call is never made and can't be
> called by the user. Will this be changed in a future release of Xalan?
> In the meantime, is there any way to work around this? It isn't
> critical for me at this point but the XercesParserLiaison API is very misleading.
XercesParserLiaison::ensureDOMParser() is called by XercesParserLiaison::parseXMLStream(const
InputSource& inputSource,
const XalanDOMString& identifier), from what I can tell. Are you perhaps calling
the version the overload that accepts a DocumentHandler?
Since the SAXParser doesn't support schema processing, there's no reason to use those properties
for that call. I will tighten up the documentation for the property calls to clarify the situation.
Dave
Albers, Michael wrote:
> Hello,
>
> I've been trying to use the
> XercesParserLiaison::setExternalSchemaLocation function call and have
> found that it has no effect. Looking at the source code for
> XercesParserLiaison it appears that none of the behavior modification
> get/set functions actually have any effect because the
> XercesParserLiaison::ensureDOMParser call is never made and can't be
> called by the user. Will this be changed in a future release of Xalan?
> In the meantime, is there any way to work around this? It isn't critical
> for me at this point but the XercesParserLiaison API is very misleading.
XercesParserLiaison::ensureDOMParser() is called by
XercesParserLiaison::parseXMLStream(const InputSource& inputSource,
const XalanDOMString& identifier), from what I can tell. Are
you perhaps calling the version the overload that accepts a DocumentHandler?
Since the SAXParser doesn't support schema processing, there's no reason
to use those properties for that call. I will tighten up the
documentation for the property calls to clarify the situation.
Dave
Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello, I've been trying to use the XercesParserLiaison::setExternalSchemaLocation function call and have found that it has no effect. Looking at the source code for XercesParserLiaison it appears that none of the behavior modification get/set functions actually have any effect because the XercesParserLiaison::ensureDOMParser call is never made and can't be called by the user. Will this be changed in a future release of Xalan? In the meantime, is there any way to work around this? It isn't critical for me at this point but the XercesParserLiaison API is very misleading. Michael Albers
Ellonnic2 wrote:
> Hello,
>
> I already have a XalanParsedSource and multiple XSLTInputSources. I want to
> transform my XalanParsedSource using each of the XSLTInputSources, while
> each time feeding the result of the transformation into the next
> transformation without touching the hard drive until the very end. Here is
> some pseudocode that should help to convey what I'm trying to accomplish:
>
> void ApplyXSLTCascade(
> XalanParsedSource originalXPS,
> XSLTInputSource styleSheetsArray[],
> char* fileName)
> {
> XalanParsedSource xps = originalXPS;
> for (each XSLTInputSource x in styleSheetsArray)
> {
> xps = transform(xps, x)
> }
>
> if (fileName)
> writeToFile(xps, fileName)
> else
> writeToConsole(xps)
> }
>
> As I mentioned, this unfortunately needs to be as-fast-as-possible and so
> the program cannot touch the disk until after the last transformation has
> been applied. Does anyone have any ideas on how to do this?
You can do this by transforming to another source tree, but you will
need to make sure your stylesheet produces a well-formed XML document.
It will also require a fair amount of memory, since you'll have multiple
trees in memory at the same time.
Is there any reason you just can't transform to a memory buffer? Take a
look at the StreamTransform sample for more information on how to do
that. This requires more parsing time, but doesn't place any limitations
on the result of the transformation, and doesn't require multiple trees
in memory at the same time.
Dave
Hello,
I already have a XalanParsedSource and multiple XSLTInputSources. I want to
transform my XalanParsedSource using each of the XSLTInputSources, while
each time feeding the result of the transformation into the next
transformation without touching the hard drive until the very end. Here is
some pseudocode that should help to convey what I'm trying to accomplish:
void ApplyXSLTCascade(
XalanParsedSource originalXPS,
XSLTInputSource styleSheetsArray[],
char* fileName)
{
XalanParsedSource xps = originalXPS;
for (each XSLTInputSource x in styleSheetsArray)
{
xps = transform(xps, x)
}
if (fileName)
writeToFile(xps, fileName)
else
writeToConsole(xps)
}
As I mentioned, this unfortunately needs to be as-fast-as-possible and so
the program cannot touch the disk until after the last transformation has
been applied. Does anyone have any ideas on how to do this?
~DPD
--
View this message in context: http://www.nabble.com/Applying-Multiple-XSLTs-%28In-Memory-Only%29-tp25389413p25389413.html
Sent from the Xalan - C - Users mailing list archive at Nabble.com.
I feel so foolish. You were absolutely right about the DLL. The batch file
I wrote that started VS2005 was trying to use a quote (") to set the path
environment variable, and consequently the bin directory wasn't being added
correctly to the path. Anyway, thanks again! You're too nice!!!
~DPD
--
View this message in context: http://www.nabble.com/Windows---samples-fail-on-%22transform%28...%29%22-when-using-%22cout%22-tp25192539p25370993.html
Sent from the Xalan - C - Users mailing list archive at Nabble.com.
Ellonnic2 wrote:
> Hi Dave,
>
> Thanks so much for your reply. I think I'm 98% of the way there. I just
> have one minor issue. Once I have everything seemingly set up correctly,
> when I build, I get the following:
>
> "Cannot open include file: 'LocalMsgIndex.hpp': No such file or directory"
> and then lots of
> "fatal error C1083: Cannot open include file: 'LocalMsgIndex.hpp': No such
> file or directory"
This usually occurs because the Xerces-C DLL cannot be located, so the
message generation utility can't execute. Please make sure the Xerces-C
directories that contain the debug and release Xerces-C DLLs are on your
path. Alternatively, you can copy those binaries to the appropriate
Xalan-C output directories. To do this, I usually just build the
MsgCreator project for the configurations I'm interested in, then copy
the appropriate binaries into the resulting output directories under the
Build directory. Remember to copy the release DLL to any release
configuration output directories and the debug DLL to any debug
configuration output directories.
> Now, I understand that there is a FAQ for the "Missing LocalMsgIndex.hpp
> file", however, this seemingly only tells me that this file should have been
> generated. Does this error force me to now have to build with ICU support?
> When I changed the target from "Debug with ICU" to "Debug", it had no
> effect.
That won't fix the problem, since the issue is you're missing the
Xerces-C DLLs.
> Changing topics, on the Xalan download site
> ("http://xml.apache.org/xalan-c/download.html"), I do not see any Macintosh
> information, but the source code has a "c\Projects\MacOS" directory. Which
> OSes does the most recent source code support that is not on the site's
> list?
That configuration has not been maintained for many years, and in fact,
it's project files for Apple's ProjectBuilder IDE, which is no longer
being developed.
Dave
Hi Dave,
Thanks so much for your reply. I think I'm 98% of the way there. I just
have one minor issue. Once I have everything seemingly set up correctly,
when I build, I get the following:
"Cannot open include file: 'LocalMsgIndex.hpp': No such file or directory"
and then lots of
"fatal error C1083: Cannot open include file: 'LocalMsgIndex.hpp': No such
file or directory"
Now, I understand that there is a FAQ for the "Missing LocalMsgIndex.hpp
file", however, this seemingly only tells me that this file should have been
generated. Does this error force me to now have to build with ICU support?
When I changed the target from "Debug with ICU" to "Debug", it had no
effect.
Changing topics, on the Xalan download site
("http://xml.apache.org/xalan-c/download.html"), I do not see any Macintosh
information, but the source code has a "c\Projects\MacOS" directory. Which
OSes does the most recent source code support that is not on the site's
list?
--
View this message in context: http://www.nabble.com/Windows---samples-fail-on-%22transform%28...%29%22-when-using-%22cout%22-tp25192539p25368970.html
Sent from the Xalan - C - Users mailing list archive at Nabble.com.
Albers, Michael wrote:
> Hello,
>
> I've been trying to use Xalan on an AIX machine and have run into some
> problems. I've been using the exact same code and XML on a Solaris
> platform with no issues. Despite my best efforts in tweaking my code and
> looking through forums I haven't been able to solve my AIX woes.
>
> I've been experiencing three problems, detailed below.
>
> 1. XPathEvaluator::terminate is causing my application to core. I've
> traced this to a pure virtual function, XalanList::allocate, being
> called by the memory manager instance. This but isn't much of an issue
> as I'm implementing a wrapper class which will be the exclusive means
> for other code to use the Xalan API. To do the initialization and
> termination I created a singleton static subclass. The Xalan/Xerces
> initialization is done in the constructor and the termination, in the
> destructor. This way the compiler does most of the work and the user's
> of my code need not worry about initialization. Since the termination
> will be done on process termination actually terminating Xalan doesn't
> seem to be much of an issue.
This usually occurs because of order-of-destruction issues. Please
verify you have no existing Xalan-C objects before your static singleton
class is destroyed.
You're probably seeing a difference in behavior on the two platforms
because the order of destruction of static objects is not specified
between compilation units. It's very difficult if not impossible to get
this to work right, because each platform is different.
AIX does have a notion of destructor priorities for shared objects, so
you may want to exploit this feature to ensure the shared object
initialization and destruction sequence works between the Xalan-C and
Xerces-C libraries, and a higher priority than other shared objects that
depend on yours. This can be tricky to do, so you may need to abandon
your dependency on a static singleton object. This will also allow
better error-handling, since you will be unable to gracefully handle
errors initializing the Xerces-C and Xalan-C libraries
>
> 2. XPaths won't evaluate when using namespaces in the XML. My code is
> heavily based off of the SimpleXPathAPI sample. When I run
> SimpleXPathAPI with my XML (with namespaces) the data is retrieved
> correctly. When I use the exact same XPath with my code no results are
> returned. I've made sure that the XML is valid and the XPath is
> syntactically correct.
This usually occurs because you're not providing an appropriate
PrefixResolver instance to resolve the namespace prefixes in the
document. You can search the archives of the mailing list for the
string "PrefixResolver" to see more Xalan-specific details for dealing
with this.
> 3. In my efforts to fix number two I tried removing the namespace from
> my XML. That worked somewhat better but now my application cores later
> on down the line. After retrieving about half of the data from the XML
> the core happens. I've tracked this down to another pure virtual
> function being called. This time the call happens in
> XalanReferenceCountedObject::removeReference.
You will need to provide a stack trace at a minimum, but I suspect if
your code works on other platforms, but doesn't on AIX, there are
compiler issues getting in the way.
One common cause of this is not obeying the rules of the XPathEvaluator
APIs. For example, the evaluate() member functions that return
XObjectPtr instances make it explicit you cannot call any of the
evaluate() member functions again while the returned object is still in
scope. For example, this pseudo-code can cause the error you're seeing:
const XObjectPtr theResult1(
theEvaluator.evaluate(
theDOMSupport,
theContextNode,
XPath1.c_str(),
thePrefixResolver));
const XObjectPtr theResult2(
theEvaluator.evaluate(
theDOMSupport,
theContextNode,
XPath2.c_str(),
thePrefixResolver));
Since XObjectPtr is a smart-pointer to an implementation class, making a
copy of the returned XObjectPtr won't work. Instead, you'll need to
make a copy of the underlying data. See the post for more info:
http://marc.info/?l=xalan-c-users&m=123615175207902&w=2
I would suggest you build a debug version of the library on AIX, which
will enable run-time assertions, which may help you catch problems of
this nature sooner.
> For what it's worth here's some various version information.
>
> Xalan: 1.10
> Xerces: 2.7
> AIX: 6.1 TL2 SP2
> xlC_r 09.00.0000.0006
Xalan-C hasn't been built regularly on AIX since xlC 6.0, and I have no
access to an AIX machine much less the AIX compiler, so it's unlikely I
can offer too much assistance.
Dave
Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello, I've been trying to use Xalan on an AIX machine and have run into some problems. I've been using the exact same code and XML on a Solaris platform with no issues. Despite my best efforts in tweaking my code and looking through forums I haven't been able to solve my AIX woes. I've been experiencing three problems, detailed below. 1. XPathEvaluator::terminate is causing my application to core. I've traced this to a pure virtual function, XalanList::allocate, being called by the memory manager instance. This but isn't much of an issue as I'm implementing a wrapper class which will be the exclusive means for other code to use the Xalan API. To do the initialization and termination I created a singleton static subclass. The Xalan/Xerces initialization is done in the constructor and the termination, in the destructor. This way the compiler does most of the work and the user's of my code need not worry about initialization. Since the termination will be done on process termination actually terminating Xalan doesn't seem to be much of an issue. 2. XPaths won't evaluate when using namespaces in the XML. My code is heavily based off of the SimpleXPathAPI sample. When I run SimpleXPathAPI with my XML (with namespaces) the data is retrieved correctly. When I use the exact same XPath with my code no results are returned. I've made sure that the XML is valid and the XPath is syntactically correct. 3. In my efforts to fix number two I tried removing the namespace from my XML. That worked somewhat better but now my application cores later on down the line. After retrieving about half of the data from the XML the core happens. I've tracked this down to another pure virtual function being called. This time the call happens in XalanReferenceCountedObject::removeReference. For what it's worth here's some various version information. Xalan: 1.10 Xerces: 2.7 AIX: 6.1 TL2 SP2 xlC_r 09.00.0000.0006 I understand that what I've given you to work with isn't much, but unfortunately that's all I have. I'm unable to give you any source code or the XML I'm using. Anything you can give my to try would be accepted gratefully. Thanks, Michael Albers
Ellonnic2 wrote: > Hi Dave, > > Thanks for your reply. > > I only built the sample code, not the Xalan or Xerces source code itself. > To be more specific, I downloaded and used the binary distribution of both > Xerces (xerces-c_2_7_0-windows_2000-msvc_60.zip) and Xalan > (Xalan-C_1_10_0-win32-msvc_60.zip). > > Trying to step over this very line: > theResult = theXalanTransformer.transform(argv[1], argv[2], cout); > consistently causes the "Unhandled exception at ... in XalanTransform.exe: > ...: Access violation reading location ...." failure. > > Is it because I'm using Visual Studio 2005 to build this and the binaries > were built using Visual C++ 6.0? If so, how do resolve that without having > to upgrade Visual Studio versions?o You can't mix the binaries built with VS6 with binaries you built with VS2005 -- Microsoft's run-time libraries are not compatible. If you need to build with VS2005, first download the Xerces-C vs2005 binaries, or build Xerces-C 3.0.1 from the source code: http://apache.securedservers.com/xerces/c/3/binaries/xerces-c-3.0.1-x86-windows-vc-8.0.zip http://apache.securedservers.com/xerces/c/3/sources/xerces-c-3.0.1.zip Then, you'll need to check out the latest Xalan-C source code from the Subversion repository. It's fairly easy to do using a GUI program like TortoiseSVN: http://tortoisesvn.net/downloads After you install TortoiseSVN, open Windows Explorer and navigate to the folder where you want to check out the sources. Right-click in the folder, then enter the following URL in the edit field: http://svn.apache.org/repos/asf/xalan/c/trunk You can also specify a subdirectory or the checkout in the second edit field, if you want. Then, you can follow the Windows build instructions here: http://xml.apache.org/xalan-c/build_instruct.html#dotNet Note you'll need to open the project files for VC8 instead of VC7.1, since you're using VS2005. Also, please make sure you put the Xerces-C DLLs (both debug and release) somewhere on your path, so they will be found during the Xalan-C build process. I typically add the Xerces-C output directories to the path, but you may find it easier to put them in a single directory and put that directory on your path. If you have any questions or problems, just post a reply. Dave
Hi Dave, Thanks for your reply. I only built the sample code, not the Xalan or Xerces source code itself. To be more specific, I downloaded and used the binary distribution of both Xerces (xerces-c_2_7_0-windows_2000-msvc_60.zip) and Xalan (Xalan-C_1_10_0-win32-msvc_60.zip). Trying to step over this very line: theResult = theXalanTransformer.transform(argv[1], argv[2], cout); consistently causes the "Unhandled exception at ... in XalanTransform.exe: ...: Access violation reading location ...." failure. Is it because I'm using Visual Studio 2005 to build this and the binaries were built using Visual C++ 6.0? If so, how do resolve that without having to upgrade Visual Studio versions?o ~Dan -- View this message in context: http://www.nabble.com/Windows---samples-fail-on-%22transform%28...%29%22-when-using-%22cout%22-tp25192539p25205124.html Sent from the Xalan - C - Users mailing list archive at Nabble.com.
Ellonnic2 wrote: > Hello, > > Many of Xalan's samples redirect the program's output to stdout by passing > in "cout" as the last parameter to the "transform(...)" method. This works > fine with the executables provided along with the binary distribution of > Xalan. However, if I instead build the sample source-code myself using > Visual Studio 2005, I get a crash/exception whenever I execute any transform > call using "cout" as the last parameter (the attached XalanTransform.cpp has > the simplest example of this). > > theResult = theXalanTransformer.transform(argv[1], argv[2], cout); > > Does anyone know why this happens and/or how to prevent it??? That seems very strange. Some questions: 1. Did you also build Xerces-C from source source, or did you download the binary distribution? 2. How did you build Xalan-C 1.10 using VS2005? You would need to make a lot of source code changes to build it (the current repository version builds with VS2005). 3. Have you run your executable in the debugger to determine where the access violation occurs? Dave
Hello, Many of Xalan's samples redirect the program's output to stdout by passing in "cout" as the last parameter to the "transform(...)" method. This works fine with the executables provided along with the binary distribution of Xalan. However, if I instead build the sample source-code myself using Visual Studio 2005, I get a crash/exception whenever I execute any transform call using "cout" as the last parameter (the attached XalanTransform.cpp has the simplest example of this). theResult = theXalanTransformer.transform(argv[1], argv[2], cout); Does anyone know why this happens and/or how to prevent it??? Thanks in advance for your time and patience, ~Dan http://www.nabble.com/file/p25192539/XalanTransform.cpp XalanTransform.cpp -- View this message in context: http://www.nabble.com/Windows---samples-fail-on-%22transform%28...%29%22-when-using-%22cout%22-tp25192539p25192539.html Sent from the Xalan - C - Users mailing list archive at Nabble.com.
David S. wrote: > What I'm thinking of is something like this: > > <xsl:sort select="hname" lang="he" data-type="text" order="ascending"/> > > Is this possible with Xalan? If you build with ICU support, Hebrew collation is supported. Dave
What I'm thinking of is something like this: <xsl:sort select="hname" lang="he" data-type="text" order="ascending"/> Is this possible with Xalan? TiA -- View this message in context: http://www.nabble.com/Can-I-sort-Hebrew-strings-with-xslt%3Asort--tp25073002p25073002.html Sent from the Xalan - C - Users mailing list archive at Nabble.com.
paul.bandler@nomura.com wrote: > Ah, thanks. > > I did in fact try to do exactly that - but I need to append another > entire document (created by XalanSourceTreeParserLiaison > /XalanSourceTreeDOMSupport) as the child of the root of the XercesDOM > document generated by XSLT+FormatterToXercesDOM. I've tried appending > the root of the parsed document to the first child of the XSLT generated > DOM but it didn't work and it occurred to me that I might need to do > something special to take care of transferring the ownership of the > parsed DOM nodes to the generated XSLT/DOM? I tried using clone but > that didn't seem to work either. These are standard DOM API issues. First of all, you'll need to use the DOMDocument::importNode() member function to create new nodes in the context of the target document. You can then call DOMMode::appendNode() to add the new nodes to the tree. Finally, you cannot import a document node to another document. Instead, you'll need to append the document element, which you can get by calling DOMDocument::getDocumentElement(). Please ask future questions regarding the Xerces-C DOM on the Xerces-C user list. You can find good DOM API documentation by searching using your favorite search engine. Dave
paul.bandler@nomura.com wrote: >> However, you might want to look at the XSLT document function, instead >> of generating a result DOM and modifying it. You can use the >> xsl:copy-of instruction to copy an entire document > > While that sounds like an eminently good suggestion, I need to make this > change without altering the XSLT workings of this program. > >> If you want a mutable result, then yes, you have to use the Xerces-C > DOM. > > Ok, thanks so what I'm trying to is possible. You probably haven't > wanted to tell me what is probably plainly obvious to anyone more > familiar with these API's, but how do I alter an existing DOM document - > I've seen and used the content handler to create a new document, but > once its 'endDocument' method has been called - can the constructed > document be further modified? Take a look at the TransformToXercesDOM sample program, which shows how to generate an instance of the Xerces-C DOM as the result of a transformation. Once you've finished the XSLT part, you can modify the DOM instance using the standard DOM APIs. Dave
Ah, thanks.
I did in fact try to do exactly that - but I need to append another
entire document (created by XalanSourceTreeParserLiaison
/XalanSourceTreeDOMSupport) as the child of the root of the XercesDOM
document generated by XSLT+FormatterToXercesDOM. I've tried appending
the root of the parsed document to the first child of the XSLT generated
DOM but it didn't work and it occurred to me that I might need to do
something special to take care of transferring the ownership of the
parsed DOM nodes to the generated XSLT/DOM? I tried using clone but
that didn't seem to work either.
> I developed an API that wraps xercesc/msxml2/libxml API's into one
easy to use
There's a hint in what you write above that I'm perhaps not alone in
finding the Xalan/Xerces API set a little overwhelming sometimes...? I
had the same task as above to accomplish in Java and was able to achieve
it quickly in a few lines using DOM4J. After a couple of days of
struggling with Xalan/Xerces in C++ I had to give up and resort to a
crude string manipulation to insert the new document text before the
closing tag of the parent document...
-----Original Message-----
From: Hans Smit [mailto:jcsmit@xs4all.nl]
Sent: 14 August 2009 14:08
To: xalan-c-users@xml.apache.org
Subject: RE: Relative newbie question - How to augment XSLT generated
output?
Sorry for the confusion.
This is the trick I was talking about:
xercesc::DOMDocument * outDoc =
xercesc::DOMImplementation::getImplementation()->createDocument();
xalanc::FormatterToXercesDOM theFormatter(outDoc, 0);
The FormatterToXercesDOM instance can than be passed to the xalanc
transform method. This than transforms the output to an
xercesc::DOMDocument, which you can then manipulate with
appendChild/removeChild/etc.
The code I gave you is a fragment. The only parts of it your interested
in
are the object references beginning with the namespaces identifier
"xercesc::*" and "xalanc::*".
The "new DOMDocumentImpl(outDoc);" call is a call to my own
implementation
wrapper of the xercesc::DOMDocument class.
Also note that the mTransformer + mStyleSheet are defined as attributes
of
my wrapper class:
xalanc::XalanTransformer mTransformer;
const xalanc::XalanCompiledStylesheet * mStyleSheet;
I hope this provides some clarity.
Hans
> Thanks for the reply but..
>
>> The trick your looking for is outlined in transformToDocument method.
>
> Are you referring to:-
>
> return new DOMDocumentImpl(outDoc); ??
>
> DOMDocumentImpl doesn't appear in the external API (packaged Doxyden),
> and the class in the implementation doesn't have a public constructor
> that matches the above as far as I can see...
>
> public:
> DOMDocumentImpl(MemoryManager* const manager =
> XMLPlatformUtils::fgMemoryManager);
> DOMDocumentImpl(const XMLCh* namespaceURI, //DOM Level 2
> const XMLCh* qualifiedName,
> DOMDocumentType* doctype,
> MemoryManager* const manager =
> XMLPlatformUtils::fgMemoryManager);
>
> ...
>
> private:
> ...
> //
>
-----------------------------------------------------------------------
> // Unimplemented constructors and operators
> //
>
-----------------------------------------------------------------------
> DOMDocumentImpl(const DOMDocumentImpl &);
> DOMDocumentImpl & operator = (const DOMDocumentImpl &);
>
> What am I missing ....?
>
>
> -----Original Message-----
> From: Hans Smit [mailto:jcsmit@xs4all.nl]
> Sent: 14 August 2009 13:23
> To: xalan-c-users@xml.apache.org
> Subject: RE: Relative newbie question - How to augment XSLT generated
> output?
>
> This may be what your looking for:
>
> NOTE: this is just a fragment of a class I've developed, so if you try
> to
> compile "as-is" you will get errors. The trick your looking for is
> outlined in transformToDocument method.
>
> Just in case your wondering about the "xmlapi" namespace - I developed
> an
> API that wraps xercesc/msxml2/libxml API's into one easy to use
> interface.
> Toggling between vendors is just a matter of flicking a processor
> switch.
> Nice.
>
> [source]
>
> ...
>
> //--------------------------------------------------------------
> xmlapi::DOMDocument::ptr transformToDocument () {
>
> xercesc::DOMDocument * outDoc =
> xercesc::DOMImplementation::getImplementation()->createDocument();
> xalanc::FormatterToXercesDOM theFormatter(outDoc, 0);
> transform_impl(theFormatter);
> return new DOMDocumentImpl(outDoc);
> }
>
> //--------------------------------------------------------------
> void transform (std::ostream & sstrm, bool
> indent) {
> transform_impl(sstrm);
> }
>
> private:
> //--------------------------------------------------------------
> template<class Output>
> void transform_impl (Output & out) {
> int err = 0;
> xalanc::XercesParserLiaison parserLiaison;
> #ifdef XERCESC_3
> xalanc::XercesDOMSupport domSupport(parserLiaison);
> #else
> xalanc::XercesDOMSupport domSupport;
> #endif
> if (mInput.get() == NULL) {
> throw xmlapi::XMLException(EXCEPTION_HERE, "input xml is NULL");
> }
> if (mStyleSheet == NULL) {
> throw xmlapi::XMLException(EXCEPTION_HERE, "compiled styleheet
is
> NULL");
> }
> bool threadSafe = true;
> bool buildWrapper = true;
> xercesc::DOMDocument * xmlDoc =
> dynamic_cast<DOMDocumentImpl*>(mInput.get())->mDoc;
> xalanc::XalanDocument * xalanDocument =
> parserLiaison.createDocument(xmlDoc, threadSafe, buildWrapper);
> xalanc::XercesDOMWrapperParsedSource parsedSource (
> parserLiaison.mapToXercesDocument(xalanDocument),
> parserLiaison,
> domSupport,
> xalanc::XalanDOMString()
> );
> err = mTransformer.transform(parsedSource, mStyleSheet, out);
> if (err) {
> const char * errMsg = mTransformer.getLastError();
> if (!errMsg) {
> errMsg = "Unknown transform exception";
> }
> throw xmlapi::XMLException(EXCEPTION_HERE, errMsg);
> }
> }
>
> ...
>
> [/source]
>
>
> Kind regards,
>
> Hans
>
>
>
>>>However, you might want to look at the XSLT document function,
instead
>>>of generating a result DOM and modifying it. You can use the
>>>xsl:copy-of instruction to copy an entire document
>>
>> While that sounds like an eminently good suggestion, I need to make
> this
>> change without altering the XSLT workings of this program.
>>
>>> If you want a mutable result, then yes, you have to use the Xerces-C
>> DOM.
>>
>> Ok, thanks so what I'm trying to is possible. You probably haven't
>> wanted to tell me what is probably plainly obvious to anyone more
>> familiar with these API's, but how do I alter an existing DOM
document
> -
>> I've seen and used the content handler to create a new document, but
>> once its 'endDocument' method has been called - can the constructed
>> document be further modified?
>>
>> -----Original Message-----
>> From: David Bertoni [mailto:dbertoni@apache.org]
>> Sent: 13 August 2009 19:07
>> To: xalan-c-users@xml.apache.org
>> Subject: Re: Relative newbie question - How to augment XSLT generated
>> output?
>>
>> paul.bandler@nomura.com wrote:
>>> I need to be able to augment an XSLT generated document by adding
the
>>> contents of another document to it as a child node. I tried
>> generating
>>> to an XalanSourceTreeDocument but when I invoked addChild an
>>> XalanDOMException was raised with code 7 (modification not allowed).
>> Do
>>> I need to generate to an Xerces DOM instead, using
>> FormatterToXercesDOM
>>> as per one of the examples, and if so what are the steps to add one
>>> document as the child of another XercesDOM - i.e. can I indeed add
to
>> a
>>> fully formed document and do I need to clone the nodes from one
>> document
>>> before adding to another?
>> If you want a mutable result, then yes, you have to use the Xerces-C
>> DOM.
>>
>> However, you might want to look at the XSLT document function,
instead
>> of generating a result DOM and modifying it. You can use the
>> xsl:copy-of instruction to copy an entire document anywhere you like
> in
>> the result tree. It will also be much more efficient than generating
> a
>> Xerces-C DOM document as the result, then appending another document.
>>
>> Dave
>>
>>
>>
>> This e-mail (including any attachments) is confidential, may contain
>> proprietary or privileged information and is intended for the named
>> recipient(s) only. Unintended recipients are prohibited from taking
> action
>> on the basis of information in this e-mail and must delete all
copies.
>> Nomura will not accept responsibility or liability for the accuracy
or
>> completeness of, or the presence of any virus or disabling code in,
> this
>> e-mail. If verification is sought please request a hard copy. Any
>> reference
>> to the terms of executed transactions should be treated as
preliminary
>> only
>> and subject to formal written confirmation by Nomura. Nomura reserves
> the
>> right to monitor e-mail communications through its networks (in
> accordance
>> with applicable laws). No confidentiality or privilege is waived or
> lost
>> by
>> Nomura by any mistransmission of this e-mail. Any reference to
> "Nomura" is
>> a reference to any entity in the Nomura Holdings, Inc. group. Please
> read
>> our Electronic Communications Legal Notice which forms part of this
>> e-mail:
>> http://www.Nomura.com/email_disclaimer.htm
>>
>>
>>
>
>
>
>
>
> This e-mail (including any attachments) is confidential, may contain
> proprietary or privileged information and is intended for the named
> recipient(s) only. Unintended recipients are prohibited from taking
action
> on the basis of information in this e-mail and must delete all copies.
> Nomura will not accept responsibility or liability for the accuracy or
> completeness of, or the presence of any virus or disabling code in,
this
> e-mail. If verification is sought please request a hard copy. Any
> reference
> to the terms of executed transactions should be treated as preliminary
> only
> and subject to formal written confirmation by Nomura. Nomura reserves
the
> right to monitor e-mail communications through its networks (in
accordance
> with applicable laws). No confidentiality or privilege is waived or
lost
> by
> Nomura by any mistransmission of this e-mail. Any reference to
"Nomura" is
> a reference to any entity in the Nomura Holdings, Inc. group. Please
read
> our Electronic Communications Legal Notice which forms part of this
> e-mail:
> http://www.Nomura.com/email_disclaimer.htm
>
>
>
This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm
Sorry for the confusion.
This is the trick I was talking about:
xercesc::DOMDocument * outDoc =
xercesc::DOMImplementation::getImplementation()->createDocument();
xalanc::FormatterToXercesDOM theFormatter(outDoc, 0);
The FormatterToXercesDOM instance can than be passed to the xalanc
transform method. This than transforms the output to an
xercesc::DOMDocument, which you can then manipulate with
appendChild/removeChild/etc.
The code I gave you is a fragment. The only parts of it your interested in
are the object references beginning with the namespaces identifier
"xercesc::*" and "xalanc::*".
The "new DOMDocumentImpl(outDoc);" call is a call to my own implementation
wrapper of the xercesc::DOMDocument class.
Also note that the mTransformer + mStyleSheet are defined as attributes of
my wrapper class:
xalanc::XalanTransformer mTransformer;
const xalanc::XalanCompiledStylesheet * mStyleSheet;
I hope this provides some clarity.
Hans
> Thanks for the reply but..
>
>> The trick your looking for is outlined in transformToDocument method.
>
> Are you referring to:-
>
> return new DOMDocumentImpl(outDoc); ??
>
> DOMDocumentImpl doesn't appear in the external API (packaged Doxyden),
> and the class in the implementation doesn't have a public constructor
> that matches the above as far as I can see...
>
> public:
> DOMDocumentImpl(MemoryManager* const manager =
> XMLPlatformUtils::fgMemoryManager);
> DOMDocumentImpl(const XMLCh* namespaceURI, //DOM Level 2
> const XMLCh* qualifiedName,
> DOMDocumentType* doctype,
> MemoryManager* const manager =
> XMLPlatformUtils::fgMemoryManager);
>
> ...
>
> private:
> ...
> //
> -----------------------------------------------------------------------
> // Unimplemented constructors and operators
> //
> -----------------------------------------------------------------------
> DOMDocumentImpl(const DOMDocumentImpl &);
> DOMDocumentImpl & operator = (const DOMDocumentImpl &);
>
> What am I missing ....?
>
>
> -----Original Message-----
> From: Hans Smit [mailto:jcsmit@xs4all.nl]
> Sent: 14 August 2009 13:23
> To: xalan-c-users@xml.apache.org
> Subject: RE: Relative newbie question - How to augment XSLT generated
> output?
>
> This may be what your looking for:
>
> NOTE: this is just a fragment of a class I've developed, so if you try
> to
> compile "as-is" you will get errors. The trick your looking for is
> outlined in transformToDocument method.
>
> Just in case your wondering about the "xmlapi" namespace - I developed
> an
> API that wraps xercesc/msxml2/libxml API's into one easy to use
> interface.
> Toggling between vendors is just a matter of flicking a processor
> switch.
> Nice.
>
> [source]
>
> ...
>
> //--------------------------------------------------------------
> xmlapi::DOMDocument::ptr transformToDocument () {
>
> xercesc::DOMDocument * outDoc =
> xercesc::DOMImplementation::getImplementation()->createDocument();
> xalanc::FormatterToXercesDOM theFormatter(outDoc, 0);
> transform_impl(theFormatter);
> return new DOMDocumentImpl(outDoc);
> }
>
> //--------------------------------------------------------------
> void transform (std::ostream & sstrm, bool
> indent) {
> transform_impl(sstrm);
> }
>
> private:
> //--------------------------------------------------------------
> template<class Output>
> void transform_impl (Output & out) {
> int err = 0;
> xalanc::XercesParserLiaison parserLiaison;
> #ifdef XERCESC_3
> xalanc::XercesDOMSupport domSupport(parserLiaison);
> #else
> xalanc::XercesDOMSupport domSupport;
> #endif
> if (mInput.get() == NULL) {
> throw xmlapi::XMLException(EXCEPTION_HERE, "input xml is NULL");
> }
> if (mStyleSheet == NULL) {
> throw xmlapi::XMLException(EXCEPTION_HERE, "compiled styleheet is
> NULL");
> }
> bool threadSafe = true;
> bool buildWrapper = true;
> xercesc::DOMDocument * xmlDoc =
> dynamic_cast<DOMDocumentImpl*>(mInput.get())->mDoc;
> xalanc::XalanDocument * xalanDocument =
> parserLiaison.createDocument(xmlDoc, threadSafe, buildWrapper);
> xalanc::XercesDOMWrapperParsedSource parsedSource (
> parserLiaison.mapToXercesDocument(xalanDocument),
> parserLiaison,
> domSupport,
> xalanc::XalanDOMString()
> );
> err = mTransformer.transform(parsedSource, mStyleSheet, out);
> if (err) {
> const char * errMsg = mTransformer.getLastError();
> if (!errMsg) {
> errMsg = "Unknown transform exception";
> }
> throw xmlapi::XMLException(EXCEPTION_HERE, errMsg);
> }
> }
>
> ...
>
> [/source]
>
>
> Kind regards,
>
> Hans
>
>
>
>>>However, you might want to look at the XSLT document function, instead
>>>of generating a result DOM and modifying it. You can use the
>>>xsl:copy-of instruction to copy an entire document
>>
>> While that sounds like an eminently good suggestion, I need to make
> this
>> change without altering the XSLT workings of this program.
>>
>>> If you want a mutable result, then yes, you have to use the Xerces-C
>> DOM.
>>
>> Ok, thanks so what I'm trying to is possible. You probably haven't
>> wanted to tell me what is probably plainly obvious to anyone more
>> familiar with these API's, but how do I alter an existing DOM document
> -
>> I've seen and used the content handler to create a new document, but
>> once its 'endDocument' method has been called - can the constructed
>> document be further modified?
>>
>> -----Original Message-----
>> From: David Bertoni [mailto:dbertoni@apache.org]
>> Sent: 13 August 2009 19:07
>> To: xalan-c-users@xml.apache.org
>> Subject: Re: Relative newbie question - How to augment XSLT generated
>> output?
>>
>> paul.bandler@nomura.com wrote:
>>> I need to be able to augment an XSLT generated document by adding the
>>> contents of another document to it as a child node. I tried
>> generating
>>> to an XalanSourceTreeDocument but when I invoked addChild an
>>> XalanDOMException was raised with code 7 (modification not allowed).
>> Do
>>> I need to generate to an Xerces DOM instead, using
>> FormatterToXercesDOM
>>> as per one of the examples, and if so what are the steps to add one
>>> document as the child of another XercesDOM - i.e. can I indeed add to
>> a
>>> fully formed document and do I need to clone the nodes from one
>> document
>>> before adding to another?
>> If you want a mutable result, then yes, you have to use the Xerces-C
>> DOM.
>>
>> However, you might want to look at the XSLT document function, instead
>> of generating a result DOM and modifying it. You can use the
>> xsl:copy-of instruction to copy an entire document anywhere you like
> in
>> the result tree. It will also be much more efficient than generating
> a
>> Xerces-C DOM document as the result, then appending another document.
>>
>> Dave
>>
>>
>>
>> This e-mail (including any attachments) is confidential, may contain
>> proprietary or privileged information and is intended for the named
>> recipient(s) only. Unintended recipients are prohibited from taking
> action
>> on the basis of information in this e-mail and must delete all copies.
>> Nomura will not accept responsibility or liability for the accuracy or
>> completeness of, or the presence of any virus or disabling code in,
> this
>> e-mail. If verification is sought please request a hard copy. Any
>> reference
>> to the terms of executed transactions should be treated as preliminary
>> only
>> and subject to formal written confirmation by Nomura. Nomura reserves
> the
>> right to monitor e-mail communications through its networks (in
> accordance
>> with applicable laws). No confidentiality or privilege is waived or
> lost
>> by
>> Nomura by any mistransmission of this e-mail. Any reference to
> "Nomura" is
>> a reference to any entity in the Nomura Holdings, Inc. group. Please
> read
>> our Electronic Communications Legal Notice which forms part of this
>> e-mail:
>> http://www.Nomura.com/email_disclaimer.htm
>>
>>
>>
>
>
>
>
>
> This e-mail (including any attachments) is confidential, may contain
> proprietary or privileged information and is intended for the named
> recipient(s) only. Unintended recipients are prohibited from taking action
> on the basis of information in this e-mail and must delete all copies.
> Nomura will not accept responsibility or liability for the accuracy or
> completeness of, or the presence of any virus or disabling code in, this
> e-mail. If verification is sought please request a hard copy. Any
> reference
> to the terms of executed transactions should be treated as preliminary
> only
> and subject to formal written confirmation by Nomura. Nomura reserves the
> right to monitor e-mail communications through its networks (in accordance
> with applicable laws). No confidentiality or privilege is waived or lost
> by
> Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
> a reference to any entity in the Nomura Holdings, Inc. group. Please read
> our Electronic Communications Legal Notice which forms part of this
> e-mail:
> http://www.Nomura.com/email_disclaimer.htm
>
>
>
Thanks for the reply but..
> The trick your looking for is outlined in transformToDocument method.
Are you referring to:-
return new DOMDocumentImpl(outDoc); ??
DOMDocumentImpl doesn't appear in the external API (packaged Doxyden),
and the class in the implementation doesn't have a public constructor
that matches the above as far as I can see...
public:
DOMDocumentImpl(MemoryManager* const manager =
XMLPlatformUtils::fgMemoryManager);
DOMDocumentImpl(const XMLCh* namespaceURI, //DOM Level 2
const XMLCh* qualifiedName,
DOMDocumentType* doctype,
MemoryManager* const manager =
XMLPlatformUtils::fgMemoryManager);
...
private:
...
//
-----------------------------------------------------------------------
// Unimplemented constructors and operators
//
-----------------------------------------------------------------------
DOMDocumentImpl(const DOMDocumentImpl &);
DOMDocumentImpl & operator = (const DOMDocumentImpl &);
What am I missing ....?
-----Original Message-----
From: Hans Smit [mailto:jcsmit@xs4all.nl]
Sent: 14 August 2009 13:23
To: xalan-c-users@xml.apache.org
Subject: RE: Relative newbie question - How to augment XSLT generated
output?
This may be what your looking for:
NOTE: this is just a fragment of a class I've developed, so if you try
to
compile "as-is" you will get errors. The trick your looking for is
outlined in transformToDocument method.
Just in case your wondering about the "xmlapi" namespace - I developed
an
API that wraps xercesc/msxml2/libxml API's into one easy to use
interface.
Toggling between vendors is just a matter of flicking a processor
switch.
Nice.
[source]
...
//--------------------------------------------------------------
xmlapi::DOMDocument::ptr transformToDocument () {
xercesc::DOMDocument * outDoc =
xercesc::DOMImplementation::getImplementation()->createDocument();
xalanc::FormatterToXercesDOM theFormatter(outDoc, 0);
transform_impl(theFormatter);
return new DOMDocumentImpl(outDoc);
}
//--------------------------------------------------------------
void transform (std::ostream & sstrm, bool
indent) {
transform_impl(sstrm);
}
private:
//--------------------------------------------------------------
template<class Output>
void transform_impl (Output & out) {
int err = 0;
xalanc::XercesParserLiaison parserLiaison;
#ifdef XERCESC_3
xalanc::XercesDOMSupport domSupport(parserLiaison);
#else
xalanc::XercesDOMSupport domSupport;
#endif
if (mInput.get() == NULL) {
throw xmlapi::XMLException(EXCEPTION_HERE, "input xml is NULL");
}
if (mStyleSheet == NULL) {
throw xmlapi::XMLException(EXCEPTION_HERE, "compiled styleheet is
NULL");
}
bool threadSafe = true;
bool buildWrapper = true;
xercesc::DOMDocument * xmlDoc =
dynamic_cast<DOMDocumentImpl*>(mInput.get())->mDoc;
xalanc::XalanDocument * xalanDocument =
parserLiaison.createDocument(xmlDoc, threadSafe, buildWrapper);
xalanc::XercesDOMWrapperParsedSource parsedSource (
parserLiaison.mapToXercesDocument(xalanDocument),
parserLiaison,
domSupport,
xalanc::XalanDOMString()
);
err = mTransformer.transform(parsedSource, mStyleSheet, out);
if (err) {
const char * errMsg = mTransformer.getLastError();
if (!errMsg) {
errMsg = "Unknown transform exception";
}
throw xmlapi::XMLException(EXCEPTION_HERE, errMsg);
}
}
...
[/source]
Kind regards,
Hans
>>However, you might want to look at the XSLT document function, instead
>>of generating a result DOM and modifying it. You can use the
>>xsl:copy-of instruction to copy an entire document
>
> While that sounds like an eminently good suggestion, I need to make
this
> change without altering the XSLT workings of this program.
>
>> If you want a mutable result, then yes, you have to use the Xerces-C
> DOM.
>
> Ok, thanks so what I'm trying to is possible. You probably haven't
> wanted to tell me what is probably plainly obvious to anyone more
> familiar with these API's, but how do I alter an existing DOM document
-
> I've seen and used the content handler to create a new document, but
> once its 'endDocument' method has been called - can the constructed
> document be further modified?
>
> -----Original Message-----
> From: David Bertoni [mailto:dbertoni@apache.org]
> Sent: 13 August 2009 19:07
> To: xalan-c-users@xml.apache.org
> Subject: Re: Relative newbie question - How to augment XSLT generated
> output?
>
> paul.bandler@nomura.com wrote:
>> I need to be able to augment an XSLT generated document by adding the
>> contents of another document to it as a child node. I tried
> generating
>> to an XalanSourceTreeDocument but when I invoked addChild an
>> XalanDOMException was raised with code 7 (modification not allowed).
> Do
>> I need to generate to an Xerces DOM instead, using
> FormatterToXercesDOM
>> as per one of the examples, and if so what are the steps to add one
>> document as the child of another XercesDOM - i.e. can I indeed add to
> a
>> fully formed document and do I need to clone the nodes from one
> document
>> before adding to another?
> If you want a mutable result, then yes, you have to use the Xerces-C
> DOM.
>
> However, you might want to look at the XSLT document function, instead
> of generating a result DOM and modifying it. You can use the
> xsl:copy-of instruction to copy an entire document anywhere you like
in
> the result tree. It will also be much more efficient than generating
a
> Xerces-C DOM document as the result, then appending another document.
>
> Dave
>
>
>
> This e-mail (including any attachments) is confidential, may contain
> proprietary or privileged information and is intended for the named
> recipient(s) only. Unintended recipients are prohibited from taking
action
> on the basis of information in this e-mail and must delete all copies.
> Nomura will not accept responsibility or liability for the accuracy or
> completeness of, or the presence of any virus or disabling code in,
this
> e-mail. If verification is sought please request a hard copy. Any
> reference
> to the terms of executed transactions should be treated as preliminary
> only
> and subject to formal written confirmation by Nomura. Nomura reserves
the
> right to monitor e-mail communications through its networks (in
accordance
> with applicable laws). No confidentiality or privilege is waived or
lost
> by
> Nomura by any mistransmission of this e-mail. Any reference to
"Nomura" is
> a reference to any entity in the Nomura Holdings, Inc. group. Please
read
> our Electronic Communications Legal Notice which forms part of this
> e-mail:
> http://www.Nomura.com/email_disclaimer.htm
>
>
>
This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm
This may be what your looking for:
NOTE: this is just a fragment of a class I've developed, so if you try to
compile "as-is" you will get errors. The trick your looking for is
outlined in transformToDocument method.
Just in case your wondering about the "xmlapi" namespace - I developed an
API that wraps xercesc/msxml2/libxml API's into one easy to use interface.
Toggling between vendors is just a matter of flicking a processor switch.
Nice.
[source]
...
//--------------------------------------------------------------
xmlapi::DOMDocument::ptr transformToDocument () {
xercesc::DOMDocument * outDoc =
xercesc::DOMImplementation::getImplementation()->createDocument();
xalanc::FormatterToXercesDOM theFormatter(outDoc, 0);
transform_impl(theFormatter);
return new DOMDocumentImpl(outDoc);
}
//--------------------------------------------------------------
void transform (std::ostream & sstrm, bool
indent) {
transform_impl(sstrm);
}
private:
//--------------------------------------------------------------
template<class Output>
void transform_impl (Output & out) {
int err = 0;
xalanc::XercesParserLiaison parserLiaison;
#ifdef XERCESC_3
xalanc::XercesDOMSupport domSupport(parserLiaison);
#else
xalanc::XercesDOMSupport domSupport;
#endif
if (mInput.get() == NULL) {
throw xmlapi::XMLException(EXCEPTION_HERE, "input xml is NULL");
}
if (mStyleSheet == NULL) {
throw xmlapi::XMLException(EXCEPTION_HERE, "compiled styleheet is
NULL");
}
bool threadSafe = true;
bool buildWrapper = true;
xercesc::DOMDocument * xmlDoc =
dynamic_cast<DOMDocumentImpl*>(mInput.get())->mDoc;
xalanc::XalanDocument * xalanDocument =
parserLiaison.createDocument(xmlDoc, threadSafe, buildWrapper);
xalanc::XercesDOMWrapperParsedSource parsedSource (
parserLiaison.mapToXercesDocument(xalanDocument),
parserLiaison,
domSupport,
xalanc::XalanDOMString()
);
err = mTransformer.transform(parsedSource, mStyleSheet, out);
if (err) {
const char * errMsg = mTransformer.getLastError();
if (!errMsg) {
errMsg = "Unknown transform exception";
}
throw xmlapi::XMLException(EXCEPTION_HERE, errMsg);
}
}
...
[/source]
Kind regards,
Hans
>>However, you might want to look at the XSLT document function, instead
>>of generating a result DOM and modifying it. You can use the
>>xsl:copy-of instruction to copy an entire document
>
> While that sounds like an eminently good suggestion, I need to make this
> change without altering the XSLT workings of this program.
>
>> If you want a mutable result, then yes, you have to use the Xerces-C
> DOM.
>
> Ok, thanks so what I'm trying to is possible. You probably haven't
> wanted to tell me what is probably plainly obvious to anyone more
> familiar with these API's, but how do I alter an existing DOM document -
> I've seen and used the content handler to create a new document, but
> once its 'endDocument' method has been called - can the constructed
> document be further modified?
>
> -----Original Message-----
> From: David Bertoni [mailto:dbertoni@apache.org]
> Sent: 13 August 2009 19:07
> To: xalan-c-users@xml.apache.org
> Subject: Re: Relative newbie question - How to augment XSLT generated
> output?
>
> paul.bandler@nomura.com wrote:
>> I need to be able to augment an XSLT generated document by adding the
>> contents of another document to it as a child node. I tried
> generating
>> to an XalanSourceTreeDocument but when I invoked addChild an
>> XalanDOMException was raised with code 7 (modification not allowed).
> Do
>> I need to generate to an Xerces DOM instead, using
> FormatterToXercesDOM
>> as per one of the examples, and if so what are the steps to add one
>> document as the child of another XercesDOM - i.e. can I indeed add to
> a
>> fully formed document and do I need to clone the nodes from one
> document
>> before adding to another?
> If you want a mutable result, then yes, you have to use the Xerces-C
> DOM.
>
> However, you might want to look at the XSLT document function, instead
> of generating a result DOM and modifying it. You can use the
> xsl:copy-of instruction to copy an entire document anywhere you like in
> the result tree. It will also be much more efficient than generating a
> Xerces-C DOM document as the result, then appending another document.
>
> Dave
>
>
>
> This e-mail (including any attachments) is confidential, may contain
> proprietary or privileged information and is intended for the named
> recipient(s) only. Unintended recipients are prohibited from taking action
> on the basis of information in this e-mail and must delete all copies.
> Nomura will not accept responsibility or liability for the accuracy or
> completeness of, or the presence of any virus or disabling code in, this
> e-mail. If verification is sought please request a hard copy. Any
> reference
> to the terms of executed transactions should be treated as preliminary
> only
> and subject to formal written confirmation by Nomura. Nomura reserves the
> right to monitor e-mail communications through its networks (in accordance
> with applicable laws). No confidentiality or privilege is waived or lost
> by
> Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
> a reference to any entity in the Nomura Holdings, Inc. group. Please read
> our Electronic Communications Legal Notice which forms part of this
> e-mail:
> http://www.Nomura.com/email_disclaimer.htm
>
>
>
>However, you might want to look at the XSLT document function, instead >of generating a result DOM and modifying it. You can use the >xsl:copy-of instruction to copy an entire document While that sounds like an eminently good suggestion, I need to make this change without altering the XSLT workings of this program. > If you want a mutable result, then yes, you have to use the Xerces-C DOM. Ok, thanks so what I'm trying to is possible. You probably haven't wanted to tell me what is probably plainly obvious to anyone more familiar with these API's, but how do I alter an existing DOM document - I've seen and used the content handler to create a new document, but once its 'endDocument' method has been called - can the constructed document be further modified? -----Original Message----- From: David Bertoni [mailto:dbertoni@apache.org] Sent: 13 August 2009 19:07 To: xalan-c-users@xml.apache.org Subject: Re: Relative newbie question - How to augment XSLT generated output? paul.bandler@nomura.com wrote: > I need to be able to augment an XSLT generated document by adding the > contents of another document to it as a child node. I tried generating > to an XalanSourceTreeDocument but when I invoked addChild an > XalanDOMException was raised with code 7 (modification not allowed). Do > I need to generate to an Xerces DOM instead, using FormatterToXercesDOM > as per one of the examples, and if so what are the steps to add one > document as the child of another XercesDOM - i.e. can I indeed add to a > fully formed document and do I need to clone the nodes from one document > before adding to another? If you want a mutable result, then yes, you have to use the Xerces-C DOM. However, you might want to look at the XSLT document function, instead of generating a result DOM and modifying it. You can use the xsl:copy-of instruction to copy an entire document anywhere you like in the result tree. It will also be much more efficient than generating a Xerces-C DOM document as the result, then appending another document. Dave This e-mail (including any attachments) is confidential, may contain proprietary or privileged information and is intended for the named recipient(s) only. Unintended recipients are prohibited from taking action on the basis of information in this e-mail and must delete all copies. Nomura will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in, this e-mail. If verification is sought please request a hard copy. Any reference to the terms of executed transactions should be treated as preliminary only and subject to formal written confirmation by Nomura. Nomura reserves the right to monitor e-mail communications through its networks (in accordance with applicable laws). No confidentiality or privilege is waived or lost by Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is a reference to any entity in the Nomura Holdings, Inc. group. Please read our Electronic Communications Legal Notice which forms part of this e-mail: http://www.Nomura.com/email_disclaimer.htm
paul.bandler@nomura.com wrote: > I need to be able to augment an XSLT generated document by adding the > contents of another document to it as a child node. I tried generating > to an XalanSourceTreeDocument but when I invoked addChild an > XalanDOMException was raised with code 7 (modification not allowed). Do > I need to generate to an Xerces DOM instead, using FormatterToXercesDOM > as per one of the examples, and if so what are the steps to add one > document as the child of another XercesDOM – i.e. can I indeed add to a > fully formed document and do I need to clone the nodes from one document > before adding to another? If you want a mutable result, then yes, you have to use the Xerces-C DOM. However, you might want to look at the XSLT document function, instead of generating a result DOM and modifying it. You can use the xsl:copy-of instruction to copy an entire document anywhere you like in the result tree. It will also be much more efficient than generating a Xerces-C DOM document as the result, then appending another document. Dave