[jira] Closed: (XERCESC-1791) missing copyright information in NOTICE file
[ https://issues.apache.org/jira/browse/XERCESC-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1791. Resolution: Fixed The test has been rewritten not to use external schemas. As for the copyright notices of files copied by autotools, I don't think we need to add them to the NOTICE. missing copyright information in NOTICE file Key: XERCESC-1791 URL: https://issues.apache.org/jira/browse/XERCESC-1791 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.0.0 Reporter: Jay Berkenbilt Fix For: 3.0.0 Thanks to the debian ftp masters for noticing thisthe apache software license requires additional copyrights to be acknowledged in the NOTICE file along with the source distribution. Xerces-c has a NOTICE file that acknowledges IBM, but searching through all the files with the distribution, I also found copyrights assigned to the following other organizations: Copyright 1998-2004 W3C (MIT, ERCIM, Keio) Copyright (C) 1999-2007 Free Software Foundation, Inc. Copyright (C) 1994 X Consortium I believe that, in order to be fully compliant with the apache software licenses, these should be acknowledged in the NOTICE file as well. In any case, they are now acknowledged in the debian copyright file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1445) 3.0 unstable -- multiply defined symbols. Solaris compilation, Sunpro CC.
[ https://issues.apache.org/jira/browse/XERCESC-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1445. Resolution: Fixed Assignee: Boris Kolpackov I think this has been resolved with the re-write of makefiles not to use convenience libraries. At least I was able to build beta 1 on Solaris with Sun CC 5.7 and 5.8. Also no beta testers complained about this issue. 3.0 unstable -- multiply defined symbols. Solaris compilation, Sunpro CC. -- Key: XERCESC-1445 URL: https://issues.apache.org/jira/browse/XERCESC-1445 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: Nightly build (please specify the date) Environment: % uname -a SunOS merlin.sce.carleton.ca 5.9 Generic_118558-04 sun4u sparc SUNW,Sun-Blade-100 % which CC /opt/SUNWspro/bin/CC % Reporter: Greg Franks Assignee: Boris Kolpackov Fix For: 3.0.0 Attachments: make.out make[2]: Entering directory `/home/greg/src/xerces-3.0/obj' /bin/sh ../libtool --tag=CXX --mode=link CC -g -D_REENTRANT-o libxerces.la -rpath /home/greg/SunOS//lib -release 3.0 \ ../src/libsrc.la ../lib/libcompat.la -lnsl -lsocket -lpthread mkdir .libs CC -G -nolib -hlibxerces-3.0.so -o .libs/libxerces-3.0.so -Qoption ld -z -Qoption ld allextract,../src/.libs/libsrc.a,../\ lib/.libs/libcompat.a -Qoption ld -z -Qoption ld defaultextract -lnsl -lsocket -lpthread ld: fatal: symbol `xercesc_3_0::ArrayJanitorunsigned short::ArrayJanitor(unsigned short*const,xercesc_3_0::MemoryManager*\ const)' is multiply-defined: (file ../src/.libs/libsrc.a(5p1Hx3-VEoc2SE8Hxf3c.o) type=FUNC; file ../src/.libs/libsrc.a(lt1-5p1Hx3-VEoc2SE8Hxf3c.\ o) type=FUNC); There are many more -- I will attach the complete output from the build. A couple of thoughts: 1) Template instantiation is not being done correctly someplace. 2) ar is being used instead of CC -xar in one place: ln .libs/libsrc.lax/libposixfmgr.a/CYlL5XBusGc3QexZRON2.o .libs/libsrc.lax/lt777-CYlL5XBusGc3QexZRON2.o || cp .libs/libsrc.\ lax/libposixfmgr.a/CYlL5XBusGc3QexZRON2.o .libs/libsrc.lax/lt777-CYlL5XBusGc3QexZRON2.o ln .libs/libsrc.lax/libposixfmgr.a/LnpLxyFd9IXk4HQ5rcj9.o .libs/libsrc.lax/lt778-LnpLxyFd9IXk4HQ5rcj9.o || cp .libs/libsrc.\ lax/libposixfmgr.a/LnpLxyFd9IXk4HQ5rcj9.o .libs/libsrc.lax/lt778-LnpLxyFd9IXk4HQ5rcj9.o ar cru .libs/libsrc.a .libs/libsrc.lax/libutil.a/Base64.o .libs/libsrc.lax/libutil.a/BinFileInputStream.o .libs/libsrc.lax/\ ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1812) 3.0.0 beta 1 fails to build on most debian platforms
[
https://issues.apache.org/jira/browse/XERCESC-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607501#action_12607501
]
Boris Kolpackov commented on XERCESC-1812:
--
I took a look at the build log and I think you either forgot to patch
src/Makefile.am or you didn't run the reconf script (I don't see the
root_res.lo object in the library linking command line which I've added).
3.0.0 beta 1 fails to build on most debian platforms
Key: XERCESC-1812
URL: https://issues.apache.org/jira/browse/XERCESC-1812
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 3.0.0
Environment: debian, experimental distribution
Reporter: Jay Berkenbilt
My latest attempt to build xerces-c 3.0.0 beta 1, after applying a patch to
fix the .o vs. .ao problem discussed earlier, resulted in a successful build
on i386, amd64, powerpc, and alpha platforms only. The other platforms on
which a build has been attempted (arm, mipsel, hppa, sparc, s390, ia64) have
all failed.
This is an excerpt from the log output on hppa. It is representative of the
failures on the other platforms.
Making all in samples
make[3]: Entering directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1/samples'
../config/pretty-make Compiling g++ -DHAVE_CONFIG_H -I. -I..
-I../src/xercesc/util -I../src -I../src -g -O2 -g -Wall -O2 -c -o
src/CreateDOMDocument/CreateDOMDocument.o
src/CreateDOMDocument/CreateDOMDocument.cpp
Compiling src/CreateDOMDocument/CreateDOMDocument.cpp
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -g -Wall -O2-o
CreateDOMDocument src/CreateDOMDocument/CreateDOMDocument.o
../src/libxerces-c.la -lnsl -L/usr/lib -licuuc -licudata -L/usr/lib -licuuc
-licudata -lpthread
mkdir .libs
g++ -g -O2 -g -Wall -O2 -o .libs/CreateDOMDocument
src/CreateDOMDocument/CreateDOMDocument.o ../src/.libs/libxerces-c.so -lnsl
-L/usr/lib -licuuc -licudata -lpthread
../src/.libs/libxerces-c.so: undefined reference to
`xercesc_messages_3_0_root_res'
collect2: ld returned 1 exit status
make[3]: *** [CreateDOMDocument] Error 1
make[3]: Leaving directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1/samples'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1'
make: *** [debian/stamp-makefile-build] Error 2
You may find links to the build logs on all the platforms from this URL:
http://experimental.debian.net/build.php?pkg=xerces-c
xerces-c is configured with the following (again, hppa as an example):
CC=cc CXX=g++ CFLAGS=-g -O2 -g -Wall -O2 CXXFLAGS=-g -O2 -g -Wall -O2
CPPFLAGS= LDFLAGS=
/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1/configure
--build=hppa-linux-gnu --prefix=/usr --includedir=\${prefix}/include
--mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
--sysconfdir=/etc --localstatedir=/var --libexecdir=\${prefix}/lib/xerces-c
--disable-maintainer-mode --disable-dependency-tracking --srcdir=.
This is essentially the default for debian. I don't pass any special
arguments. The debian xerces packages are built using the ICU transcoder,
which seems relevant here. I have verified from the configure output that
the ICU transcoder is being selected on both the successful and unsuccessful
builds.
My build is 3.0.0 beta 1 plus changes from subversion through revision 653079.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1758) Incorrect Unique Particle Attribution rule in its components '##other' and '##any' with FAST Schema definition
[ https://issues.apache.org/jira/browse/XERCESC-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1758. Resolution: Fixed Assignee: Boris Kolpackov Fix is in SVN. Incorrect Unique Particle Attribution rule in its components '##other' and '##any' with FAST Schema definition - Key: XERCESC-1758 URL: https://issues.apache.org/jira/browse/XERCESC-1758 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.8.0 Environment: Linux 2.6.9-55.ELsmp #1 SMP x86_64 GNU/Linux Red Hat Enterprise Linux AS release 4 (Nahant Update 5) Xerces-C++ Version 2.8.0 compiled with g++ 4.2.1 64 bits Reporter: Fernando Jeronymo Assignee: Boris Kolpackov Fix For: 3.0.0, 2.9.0 Attachments: fast.xsd, fastExample.xml When attempting to validate an XML file with the following schema (from http://www.fixprotocol.org/documents/3066/FAST%20Specification%201%20x%201.pdf [Appendix 2 W3C XML Schema (Non-Normative)] ) I get the following error from Xerces-C: Error at file fastapi.xml, line 2, char 201 Message: Complex type '__AnonC13' violates the Unique Particle Attribution rule in its components '##other' and '##any' However, other tools (XMLSpy, Xerces-J) validate the schema correctly. I have attached both XSD and XML files that were used to test/reproduce the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1655) Incorrect UPA violation error with xs:any and ##other
[ https://issues.apache.org/jira/browse/XERCESC-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1655. Resolution: Fixed Fix Version/s: 2.9.0 3.0.0 Assignee: Boris Kolpackov Fix is in SVN. Incorrect UPA violation error with xs:any and ##other - Key: XERCESC-1655 URL: https://issues.apache.org/jira/browse/XERCESC-1655 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0 Reporter: John Snelson Assignee: Boris Kolpackov Fix For: 3.0.0, 2.9.0 We are seeing a Unique Particle Attribution violation error occur on a schema which I am sure shouldn't have this problem. The error is: Parse error in document at line, 1, char 417. Parser message: Complex type 'dataType' violates the Unique Particle Attribution rule in its components '##other' and 'data' The schema that causes this is: ?xml version=1.0 encoding=UTF-8? xs:schema targetNamespace=info:rfa/rfaRegistry/xmlSchemas/iwsaDeposit xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns=info:rfa/rfaRegistry/xmlSchemas/iwsaDeposit xs:element name=data type=dataType/ xs:complexType name=dataType xs:sequence xs:choice xs:any namespace=##other processContents=lax/ xs:element name=data type=xs:string/ /xs:choice /xs:sequence /xs:complexType /xs:schema The instance document that causes this: ?xml version=1.0 encoding=UTF-8? da:data xmlns:da=info:rfa/rfaRegistry/xmlSchemas/iwsaDeposit xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:bl=blah xsi:schemaLocation=info:rfa/rfaRegistry/xmlSchemas/iwsaDeposit D:/Data/eclipse/workspace/GDFRPrototype/xml/xsd/iwsaDeposit-2_TEST.xsd info:rfa/rfaRegistry/xmlSchemas/adminData D:/Data/eclipse/workspace/GDFRPrototype/xml/xsd/adminData.xsd bl:otherThings/bl:other /da:data My understanding of W3C XML Schema is that the ##other should not overlap with the element declared in the schema's target namespace, and that therefore this schema does not violate the UPA rule. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-806) Schema containing xs:any namespace=##local fails validation
[ https://issues.apache.org/jira/browse/XERCESC-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-806. --- Resolution: Fixed Fix Version/s: 2.9.0 3.0.0 Assignee: Boris Kolpackov (was: Xerces-C Developers Mailing List) Fix is in SVN. Schema containing xs:any namespace=##local fails validation - Key: XERCESC-806 URL: https://issues.apache.org/jira/browse/XERCESC-806 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.2.0 Environment: Operating System: Windows XP Platform: PC Reporter: Alberto Massari Assignee: Boris Kolpackov Fix For: 3.0.0, 2.9.0 Attachments: relaxng.xsd, test_local.xml, test_local.xsd If you take the attached files and run SaxCount -n -f -s test_local.xml, you will get this error: Error at file c:\testcase\test_local.xml, line 3, char 51 Message: 'pippo' and '##any' violate the Unique Particle Attribution rule while XSV 2.2 validates it fine. Note that the schema has no ##any inside it, while it has a ##local directive; could it be that the validator is reading ##local and using ##any? Alberto P.S. The bug is against version 2.1 because there is no entry (yet) for 2.2, but the bug is present also in 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1812) 3.0.0 beta 1 fails to build on most debian platforms
[
https://issues.apache.org/jira/browse/XERCESC-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607182#action_12607182
]
Boris Kolpackov commented on XERCESC-1812:
--
I commited a change that should heopefully fix this (I couldn't test it since I
don't have access to those architectures). It is commited as revision 670516.
Can you let me know if this fixes the problem?
I am also thinking of making ICU message loader non-default even if ICU is
available since the current implementation appears very brittle.
3.0.0 beta 1 fails to build on most debian platforms
Key: XERCESC-1812
URL: https://issues.apache.org/jira/browse/XERCESC-1812
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 3.0.0
Environment: debian, experimental distribution
Reporter: Jay Berkenbilt
My latest attempt to build xerces-c 3.0.0 beta 1, after applying a patch to
fix the .o vs. .ao problem discussed earlier, resulted in a successful build
on i386, amd64, powerpc, and alpha platforms only. The other platforms on
which a build has been attempted (arm, mipsel, hppa, sparc, s390, ia64) have
all failed.
This is an excerpt from the log output on hppa. It is representative of the
failures on the other platforms.
Making all in samples
make[3]: Entering directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1/samples'
../config/pretty-make Compiling g++ -DHAVE_CONFIG_H -I. -I..
-I../src/xercesc/util -I../src -I../src -g -O2 -g -Wall -O2 -c -o
src/CreateDOMDocument/CreateDOMDocument.o
src/CreateDOMDocument/CreateDOMDocument.cpp
Compiling src/CreateDOMDocument/CreateDOMDocument.cpp
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -g -Wall -O2-o
CreateDOMDocument src/CreateDOMDocument/CreateDOMDocument.o
../src/libxerces-c.la -lnsl -L/usr/lib -licuuc -licudata -L/usr/lib -licuuc
-licudata -lpthread
mkdir .libs
g++ -g -O2 -g -Wall -O2 -o .libs/CreateDOMDocument
src/CreateDOMDocument/CreateDOMDocument.o ../src/.libs/libxerces-c.so -lnsl
-L/usr/lib -licuuc -licudata -lpthread
../src/.libs/libxerces-c.so: undefined reference to
`xercesc_messages_3_0_root_res'
collect2: ld returned 1 exit status
make[3]: *** [CreateDOMDocument] Error 1
make[3]: Leaving directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1/samples'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1'
make: *** [debian/stamp-makefile-build] Error 2
You may find links to the build logs on all the platforms from this URL:
http://experimental.debian.net/build.php?pkg=xerces-c
xerces-c is configured with the following (again, hppa as an example):
CC=cc CXX=g++ CFLAGS=-g -O2 -g -Wall -O2 CXXFLAGS=-g -O2 -g -Wall -O2
CPPFLAGS= LDFLAGS=
/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1/configure
--build=hppa-linux-gnu --prefix=/usr --includedir=\${prefix}/include
--mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
--sysconfdir=/etc --localstatedir=/var --libexecdir=\${prefix}/lib/xerces-c
--disable-maintainer-mode --disable-dependency-tracking --srcdir=.
This is essentially the default for debian. I don't pass any special
arguments. The debian xerces packages are built using the ICU transcoder,
which seems relevant here. I have verified from the configure output that
the ICU transcoder is being selected on both the successful and unsuccessful
builds.
My build is 3.0.0 beta 1 plus changes from subversion through revision 653079.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1812) 3.0.0 beta 1 fails to build on most debian platforms
[
https://issues.apache.org/jira/browse/XERCESC-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607257#action_12607257
]
Boris Kolpackov commented on XERCESC-1812:
--
There are two independant components in Xerces-C++ that could use ICU:
transcoder and message loader. The ICU transcoder provides support for a lot
more character encodings compared to the built-in transcoder. Then there is the
message loader (the one that causes trouble). It allows people to localize the
diagnostics messages that are produced by Xerces-C++. Arguably both components
are important if the goal it to support as many languages as possible. Let's
see if the fix helps before we make any decisions about turning the ICU message
loader off.
3.0.0 beta 1 fails to build on most debian platforms
Key: XERCESC-1812
URL: https://issues.apache.org/jira/browse/XERCESC-1812
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 3.0.0
Environment: debian, experimental distribution
Reporter: Jay Berkenbilt
My latest attempt to build xerces-c 3.0.0 beta 1, after applying a patch to
fix the .o vs. .ao problem discussed earlier, resulted in a successful build
on i386, amd64, powerpc, and alpha platforms only. The other platforms on
which a build has been attempted (arm, mipsel, hppa, sparc, s390, ia64) have
all failed.
This is an excerpt from the log output on hppa. It is representative of the
failures on the other platforms.
Making all in samples
make[3]: Entering directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1/samples'
../config/pretty-make Compiling g++ -DHAVE_CONFIG_H -I. -I..
-I../src/xercesc/util -I../src -I../src -g -O2 -g -Wall -O2 -c -o
src/CreateDOMDocument/CreateDOMDocument.o
src/CreateDOMDocument/CreateDOMDocument.cpp
Compiling src/CreateDOMDocument/CreateDOMDocument.cpp
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -g -Wall -O2-o
CreateDOMDocument src/CreateDOMDocument/CreateDOMDocument.o
../src/libxerces-c.la -lnsl -L/usr/lib -licuuc -licudata -L/usr/lib -licuuc
-licudata -lpthread
mkdir .libs
g++ -g -O2 -g -Wall -O2 -o .libs/CreateDOMDocument
src/CreateDOMDocument/CreateDOMDocument.o ../src/.libs/libxerces-c.so -lnsl
-L/usr/lib -licuuc -licudata -lpthread
../src/.libs/libxerces-c.so: undefined reference to
`xercesc_messages_3_0_root_res'
collect2: ld returned 1 exit status
make[3]: *** [CreateDOMDocument] Error 1
make[3]: Leaving directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1/samples'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1'
make: *** [debian/stamp-makefile-build] Error 2
You may find links to the build logs on all the platforms from this URL:
http://experimental.debian.net/build.php?pkg=xerces-c
xerces-c is configured with the following (again, hppa as an example):
CC=cc CXX=g++ CFLAGS=-g -O2 -g -Wall -O2 CXXFLAGS=-g -O2 -g -Wall -O2
CPPFLAGS= LDFLAGS=
/build/buildd/xerces-c-3.0.0~b1/build-tree/xerces-c-3.0.0.b1/configure
--build=hppa-linux-gnu --prefix=/usr --includedir=\${prefix}/include
--mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
--sysconfdir=/etc --localstatedir=/var --libexecdir=\${prefix}/lib/xerces-c
--disable-maintainer-mode --disable-dependency-tracking --srcdir=.
This is essentially the default for debian. I don't pass any special
arguments. The debian xerces packages are built using the ICU transcoder,
which seems relevant here. I have verified from the configure output that
the ICU transcoder is being selected on both the successful and unsuccessful
builds.
My build is 3.0.0 beta 1 plus changes from subversion through revision 653079.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1805) Accessing the HTTP Content-Type
[ https://issues.apache.org/jira/browse/XERCESC-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607094#action_12607094 ] Boris Kolpackov commented on XERCESC-1805: -- Hi John, Ok, I've commited a slightly-modified version of your changes (made getContentType pure virtual, moved the common implementation to NetAccessors/). If you can provide a patch that fixes the following then I will be happy to review commit it: 1. Don't use XMLString::transcode on the value of Content-Type 2. Make sure getContentType can be called after construction in Curl While at it, perahps you could also fix up Curl implementation not to use local code page like you did for Sockect and Winsock. Curl is a default net accessors (if libcurl is available) on all UNIX/Linux platforms so it would be good to fix this. Thanks, Boris Accessing the HTTP Content-Type --- Key: XERCESC-1805 URL: https://issues.apache.org/jira/browse/XERCESC-1805 Project: Xerces-C++ Issue Type: Improvement Components: Miscellaneous Affects Versions: 3.0.0 Reporter: John Snelson Fix For: 3.0.0 Attachments: xercesc_3_0_content_type_patch A lot of algorithms need access to the HTTP Content-Type header, to decide how to parse a file, or what encoding it is in - for instance see XSLT 2.0's unparsed-text() function: http://www.w3.org/TR/xslt20/#unparsed-text We should add a method, BinInputStream::getContentType(), and implement it in the HTTP input stream implementations. The method should return 0 when the content type is not available, like for file input streams. In addition, the socket and WinSock HTTP InputStream implementations have a number of problems: 1) They used fixed buffers which can result in buffer overflow. 2) They needlessly duplicate a whole load of code that could be shared. 3) They transcode to the local code page rather than ISO8859-1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1805) Accessing the HTTP Content-Type
[ https://issues.apache.org/jira/browse/XERCESC-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606726#action_12606726 ] Boris Kolpackov commented on XERCESC-1805: -- Hi Jonh, I don't know, it all feels wrong. Let's assume we specify that getContentType() returns media-type as defined in the HTTP 1.1 spec. The next issue is when can getContentType() be called? I would assume most users would want to know the content type before actually reading any data. But this does not seem to be valid for HTTP: getContentType can only be called after readBytes (before that the request hasn't been made so the content type is not known; I wonder how do you even use something like this in XQilla...). So I feel uncomfotable putting getContentType which appears to be very closely tied to the HTTP stream into the base interface. Any thoughts on this? Another issue that I noticed is that you use XMLString::transcode on the value of Content-Type which assumes that it is in local code page. But this is minor so perhaps you can submit a small patch later once I commit the major changes. Boris Accessing the HTTP Content-Type --- Key: XERCESC-1805 URL: https://issues.apache.org/jira/browse/XERCESC-1805 Project: Xerces-C++ Issue Type: Improvement Components: Miscellaneous Affects Versions: 3.0.0 Reporter: John Snelson Fix For: 3.0.0 Attachments: xercesc_3_0_content_type_patch A lot of algorithms need access to the HTTP Content-Type header, to decide how to parse a file, or what encoding it is in - for instance see XSLT 2.0's unparsed-text() function: http://www.w3.org/TR/xslt20/#unparsed-text We should add a method, BinInputStream::getContentType(), and implement it in the HTTP input stream implementations. The method should return 0 when the content type is not available, like for file input streams. In addition, the socket and WinSock HTTP InputStream implementations have a number of problems: 1) They used fixed buffers which can result in buffer overflow. 2) They needlessly duplicate a whole load of code that could be shared. 3) They transcode to the local code page rather than ISO8859-1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1805) Accessing the HTTP Content-Type
[ https://issues.apache.org/jira/browse/XERCESC-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606306#action_12606306 ] Boris Kolpackov commented on XERCESC-1805: -- Hi John, I reviewed your patch and it looks good overall. I have one suggestion, however. It is about the getContentType() function. Its documentation says that it returns a content type in some unspecified form. For HTTP it it the value of the Content-Type header. For other stream types it can be something else. As a result, I don't see how this function can be used unless the user knows what to expect from it (that is, the user knows the stream is HTTP and the getContentType() will return the Content-Type header). This made me think that perhaps placing getContentType() in the BinInputStream interface is not a best choice. Perhaps it would be better to create the BinHTTPInputStream interface which extends the BinInputStream and adds a (pure virtual) getContentType(). Then all HTTP stream implementations will derive from BinHTTPInputStream. We will also change the makeNew() function in XMLNetAccessor to return BinHTTPInputStream instead of BinInputStream. Even if the user has a BinInputStream instead of BinHTTPInputStream, he can always try to dynamic_cast to BinHTTPInputStream to see if the content type is available. In fact I think this is the only way for him to know what to expect from getContentType(). So here is how I suggest we change the current patch: Create src/xercesc/util/BinHTTPInputStream.hpp with the BinHTTPInputStream interface. This accidently conflicts with the common implementation that you have created for Winsock and Socket. We can rename those files to BinHTTPInputStreamCommon.hpp BinHTTPInputStreamCommon.cpp and move them to the NetAccessor directory (they, BTW, only need to be compiled when Socket or Winsock accessors are used so it would make sense to move them to NetAccessor). Let me know if you are ok with this and I will go ahead and apply the patch and make the changes. Boris Accessing the HTTP Content-Type --- Key: XERCESC-1805 URL: https://issues.apache.org/jira/browse/XERCESC-1805 Project: Xerces-C++ Issue Type: Improvement Components: Miscellaneous Affects Versions: 3.0.0 Reporter: John Snelson Fix For: 3.0.0 Attachments: xercesc_3_0_content_type_patch A lot of algorithms need access to the HTTP Content-Type header, to decide how to parse a file, or what encoding it is in - for instance see XSLT 2.0's unparsed-text() function: http://www.w3.org/TR/xslt20/#unparsed-text We should add a method, BinInputStream::getContentType(), and implement it in the HTTP input stream implementations. The method should return 0 when the content type is not available, like for file input streams. In addition, the socket and WinSock HTTP InputStream implementations have a number of problems: 1) They used fixed buffers which can result in buffer overflow. 2) They needlessly duplicate a whole load of code that could be shared. 3) They transcode to the local code page rather than ISO8859-1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1803) Bug fixes and improvements for RegularExpression class
[ https://issues.apache.org/jira/browse/XERCESC-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1803. -- Resolution: Fixed Thanks, the patch is in SVN. Bug fixes and improvements for RegularExpression class -- Key: XERCESC-1803 URL: https://issues.apache.org/jira/browse/XERCESC-1803 Project: Xerces-C++ Issue Type: Improvement Components: Miscellaneous Affects Versions: 3.0.0 Reporter: John Snelson Fix For: 3.0.0 Attachments: xercesc_3_0_regex_patch RegularExpression is not thread safe or consistent with it's use of MemoryManager. It's also not quite flexible enough to implement XSLT 2.0's analyze-string, and it has bugs in the replace() methods. http://www.w3.org/TR/xslt20/#analyze-string -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1586) IconvGNU doesn't work at all on x86_64 (SIGSEGV)
[ https://issues.apache.org/jira/browse/XERCESC-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1586: - Fix Version/s: (was: 3.0.0) This is probably related to https://issues.apache.org/jira/browse/XERCESC-1809 This problem appears to be fixed in the 3.0.0 codebase. IconvGNU doesn't work at all on x86_64 (SIGSEGV) Key: XERCESC-1586 URL: https://issues.apache.org/jira/browse/XERCESC-1586 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.7.0 Environment: CentOS 4.3 x86_64 Reporter: Stefan Ring Fix For: 2.9.0 When xerces-c is configured with -tIconvGNU, it just doesn't work at all on x86_64. I tried on Fedora Core 5 and CentOS 4.3, xerces-c 2.6 and 2.7. For building, I used the supplied .spec file and just replaced -tnative with -tIconvGNU. While it works fine with -tnative, the same cannot be said about the iconv configuration. [EMAIL PROTECTED] bin]$ pwd /usr/src/redhat/BUILD/xerces-c-src_2_7_0/bin [EMAIL PROTECTED] bin]$ LD_LIBRARY_PATH=../lib gdb ./SAX2Print GNU gdb Red Hat Linux (6.3.0.0-1.96rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib64/tls/libthread_db.so.1. (gdb) r /tmp/IMEX.xml Starting program: /usr/src/redhat/BUILD/xerces-c-src_2_7_0/bin/SAX2Print /tmp/IMEX.xml (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 182908767616 (LWP 17384)] (no debugging symbols found) (no debugging symbols found) ?xml version=1.0 encoding=LATIN1? Fatal Error at file , line 0, char 0 Message: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 182908767616 (LWP 17384)] 0x002a95f3179c in __gconv_transform_ucs2_internal () from /lib64/tls/libc.so.6 (gdb) bt #0 0x002a95f3179c in __gconv_transform_ucs2_internal () from /lib64/tls/libc.so.6 #1 0x002a95f2c538 in __gconv () from /lib64/tls/libc.so.6 #2 0x002a95f2bb9b in iconv () from /lib64/tls/libc.so.6 #3 0x002a9587dd20 in xercesc_2_7::IconvGNUWrapper::iconvTo () from ../lib/libxerces-c.so.27 #4 0x002a9587ed78 in xercesc_2_7::IconvGNULCPTranscoder::transcode () from ../lib/libxerces-c.so.27 #5 0x002a9592d441 in xercesc_2_7::XMLString::transcode () from ../lib/libxerces-c.so.27 #6 0x0040a23d in SAX2PrintHandlers::fatalError () #7 0x002a958b2874 in xercesc_2_7::SAX2XMLReaderImpl::error () from ../lib/libxerces-c.so.27 #8 0x002a95928a70 in xercesc_2_7::XMLScanner::emitError () from ../lib/libxerces-c.so.27 #9 0x002a9586ec0e in xercesc_2_7::IGXMLScanner::scanDocument () from ../lib/libxerces-c.so.27 #10 0x002a9592793d in xercesc_2_7::XMLScanner::scanDocument () from ../lib/libxerces-c.so.27 #11 0x002a959279bb in xercesc_2_7::XMLScanner::scanDocument () from ../lib/libxerces-c.so.27 #12 0x002a958b13b0 in xercesc_2_7::SAX2XMLReaderImpl::parse () from ../lib/libxerces-c.so.27 #13 0x00408e40 in main () It doesn't really matter what the file IMEX.xml looks like but for the sake of completenes, that's all there is: ?xml version=1.0 encoding=UTF-8? imex /imex -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1809) seg fault on 64bit
[
https://issues.apache.org/jira/browse/XERCESC-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606316#action_12606316
]
Boris Kolpackov commented on XERCESC-1809:
--
This is probably related to https://issues.apache.org/jira/browse/XERCESC-1586
and is fixed in the 3.0.0 codebase (you can try the beta:
http://marc.info/?l=xerces-c-usersm=120541881312475w=2 )
seg fault on 64bit
--
Key: XERCESC-1809
URL: https://issues.apache.org/jira/browse/XERCESC-1809
Project: Xerces-C++
Issue Type: Bug
Affects Versions: 2.8.0
Environment: Gentoo-Linux (emerge --version - Portage 2.1.4.4
(default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.21-gentoo-r4
x86_64))
Reporter: Guido Jäkel
Fix For: 2.9.0
I try to advance the Gentoo ebuild for dbxml to 2.4.13. For that, Xerces-C
2.8.0 and XQuilla is a prerequesite. The Gentoo ebuild for Xerces-C have been
tweeked to include the patches for XQilla this days. Now i'm able to build
dbxml on 32bit and 64bit. On 32bit it seems to work from the first tests, but
on 64bit even a simple dbxml -v dies with an segmentation fault.
With gdb, i got the following stack trace:
#0 0x2abcb1fe6c2c in ?? () from /lib/libc.so.6
#1 0x2abcb14f5de0 in xercesc_2_8::XMLString::parseInt () from
/usr/lib/libxerces-c.so.28
#2 0x2abcb13b3bbd in xercesc_2_8::AbstractStringValidator::assignFacet ()
from /usr/lib/libxerces-c.so.28
#3 0x2abcb13b411d in xercesc_2_8::AbstractStringValidator::init () from
/usr/lib/libxerces-c.so.28
#4 0x2abcb144cfe0 in
xercesc_2_8::ListDatatypeValidator::ListDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#5 0x2abcb141837e in
xercesc_2_8::DatatypeValidatorFactory::createDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#6 0x2abcb14198f9 in
xercesc_2_8::DatatypeValidatorFactory::expandRegistryToFullSchemaSet ()
from /usr/lib/libxerces-c.so.28
#7 0x2abcb097e733 in XQillaPlatformUtils::initialize () from
/usr/lib/libxqilla.so.4
#8 0x2abcb00d9fff in DbXml::Globals::initializeXmlPlatform () from
/usr/lib/libdbxml-2.4.so
#9 0x2abcb00da53f in DbXml::Globals::initialize () from
/usr/lib/libdbxml-2.4.so
#10 0x2abcb00df043 in DbXml::Manager::Manager () from
/usr/lib/libdbxml-2.4.so
#11 0x2abcb00d8fca in DbXml::XmlManager::XmlManager () from
/usr/lib/libdbxml-2.4.so
#12 0x0040c259 in ?? ()
#13 0x2abcb1fd0b74 in __libc_start_main () from /lib/libc.so.6
#14 0x0040ba39 in ?? ()
#15 0x7ad47148 in ?? ()
#16 0x in ?? ()
From that, i *guess* that it break's HERE, because this looks like a
libc-call to me.
.../xerces-c-src/src/xercesc/util/XMLString.cpp:
int XMLString::parseInt(const XMLCh* const toConvert
, MemoryManager* const manager)
{
// If no string, or empty string, then it is a failure
if ((!toConvert) || (!*toConvert))
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_null_ptr, manager);
XMLCh* trimmedStr = XMLString::replicate(toConvert, manager);
ArrayJanitorXMLCh jan1(trimmedStr, manager);
XMLString::trim(trimmedStr);
unsigned int trimmedStrLen = XMLString::stringLen(trimmedStr);
if ( !trimmedStrLen )
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_null_ptr, manager);
//the errno set by previous run is NOT automatically cleared
errno = 0;
char *nptr = XMLString::transcode(trimmedStr, manager);
ArrayJanitorchar jan2(nptr, manager);
char *endptr;
long retVal = strtol(nptr, endptr, 10); -[HERE]
// check if all chars are valid char
if ( (endptr - nptr) != (int) trimmedStrLen)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_Inv_chars, manager);
// check if overflow/underflow occurs
if (errno == ERANGE)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::Str_ConvertOverflow, manager);
//
// REVISIT: conversion of (long) to (int)
// may truncate value on IA64
return (int) retVal;
}
May please anybody give me a hint how to get it running on 64bit? Feel free
to ask for further information you'll need,
thank you
Guido
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1809) seg fault on 64bit
[
https://issues.apache.org/jira/browse/XERCESC-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605952#action_12605952
]
Boris Kolpackov commented on XERCESC-1809:
--
Guido,
Thanks for the info and sorry for the delay in replying. Looking at your strace
I see that Xerces-C++ tries to open XercesMessages_en_US.cat which means it was
built with iconv message loader (aka MsgCatalog). I remember seeing a couple of
bug reports about iconv not working on 64bit systems. Can you confirm that you
are using iconv (e.g., maybe post your runConfigure command line)?
Boris
seg fault on 64bit
--
Key: XERCESC-1809
URL: https://issues.apache.org/jira/browse/XERCESC-1809
Project: Xerces-C++
Issue Type: Bug
Affects Versions: 2.8.0
Environment: Gentoo-Linux (emerge --version - Portage 2.1.4.4
(default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.21-gentoo-r4
x86_64))
Reporter: Guido Jäkel
I try to advance the Gentoo ebuild for dbxml to 2.4.13. For that, Xerces-C
2.8.0 and XQuilla is a prerequesite. The Gentoo ebuild for Xerces-C have been
tweeked to include the patches for XQilla this days. Now i'm able to build
dbxml on 32bit and 64bit. On 32bit it seems to work from the first tests, but
on 64bit even a simple dbxml -v dies with an segmentation fault.
With gdb, i got the following stack trace:
#0 0x2abcb1fe6c2c in ?? () from /lib/libc.so.6
#1 0x2abcb14f5de0 in xercesc_2_8::XMLString::parseInt () from
/usr/lib/libxerces-c.so.28
#2 0x2abcb13b3bbd in xercesc_2_8::AbstractStringValidator::assignFacet ()
from /usr/lib/libxerces-c.so.28
#3 0x2abcb13b411d in xercesc_2_8::AbstractStringValidator::init () from
/usr/lib/libxerces-c.so.28
#4 0x2abcb144cfe0 in
xercesc_2_8::ListDatatypeValidator::ListDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#5 0x2abcb141837e in
xercesc_2_8::DatatypeValidatorFactory::createDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#6 0x2abcb14198f9 in
xercesc_2_8::DatatypeValidatorFactory::expandRegistryToFullSchemaSet ()
from /usr/lib/libxerces-c.so.28
#7 0x2abcb097e733 in XQillaPlatformUtils::initialize () from
/usr/lib/libxqilla.so.4
#8 0x2abcb00d9fff in DbXml::Globals::initializeXmlPlatform () from
/usr/lib/libdbxml-2.4.so
#9 0x2abcb00da53f in DbXml::Globals::initialize () from
/usr/lib/libdbxml-2.4.so
#10 0x2abcb00df043 in DbXml::Manager::Manager () from
/usr/lib/libdbxml-2.4.so
#11 0x2abcb00d8fca in DbXml::XmlManager::XmlManager () from
/usr/lib/libdbxml-2.4.so
#12 0x0040c259 in ?? ()
#13 0x2abcb1fd0b74 in __libc_start_main () from /lib/libc.so.6
#14 0x0040ba39 in ?? ()
#15 0x7ad47148 in ?? ()
#16 0x in ?? ()
From that, i *guess* that it break's HERE, because this looks like a
libc-call to me.
.../xerces-c-src/src/xercesc/util/XMLString.cpp:
int XMLString::parseInt(const XMLCh* const toConvert
, MemoryManager* const manager)
{
// If no string, or empty string, then it is a failure
if ((!toConvert) || (!*toConvert))
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_null_ptr, manager);
XMLCh* trimmedStr = XMLString::replicate(toConvert, manager);
ArrayJanitorXMLCh jan1(trimmedStr, manager);
XMLString::trim(trimmedStr);
unsigned int trimmedStrLen = XMLString::stringLen(trimmedStr);
if ( !trimmedStrLen )
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_null_ptr, manager);
//the errno set by previous run is NOT automatically cleared
errno = 0;
char *nptr = XMLString::transcode(trimmedStr, manager);
ArrayJanitorchar jan2(nptr, manager);
char *endptr;
long retVal = strtol(nptr, endptr, 10); -[HERE]
// check if all chars are valid char
if ( (endptr - nptr) != (int) trimmedStrLen)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_Inv_chars, manager);
// check if overflow/underflow occurs
if (errno == ERANGE)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::Str_ConvertOverflow, manager);
//
// REVISIT: conversion of (long) to (int)
// may truncate value on IA64
return (int) retVal;
}
May please anybody give me a hint how to get it running on 64bit? Feel free
to ask for further information you'll need,
thank you
Guido
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1808) Segfault when validating malformed XML instance ...
[ https://issues.apache.org/jira/browse/XERCESC-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605959#action_12605959 ] Boris Kolpackov commented on XERCESC-1808: -- Confirmed. The problem is also present in the 3.0.0 codebase and leads to SchemaValidator. Segfault when validating malformed XML instance ... --- Key: XERCESC-1808 URL: https://issues.apache.org/jira/browse/XERCESC-1808 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.8.0 Environment: Linux/Ubuntu Reporter: Jacques Legare Attachments: SAX2Count.cpp, simple.xml, simple.xsd If the following two lines // Causes crash when a malformed XML document is validated: parser-setExitOnFirstFatalError (false); are inserted in SAX2Count.cpp at line 332, a segfault occurs when the program is fed an instance which is not well-formed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1810) nilable status is ignored in subsequent declarations of the same element in a type
nilable status is ignored in subsequent declarations of the same element in a type -- Key: XERCESC-1810 URL: https://issues.apache.org/jira/browse/XERCESC-1810 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.8.0 Reporter: Boris Kolpackov Copy from the mailing list report. Schema fragment: xs:element name=people nillable=true minOccurs=0 maxOccurs=unbounded xs:complexType xs:sequence xs:choice xs:sequence minOccurs=0 xs:element name=ID type=xs:string/ xs:element name=Name type=xs:string/ xs:element name=Description type=xs:string minOccurs=0/ xs:element name=isAvailable type=xs:boolean/ /xs:sequence xs:sequence minOccurs=0 xs:element name=Name type=xs:string minOccurs=0/ xs:element name=Description type=xs:string nillable=true minOccurs=0/ /xs:sequence /xs:choice /xs:sequence /xs:complexType /xs:element XML fragment: people Namefd/Name Description xsi:nil=true/ /people The validation failes, the reason is Message: xsi:nil must not be specified for the element Description with nillable equals false -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1022) XMLPlatformUtils::isAnySlash() causing dynamic loading errors
[ https://issues.apache.org/jira/browse/XERCESC-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605970#action_12605970 ] Boris Kolpackov commented on XERCESC-1022: -- If this is such a serious problem I am surprised nobody else is complaining about it. Or is it only a problem for older g++ versions (2.96)? XMLPlatformUtils::isAnySlash() causing dynamic loading errors - Key: XERCESC-1022 URL: https://issues.apache.org/jira/browse/XERCESC-1022 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.3.0 Environment: Operating System: Linux Platform: All Reporter: Jason E. Stewart Assignee: Xerces-C Developers Mailing List Attachments: suse-error.txt, xerces-c-2.8.0-isAnySlash.patch Hey, I've had a large number bug reports in Xerces-P for the 2.3.0 release related to linking errors with isAnySlash(). For OS X the problems was eliminated by removing the 'inline' directive from the .cpp file and recompiling. For Redhat Linux this did not help, and Xerces-P was forced to remove the method from the API to enable linking. I'm at a loss to figure out why this one method should create problems on two such different platforms. The linux user was using an old version of gcc (2.96), so perhaps this is an issue? From: Steve Mathias [EMAIL PROTECTED] Subject: Re: Similar make test error To: [EMAIL PROTECTED] Date: Sat, 11 Oct 2003 09:35:18 -0600 Can't load '/usr/local/src/perl/XML-Xerces-2.3.0-1/blib/arch/auto/XML/Xerces/Xerces.so' for module XML::Xerces: /usr/local/src/perl/XML-Xerces-2.3.0-1/blib/arch/auto/XML/Xerces/Xerces.so: undefined symbol: isAnySlash__Q211xercesc_2_316XMLPlatformUtilsUs at /usr/local/lib/perl5/5.6.1/i686-linux/DynaLoader.pm line 206. at /usr/local/src/perl/XML-Xerces-2.3.0-1/blib/lib/XML/Xerces.pm line 7 I'm using xerces-c version 2_3_0 which I built myself with gcc version 2.96 (I've tried a couple of the samples and they run fine) and xerces-p version 2.3.0-1. Jason I don't have gcc-2.96 to test this on, but I don't think the gcc Jason version is the issue here. Jason I'm assuming that you've tried to run DOMCount or some other Jason Xerces-C application just to ensure the libxerces.so is working Jason fine? Yes, all the xerces-c sample programs run fine. Jason If so then please grep the library symbols using the commands I Jason sent to Kai, and lets see what's happenging there. Here's what I get: # nm -C /usr/local/xerces-c-src_2_3_0/lib/libxerces-c.so | grep -i isanyslash # nm -C # /usr/local/src/perl/XML-Xerces-2.3.0-1/blib/arch/auto/XML/Xerces/Xerces.so # | grep -i isanyslash 0005de34 T _wrap_XMLPlatformUtils_isAnySlash U xercesc_2_3::XMLPlatformUtils::isAnySlash(unsigned short) So, I guess the error message is correct in reporting that the symbol is undefined. I'm in a little over my head with all this compiler/linking stuff though. How can I fix this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1022) XMLPlatformUtils::isAnySlash() causing dynamic loading errors
[ https://issues.apache.org/jira/browse/XERCESC-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605970#action_12605970 ] Boris Kolpackov commented on XERCESC-1022: -- If this is such a serious problem I am surprised nobody else is complaining about it. Or is it only a problem for older g++ versions (2.96)? XMLPlatformUtils::isAnySlash() causing dynamic loading errors - Key: XERCESC-1022 URL: https://issues.apache.org/jira/browse/XERCESC-1022 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.3.0 Environment: Operating System: Linux Platform: All Reporter: Jason E. Stewart Assignee: Xerces-C Developers Mailing List Attachments: suse-error.txt, xerces-c-2.8.0-isAnySlash.patch Hey, I've had a large number bug reports in Xerces-P for the 2.3.0 release related to linking errors with isAnySlash(). For OS X the problems was eliminated by removing the 'inline' directive from the .cpp file and recompiling. For Redhat Linux this did not help, and Xerces-P was forced to remove the method from the API to enable linking. I'm at a loss to figure out why this one method should create problems on two such different platforms. The linux user was using an old version of gcc (2.96), so perhaps this is an issue? From: Steve Mathias [EMAIL PROTECTED] Subject: Re: Similar make test error To: [EMAIL PROTECTED] Date: Sat, 11 Oct 2003 09:35:18 -0600 Can't load '/usr/local/src/perl/XML-Xerces-2.3.0-1/blib/arch/auto/XML/Xerces/Xerces.so' for module XML::Xerces: /usr/local/src/perl/XML-Xerces-2.3.0-1/blib/arch/auto/XML/Xerces/Xerces.so: undefined symbol: isAnySlash__Q211xercesc_2_316XMLPlatformUtilsUs at /usr/local/lib/perl5/5.6.1/i686-linux/DynaLoader.pm line 206. at /usr/local/src/perl/XML-Xerces-2.3.0-1/blib/lib/XML/Xerces.pm line 7 I'm using xerces-c version 2_3_0 which I built myself with gcc version 2.96 (I've tried a couple of the samples and they run fine) and xerces-p version 2.3.0-1. Jason I don't have gcc-2.96 to test this on, but I don't think the gcc Jason version is the issue here. Jason I'm assuming that you've tried to run DOMCount or some other Jason Xerces-C application just to ensure the libxerces.so is working Jason fine? Yes, all the xerces-c sample programs run fine. Jason If so then please grep the library symbols using the commands I Jason sent to Kai, and lets see what's happenging there. Here's what I get: # nm -C /usr/local/xerces-c-src_2_3_0/lib/libxerces-c.so | grep -i isanyslash # nm -C # /usr/local/src/perl/XML-Xerces-2.3.0-1/blib/arch/auto/XML/Xerces/Xerces.so # | grep -i isanyslash 0005de34 T _wrap_XMLPlatformUtils_isAnySlash U xercesc_2_3::XMLPlatformUtils::isAnySlash(unsigned short) So, I guess the error message is correct in reporting that the symbol is undefined. I'm in a little over my head with all this compiler/linking stuff though. How can I fix this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1809) seg fault on 64bit
[
https://issues.apache.org/jira/browse/XERCESC-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604327#action_12604327
]
Boris Kolpackov commented on XERCESC-1809:
--
Guido, can you try to run some of the Xerces-C++ examples or better yet the
test suite that comes with Xerces-C++ (see scripts/sanityTest.pl)? Right now
you are testing Xerces-C++/XQilla/DBXML combo and it is not clear which part is
causing the problem. Since Xerces-C++ 2.8.0 is know to work on 64-bit Linux, I
suspect there is something specific to this combination in which case you
better ask for help on XQilla and/or DBXML mailing lists.
seg fault on 64bit
--
Key: XERCESC-1809
URL: https://issues.apache.org/jira/browse/XERCESC-1809
Project: Xerces-C++
Issue Type: Bug
Affects Versions: 2.8.0
Environment: Gentoo-Linux (emerge --version - Portage 2.1.4.4
(default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.21-gentoo-r4
x86_64))
Reporter: Guido Jäkel
I try to advance the Gentoo ebuild for dbxml to 2.4.13. For that, Xerces-C
2.8.0 and XQuilla is a prerequesite. The Gentoo ebuild for Xerces-C have been
tweeked to include the patches for XQilla this days. Now i'm able to build
dbxml on 32bit and 64bit. On 32bit it seems to work from the first tests, but
on 64bit even a simple dbxml -v dies with an segmentation fault.
With gdb, i got the following stack trace:
#0 0x2abcb1fe6c2c in ?? () from /lib/libc.so.6
#1 0x2abcb14f5de0 in xercesc_2_8::XMLString::parseInt () from
/usr/lib/libxerces-c.so.28
#2 0x2abcb13b3bbd in xercesc_2_8::AbstractStringValidator::assignFacet ()
from /usr/lib/libxerces-c.so.28
#3 0x2abcb13b411d in xercesc_2_8::AbstractStringValidator::init () from
/usr/lib/libxerces-c.so.28
#4 0x2abcb144cfe0 in
xercesc_2_8::ListDatatypeValidator::ListDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#5 0x2abcb141837e in
xercesc_2_8::DatatypeValidatorFactory::createDatatypeValidator () from
/usr/lib/libxerces-c.so.28
#6 0x2abcb14198f9 in
xercesc_2_8::DatatypeValidatorFactory::expandRegistryToFullSchemaSet ()
from /usr/lib/libxerces-c.so.28
#7 0x2abcb097e733 in XQillaPlatformUtils::initialize () from
/usr/lib/libxqilla.so.4
#8 0x2abcb00d9fff in DbXml::Globals::initializeXmlPlatform () from
/usr/lib/libdbxml-2.4.so
#9 0x2abcb00da53f in DbXml::Globals::initialize () from
/usr/lib/libdbxml-2.4.so
#10 0x2abcb00df043 in DbXml::Manager::Manager () from
/usr/lib/libdbxml-2.4.so
#11 0x2abcb00d8fca in DbXml::XmlManager::XmlManager () from
/usr/lib/libdbxml-2.4.so
#12 0x0040c259 in ?? ()
#13 0x2abcb1fd0b74 in __libc_start_main () from /lib/libc.so.6
#14 0x0040ba39 in ?? ()
#15 0x7ad47148 in ?? ()
#16 0x in ?? ()
From that, i *guess* that it break's HERE, because this looks like a
libc-call to me.
.../xerces-c-src/src/xercesc/util/XMLString.cpp:
int XMLString::parseInt(const XMLCh* const toConvert
, MemoryManager* const manager)
{
// If no string, or empty string, then it is a failure
if ((!toConvert) || (!*toConvert))
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_null_ptr, manager);
XMLCh* trimmedStr = XMLString::replicate(toConvert, manager);
ArrayJanitorXMLCh jan1(trimmedStr, manager);
XMLString::trim(trimmedStr);
unsigned int trimmedStrLen = XMLString::stringLen(trimmedStr);
if ( !trimmedStrLen )
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_null_ptr, manager);
//the errno set by previous run is NOT automatically cleared
errno = 0;
char *nptr = XMLString::transcode(trimmedStr, manager);
ArrayJanitorchar jan2(nptr, manager);
char *endptr;
long retVal = strtol(nptr, endptr, 10); -[HERE]
// check if all chars are valid char
if ( (endptr - nptr) != (int) trimmedStrLen)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::XMLNUM_Inv_chars, manager);
// check if overflow/underflow occurs
if (errno == ERANGE)
ThrowXMLwithMemMgr(NumberFormatException,
XMLExcepts::Str_ConvertOverflow, manager);
//
// REVISIT: conversion of (long) to (int)
// may truncate value on IA64
return (int) retVal;
}
May please anybody give me a hint how to get it running on 64bit? Feel free
to ask for further information you'll need,
thank you
Guido
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1652) DOMDocumentTypeImpl is not thread safe
[ https://issues.apache.org/jira/browse/XERCESC-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1652: - Fix Version/s: 2.9.0 3.0.0 Thanks for the info, Jesse. I am scheduling this bug for 3.0.0 and 2.9.0. We definitely want to figure out what's going on here before 3.0.0 is out. DOMDocumentTypeImpl is not thread safe -- Key: XERCESC-1652 URL: https://issues.apache.org/jira/browse/XERCESC-1652 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 2.7.0, 2.8.0 Environment: Multithreaded programs Reporter: Jesse Pelton Fix For: 3.0.0, 2.9.0 Attachments: DOMDocumentTypeImpl.diff DOMDocumentTypeImpl.cpp uses a static gDocTypeDocument() method to return a singleton doctype document that provides various utility services (allocating named node maps, cloning strings, and so on). Any calls to methods of this static document that can modify its instance data, including calls that allocate memory, must be synchronized to keep the document's state consistent. Patch against the trunk to follow, but note that it should be reviewed carefully. First, I pretty much blindly copied the synchronization code from DOMImplementationRegistry.cpp and may have gotten something wrong. Second, the patch is adapted from changes I made to v2.7.0 code and has not been tested (or even compiled) (Updates to the trunk prevent successful application of a patch against v2.7.0 to code from the trunk.) And lastly, it's possible that the trunk updates obsolete my patch, though it still seems relevant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1652) DOMDocumentTypeImpl is not thread safe
[ https://issues.apache.org/jira/browse/XERCESC-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603693#action_12603693 ] Boris Kolpackov commented on XERCESC-1652: -- Jesse, do you know if this problem is also in the trunk (aka 3.0.0 codebase)? DOMDocumentTypeImpl is not thread safe -- Key: XERCESC-1652 URL: https://issues.apache.org/jira/browse/XERCESC-1652 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 2.7.0, 2.8.0 Environment: Multithreaded programs Reporter: Jesse Pelton Attachments: DOMDocumentTypeImpl.diff DOMDocumentTypeImpl.cpp uses a static gDocTypeDocument() method to return a singleton doctype document that provides various utility services (allocating named node maps, cloning strings, and so on). Any calls to methods of this static document that can modify its instance data, including calls that allocate memory, must be synchronized to keep the document's state consistent. Patch against the trunk to follow, but note that it should be reviewed carefully. First, I pretty much blindly copied the synchronization code from DOMImplementationRegistry.cpp and may have gotten something wrong. Second, the patch is adapted from changes I made to v2.7.0 code and has not been tested (or even compiled) (Updates to the trunk prevent successful application of a patch against v2.7.0 to code from the trunk.) And lastly, it's possible that the trunk updates obsolete my patch, though it still seems relevant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1051) Crash when maxOccurs = 200000
[
https://issues.apache.org/jira/browse/XERCESC-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1051:
-
Fix Version/s: 3.0.0
Tentatively changing the fix for version to 3.0.0. Alberto has a solution
which for now does not work for all cases. He will try to get it into shape and
I will try to help. If this fails then we will probably need to implement the
treat large maxOccurs as unbounded hack for the time being.
Crash when maxOccurs = 20
--
Key: XERCESC-1051
URL: https://issues.apache.org/jira/browse/XERCESC-1051
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 2.3.0
Environment: Operating System: Windows NT/2K
Platform: PC
Reporter: Frank Rast
Assignee: Alberto Massari
Fix For: 3.0.0
Parser crashes in ContentSpecNode.hpp: ContentSpecNode::~ContentSpecNode().
Steps to reproduce:
validate a xml file against a schema with an element having a maxOccurs =
20.
Assumed cause:
Stack overfow
Makeshift resolution:
Set the repeat count to unbounded(-1), when maxOccurs 500:
inline void ContentSpecNode::setMaxOccurs(int max)
{
if(max 500)
max = -1;
fMaxOccurs = max;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1801) anyURI should accept backslashes
[ https://issues.apache.org/jira/browse/XERCESC-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1801: - Attachment: test.xml test.xsd Attaching the test. anyURI should accept backslashes Key: XERCESC-1801 URL: https://issues.apache.org/jira/browse/XERCESC-1801 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.8.0 Reporter: Boris Kolpackov Attachments: test.xml, test.xsd Michael Glavassevich worte on c-dev: Backslashes aren't allowed in URIs, however the XML schema type xs:anyURI [1] allows much more than the URI RFC. Specifically it's lexical space is defined as finite-length character sequences which, when the algorithm defined in Section 5.4 of [XML Linking Language] is applied to them, result in strings which are legal URIs according to [RFC 2396], as amended by [RFC 2732]. Backslashes are not interpreted as path separators but they are allowed in xs:anyURI values. Xerces-J accepts file:///c:\testing\bla.jpg as a valid xs:anyURI value. If Xerces-C rejects it then it has a bug. [1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#anyURI -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1801) anyURI should accept backslashes
anyURI should accept backslashes Key: XERCESC-1801 URL: https://issues.apache.org/jira/browse/XERCESC-1801 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.8.0 Reporter: Boris Kolpackov Attachments: test.xml, test.xsd Michael Glavassevich worte on c-dev: Backslashes aren't allowed in URIs, however the XML schema type xs:anyURI [1] allows much more than the URI RFC. Specifically it's lexical space is defined as finite-length character sequences which, when the algorithm defined in Section 5.4 of [XML Linking Language] is applied to them, result in strings which are legal URIs according to [RFC 2396], as amended by [RFC 2732]. Backslashes are not interpreted as path separators but they are allowed in xs:anyURI values. Xerces-J accepts file:///c:\testing\bla.jpg as a valid xs:anyURI value. If Xerces-C rejects it then it has a bug. [1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#anyURI -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1621) ##targetNamespace results in a bogus UPA violation error
[ https://issues.apache.org/jira/browse/XERCESC-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1621: - Fix Version/s: 2.9.0 3.0.0 ##targetNamespace results in a bogus UPA violation error Key: XERCESC-1621 URL: https://issues.apache.org/jira/browse/XERCESC-1621 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0 Environment: all Reporter: Boris Kolpackov Fix For: 3.0.0, 2.9.0 Attachments: bug.xsd The following schema fragment: complexType name=AnyTargetNamespace sequence maxOccurs=unbounded element name=apple type=string/ any namespace=##targetNamespace processContents=skip minOccurs=1 maxOccurs=unbounded/ /sequence /complexType causes Xerces-C++ to fail with the following (bogus) error: :0:0: error: Complex type 'AnyTargetNamespace' violates the Unique Particle Attribution rule in its components 'apple' and '##any' There is no UPA violation in the above fragment. Xerces-J, Jing and MSV agree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1758) Incorrect Unique Particle Attribution rule in its components '##other' and '##any' with FAST Schema definition
[ https://issues.apache.org/jira/browse/XERCESC-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1758: - Affects Version/s: (was: 2.9.0) (was: 3.0.0) 2.8.0 Fix Version/s: 2.9.0 3.0.0 Incorrect Unique Particle Attribution rule in its components '##other' and '##any' with FAST Schema definition - Key: XERCESC-1758 URL: https://issues.apache.org/jira/browse/XERCESC-1758 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.8.0 Environment: Linux 2.6.9-55.ELsmp #1 SMP x86_64 GNU/Linux Red Hat Enterprise Linux AS release 4 (Nahant Update 5) Xerces-C++ Version 2.8.0 compiled with g++ 4.2.1 64 bits Reporter: Fernando Jeronymo Fix For: 3.0.0, 2.9.0 Attachments: fast.xsd, fastExample.xml When attempting to validate an XML file with the following schema (from http://www.fixprotocol.org/documents/3066/FAST%20Specification%201%20x%201.pdf [Appendix 2 W3C XML Schema (Non-Normative)] ) I get the following error from Xerces-C: Error at file fastapi.xml, line 2, char 201 Message: Complex type '__AnonC13' violates the Unique Particle Attribution rule in its components '##other' and '##any' However, other tools (XMLSpy, Xerces-J) validate the schema correctly. I have attached both XSD and XML files that were used to test/reproduce the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1800) DOM API is not 64-bit safe
[ https://issues.apache.org/jira/browse/XERCESC-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594791#action_12594791 ] Boris Kolpackov commented on XERCESC-1800: -- Alberto already made a round of changes so if, for example, you look at XMLString in the 3.0.0 codebase, you will see that all string sizes and indexes are passed as XMLSize_t. The same is in DOMCharacterData. It is just there are still some areas where we use int/long, for example as offsets in XMLString (should be changed to XMLSSize_t) and in DOMNodeList. It doesn't make sense to fix only some of the places. The problem with using 32-bit integers where 64-bit should be use is that it makes it very hard to write 64-bit safe application that use Xerces-C++. Every time you need to pass std::size_t from your code to Xerces-C++, you have to cast or will get a warning. Plus we never know how much RAM boxes in a couple of years will have and what users will want to do with that RAM. DOM API is not 64-bit safe -- Key: XERCESC-1800 URL: https://issues.apache.org/jira/browse/XERCESC-1800 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 3.0.0 Reporter: Boris Kolpackov Priority: Blocker Fix For: 3.0.0 There are a number of places in DOM where unsigned int and unsigned long are used for indexes and sizes. These should be changed to XMLSize_t. Here is the grep result: DOMDocument.hpp: const unsigned long lineNum, DOMDocument.hpp: const unsigned long columnNum) = 0; DOMDocumentTraversal.hpp: unsigned longwhatToShow, DOMDocumentTraversal.hpp: unsigned long whatToShow, DOMLocator.hpp:virtual unsigned long getLineNumber() const = 0; DOMLocator.hpp:virtual unsigned long getColumnNumber() const = 0; DOMLSParserFilter.hpp:virtual unsigned long getWhatToShow() const = 0; DOMLSSerializerFilter.hpp:virtual unsigned long getWhatToShow() const =0; DOMLSSerializerFilter.hpp:// unsigned long fWhatToShow; DOMNodeIterator.hpp:virtual unsigned long getWhatToShow() = 0; DOMTreeWalker.hpp:virtual unsigned long getWhatToShow()= 0; DOMTypeInfo.hpp:virtual bool isDerivedFrom(const XMLCh* typeNamespaceArg, const XMLCh* typeNameArg, unsigned long derivationMethod) const = 0; DOMXPathResult.hpp: virtual unsigned long getSnapshotLength() const = 0; DOMXPathResult.hpp: * @param index of type unsigned long - Index into the snapshot collection. DOMXPathResult.hpp: virtual const DOMNode* snapshotItem(unsigned long index) const = 0; DOMImplementationList.hpp:virtual DOMImplementation *item(unsigned int index) const = 0; DOMImplementationList.hpp:virtual unsigned int getLength() const = 0; DOMLSParser.hpp:virtual const XMLCh* getURIText(unsigned int uriId) const = 0; DOMNamedNodeMap.hpp:virtual DOMNode *item(unsigned int index) const = 0; DOMNamedNodeMap.hpp:virtual unsigned int getLength() const = 0; DOMNodeList.hpp:virtual DOMNode *item(unsigned int index) const = 0; DOMNodeList.hpp:virtual unsigned int getLength() const = 0; DOMStringList.hpp:virtual const XMLCh *item(unsigned int index) const = 0; DOMStringList.hpp:virtual unsigned int getLength() const = 0; Ideally, we should do such an audit of the entire codebase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1780) OSX 10.5 (Leopard): Xerces uses CoreFoundation library calls and crashes...
[ https://issues.apache.org/jira/browse/XERCESC-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594602#action_12594602 ] Boris Kolpackov commented on XERCESC-1780: -- Additional information provided by Ozgur Sahoglu [EMAIL PROTECTED] on c-users: I came across the same problem when running 2.8 on Leopard. The native transcoder is causing this error. Even if you use ICU though, there is still a problem with MacOS Posix implementation. In /src/xercesc/util/Platforms/MacOS/MacPosixFile.cpp at line #114, the open function calls TranscodeUniCharsToUTF8 in MacOSPlatformUtils and this helper function uses CoreServices. Even though this doesn't cause any crashes, it dumps bunch of The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTION ALITY___YOU_MUST_EXEC__() to debug. messages on the screen. To suppress these messages, I've used XML::transcode instead. In 3.0, MacOS uses pure Posix implementation. You can either merge the PlatformUtils implementation from 3.0 to 2.8 or simply replace TranscodeUniCharsToUTF8 call with XML::transcode in MacPosixFile.cpp. If you're interested i can send my changes, but it's a pretty easy fix. OSX 10.5 (Leopard): Xerces uses CoreFoundation library calls and crashes... --- Key: XERCESC-1780 URL: https://issues.apache.org/jira/browse/XERCESC-1780 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 2.8.0 Environment: MacOS X 10.5 Server (Leopard), i386 or x86_64 architecture. Apache 2.2.6, Prefork, non-threaded, 64bit (default OSX 10.5 httpd server) Reporter: Valery Tschopp Fix For: 3.0.0 The Shibboleth apache2 module (see http://shibboleth.internet2.edu) uses the Xerces-C library to process XML messages. When the module is loaded by apache2, the shared Xercecs-C library is loaded too and initialized. At initialization, first some error messages appear, then the whole httpd process crashes. Error messages in /var/log/apache2/error_log (a lot of them): The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug. Stack trace in crash report: Application Specific Information: *** single-threaded process forked *** Thread 0 Crashed: 0 com.apple.CoreFoundation 0x961479c1 __CFRunLoopFindMode + 353 1 com.apple.CoreFoundation 0x961496ec CFRunLoopAddSource + 124 2 com.apple.DiskArbitration 0x9308ada4 DAApprovalSessionScheduleWithRunLoop + 61 3 ...ple.CoreServices.CarbonCore0x9621b846 _FSGetDiskArbSession(__DASession**, __DAApprovalSession**) + 646 4 ...ple.CoreServices.CarbonCore0x9621b58e CreateDiskArbDiskForMountPath(char const*) + 94 5 ...ple.CoreServices.CarbonCore0x9621a3d2 FSCacheableClient_GetVolumeCachedInfo(char const*, statfs const*, CachedVolumeInfo*, __DADisk*, __DADisk**) + 364 6 ...ple.CoreServices.CarbonCore0x96219d11 MountVolume(char const*, statfs*, unsigned char, unsigned char, __DADisk*, short*) + 537 7 ...ple.CoreServices.CarbonCore0x96219a0a MountInitialVolumes() + 258 8 ...ple.CoreServices.CarbonCore0x96219609 INIT_FileManager() + 219 9 ...ple.CoreServices.CarbonCore0x962194b6 GetRetainedVolFSVCBByVolumeID(unsigned long) + 36 10 ...ple.CoreServices.CarbonCore0x96217c96 PathGetObjectInfo(char const*, unsigned long, unsigned long, VolumeInfo**, unsigned long*, unsigned long*, char*, unsigned long*, unsigned char*) + 202 11 ...ple.CoreServices.CarbonCore0x96217b66 FSPathMakeRefInternal(unsigned char const*, unsigned long, unsigned long, FSRef*, unsigned char*) + 90 12 ...ple.CoreServices.CarbonCore0x962236bb FSPathMakeRef + 47 13 ...ple.CoreServices.CarbonCore0x96236e2b FilterRelevantFilesFromDirectory + 347 14 ...ple.CoreServices.CarbonCore0x96236679 CacheFMMapData + 1565 15 ...ple.CoreServices.CarbonCore0x96235395 IntlFCOpenComponentData + 206 16 ...ple.CoreServices.CarbonCore0x96237be9 InitScriptBundleComponent + 85 17 ...ple.CoreServices.CarbonCore0x96237b8d SMInitIntlSpec + 17 18 ...ple.CoreServices.CarbonCore0x962377a2 LMGetIntlSpec + 76 19 ...ple.CoreServices.CarbonCore0x96238b2c GetScriptManagerVariable + 28 20 ...ple.CoreServices.CarbonCore0x962410cd LocaleRefOrNULLToTagEntryPtr + 74 21 ...ple.CoreServices.CarbonCore0x96240f2e LocaleRefGetPartString + 57 22 ...ple.CoreServices.CarbonCore0x962401c5 SetDefaultLocaleString + 195 23 ...ple.CoreServices.CarbonCore
[jira] Updated: (XERCESC-1780) OSX 10.5 (Leopard): Xerces uses CoreFoundation library calls and crashes...
[ https://issues.apache.org/jira/browse/XERCESC-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1780: - Fix Version/s: (was: 3.0.0) 2.9.0 The problem appears to be fixed in 3.0.0. Changing target version to 2.9.0. OSX 10.5 (Leopard): Xerces uses CoreFoundation library calls and crashes... --- Key: XERCESC-1780 URL: https://issues.apache.org/jira/browse/XERCESC-1780 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 2.8.0 Environment: MacOS X 10.5 Server (Leopard), i386 or x86_64 architecture. Apache 2.2.6, Prefork, non-threaded, 64bit (default OSX 10.5 httpd server) Reporter: Valery Tschopp Fix For: 2.9.0 The Shibboleth apache2 module (see http://shibboleth.internet2.edu) uses the Xerces-C library to process XML messages. When the module is loaded by apache2, the shared Xercecs-C library is loaded too and initialized. At initialization, first some error messages appear, then the whole httpd process crashes. Error messages in /var/log/apache2/error_log (a lot of them): The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug. Stack trace in crash report: Application Specific Information: *** single-threaded process forked *** Thread 0 Crashed: 0 com.apple.CoreFoundation 0x961479c1 __CFRunLoopFindMode + 353 1 com.apple.CoreFoundation 0x961496ec CFRunLoopAddSource + 124 2 com.apple.DiskArbitration 0x9308ada4 DAApprovalSessionScheduleWithRunLoop + 61 3 ...ple.CoreServices.CarbonCore0x9621b846 _FSGetDiskArbSession(__DASession**, __DAApprovalSession**) + 646 4 ...ple.CoreServices.CarbonCore0x9621b58e CreateDiskArbDiskForMountPath(char const*) + 94 5 ...ple.CoreServices.CarbonCore0x9621a3d2 FSCacheableClient_GetVolumeCachedInfo(char const*, statfs const*, CachedVolumeInfo*, __DADisk*, __DADisk**) + 364 6 ...ple.CoreServices.CarbonCore0x96219d11 MountVolume(char const*, statfs*, unsigned char, unsigned char, __DADisk*, short*) + 537 7 ...ple.CoreServices.CarbonCore0x96219a0a MountInitialVolumes() + 258 8 ...ple.CoreServices.CarbonCore0x96219609 INIT_FileManager() + 219 9 ...ple.CoreServices.CarbonCore0x962194b6 GetRetainedVolFSVCBByVolumeID(unsigned long) + 36 10 ...ple.CoreServices.CarbonCore0x96217c96 PathGetObjectInfo(char const*, unsigned long, unsigned long, VolumeInfo**, unsigned long*, unsigned long*, char*, unsigned long*, unsigned char*) + 202 11 ...ple.CoreServices.CarbonCore0x96217b66 FSPathMakeRefInternal(unsigned char const*, unsigned long, unsigned long, FSRef*, unsigned char*) + 90 12 ...ple.CoreServices.CarbonCore0x962236bb FSPathMakeRef + 47 13 ...ple.CoreServices.CarbonCore0x96236e2b FilterRelevantFilesFromDirectory + 347 14 ...ple.CoreServices.CarbonCore0x96236679 CacheFMMapData + 1565 15 ...ple.CoreServices.CarbonCore0x96235395 IntlFCOpenComponentData + 206 16 ...ple.CoreServices.CarbonCore0x96237be9 InitScriptBundleComponent + 85 17 ...ple.CoreServices.CarbonCore0x96237b8d SMInitIntlSpec + 17 18 ...ple.CoreServices.CarbonCore0x962377a2 LMGetIntlSpec + 76 19 ...ple.CoreServices.CarbonCore0x96238b2c GetScriptManagerVariable + 28 20 ...ple.CoreServices.CarbonCore0x962410cd LocaleRefOrNULLToTagEntryPtr + 74 21 ...ple.CoreServices.CarbonCore0x96240f2e LocaleRefGetPartString + 57 22 ...ple.CoreServices.CarbonCore0x962401c5 SetDefaultLocaleString + 195 23 ...ple.CoreServices.CarbonCore0x962400e0 _ReloadUnicodeUtilData + 92 24 ...ple.CoreServices.CarbonCore0x9623ff16 UCRefreshThreadGlobals + 183 25 ...ple.CoreServices.CarbonCore0x9626fe3f UCCreateCollator + 133 26 libxerces-c.28.dylib 0x0059b1cf xercesc_2_8::MacOSUnicodeConverter::MacOSUnicodeConverter() + 79 27 libxerces-c.28.dylib 0x00598d7a xercesc_2_8::XMLPlatformUtils::makeTransService() + 64 28 libxerces-c.28.dylib 0x005ab68d xercesc_2_8::XMLPlatformUtils::Initialize(char const*, char const*, xercesc_2_8::PanicHandler*, xercesc_2_8::MemoryManager*, bool) + 347 29 libsaml.5.dylib 0x0020b733 saml::SAMLInternalConfig::init() + 259 30 libshib-target.dylib 0x00079be1 shibtarget::STConfig::init(char const*) + 351 31 mod_shib_22.so0x00e17d4f shib_child_init + 137 (mod_apache.cpp:1105) 32 httpd 0x206a ap_run_child_init + 68 ... It look like that Apple changes something with OSX
[jira] Created: (XERCESC-1800) DOM API is not 64-bit safe
DOM API is not 64-bit safe -- Key: XERCESC-1800 URL: https://issues.apache.org/jira/browse/XERCESC-1800 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 3.0.0 Reporter: Boris Kolpackov Priority: Blocker Fix For: 3.0.0 There are a number of places in DOM where unsigned int and unsigned long are used for indexes and sizes. These should be changed to XMLSize_t. Here is the grep result: DOMDocument.hpp: const unsigned long lineNum, DOMDocument.hpp: const unsigned long columnNum) = 0; DOMDocumentTraversal.hpp: unsigned longwhatToShow, DOMDocumentTraversal.hpp: unsigned long whatToShow, DOMLocator.hpp:virtual unsigned long getLineNumber() const = 0; DOMLocator.hpp:virtual unsigned long getColumnNumber() const = 0; DOMLSParserFilter.hpp:virtual unsigned long getWhatToShow() const = 0; DOMLSSerializerFilter.hpp:virtual unsigned long getWhatToShow() const =0; DOMLSSerializerFilter.hpp:// unsigned long fWhatToShow; DOMNodeIterator.hpp:virtual unsigned long getWhatToShow() = 0; DOMTreeWalker.hpp:virtual unsigned long getWhatToShow()= 0; DOMTypeInfo.hpp:virtual bool isDerivedFrom(const XMLCh* typeNamespaceArg, const XMLCh* typeNameArg, unsigned long derivationMethod) const = 0; DOMXPathResult.hpp: virtual unsigned long getSnapshotLength() const = 0; DOMXPathResult.hpp: * @param index of type unsigned long - Index into the snapshot collection. DOMXPathResult.hpp: virtual const DOMNode* snapshotItem(unsigned long index) const = 0; DOMImplementationList.hpp:virtual DOMImplementation *item(unsigned int index) const = 0; DOMImplementationList.hpp:virtual unsigned int getLength() const = 0; DOMLSParser.hpp:virtual const XMLCh* getURIText(unsigned int uriId) const = 0; DOMNamedNodeMap.hpp:virtual DOMNode *item(unsigned int index) const = 0; DOMNamedNodeMap.hpp:virtual unsigned int getLength() const = 0; DOMNodeList.hpp:virtual DOMNode *item(unsigned int index) const = 0; DOMNodeList.hpp:virtual unsigned int getLength() const = 0; DOMStringList.hpp:virtual const XMLCh *item(unsigned int index) const = 0; DOMStringList.hpp:virtual unsigned int getLength() const = 0; Ideally, we should do such an audit of the entire codebase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1799) packageBinaries.pl produces broken distribution on cygwin
[ https://issues.apache.org/jira/browse/XERCESC-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593244#action_12593244 ] Boris Kolpackov commented on XERCESC-1799: -- I did not use packageBinaries for 2.8.0 release -- everything was packaged manually. I also have no plans using this script for 3.0.0. Ideally in the 3.0.0 code base we should use make dist however it does not package everything at the moment and I may use manual packaging again. packageBinaries.pl produces broken distribution on cygwin - Key: XERCESC-1799 URL: https://issues.apache.org/jira/browse/XERCESC-1799 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.8.0 Environment: cygwin 1.5.25-12 Reporter: Charles Wilson I believe a number of directories have been left out of the list in populateInclude(). The Makefile.in's in these directories contain non-empty PUBHEADERS definitions. Is this an oversight in packageBinaries.pl, or is that script intended only for use on the platforms that the *xerces* team distributes prebuilt binaries for (thus, omitting Cygwin, IRIX, etc? (I rather doubt that, since the xerces team does not provide pre-built BeOS packages, yet BeOS is not missing from the populateInclude() list.) util/MsgLoaders/MsgFile util/NetAccessors/MacOSURLAccess util/NetAccessors/MacOSURLAccessCF util/NetAccessors/Socket util/NetAccessors/WinSock util/NetAccessors/libWWW util/Platforms/Cygwin util/Platforms/FreeBSD util/Platforms/IRIX util/Platforms/Interix util/Platforms/NetBSD util/Platforms/OS400 util/Platforms/OpenServer util/Platforms/QNX util/Platforms/Tru64 util/Platforms/UnixWare util/Transcoders/Cygwin util/Transcoders/Iconv390 util/Transcoders/Iconv400 util/Transcoders/IconvFBSD util/Transcoders/IconvGNU util/Transcoders/MacOSUnicodeConverter util/Transcoders/Uniconv390 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1798) Orphan/adopt grammar support in XMLGrammarPoolImpl is broken
Orphan/adopt grammar support in XMLGrammarPoolImpl is broken Key: XERCESC-1798 URL: https://issues.apache.org/jira/browse/XERCESC-1798 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.8.0, 3.0.0 Reporter: Boris Kolpackov The attached test case demonstrates a bug in the orphanGrammar()/cacheGrammar() implementation. In a nutshell, the problem is in the current architecture that uses XMLStringPool to store namespace URIs (and in some cases names). This string pool resides in the XMLGrammarPoolImpl instance and is shared by all individual grammars this grammar pool contains. When the grammar is orphaned, it does not contain any references to the pool which used to host it but it still contains string IDs that refer to the strings inside the string pool. Once such a grammar is imported with cacheGrammar() into a new grammar pool, there is no way for the importing grammar pool to populate its string pool with necessary strings. Properly fixing this bug is not going to be easy. A fairly simple but ugly workaround is to manually synchronize string pools in the two grammar pools before importing the grammars (the workaround is commented out in the test case). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1798) Orphan/adopt grammar support in XMLGrammarPoolImpl is broken
[ https://issues.apache.org/jira/browse/XERCESC-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1798: - Attachment: test.xsd test.xml test.cpp The test case. Orphan/adopt grammar support in XMLGrammarPoolImpl is broken Key: XERCESC-1798 URL: https://issues.apache.org/jira/browse/XERCESC-1798 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.8.0, 3.0.0 Reporter: Boris Kolpackov Attachments: test.cpp, test.xml, test.xsd The attached test case demonstrates a bug in the orphanGrammar()/cacheGrammar() implementation. In a nutshell, the problem is in the current architecture that uses XMLStringPool to store namespace URIs (and in some cases names). This string pool resides in the XMLGrammarPoolImpl instance and is shared by all individual grammars this grammar pool contains. When the grammar is orphaned, it does not contain any references to the pool which used to host it but it still contains string IDs that refer to the strings inside the string pool. Once such a grammar is imported with cacheGrammar() into a new grammar pool, there is no way for the importing grammar pool to populate its string pool with necessary strings. Properly fixing this bug is not going to be easy. A fairly simple but ugly workaround is to manually synchronize string pools in the two grammar pools before importing the grammars (the workaround is commented out in the test case). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1797) The xsi:type attribute should be an allowed field in an identity constraint
[ https://issues.apache.org/jira/browse/XERCESC-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1797. The xsi:type attribute should be an allowed field in an identity constraint --- Key: XERCESC-1797 URL: https://issues.apache.org/jira/browse/XERCESC-1797 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0 Environment: Fedora 4 Linux (Embedded System) Reporter: Katrina Griffith Would someone please clarify why the following unique constraint does not work? It is an allowed construct in the W3C schema specification, so this may be a bug in the Parser. sample constraint: xs:element name=ListNode type=ListType minOccurs=0 xs:unique name=Constraint1 xs:selector xpath=./Item/ xs:field xpath=@address/ xs:field xpath=@xsi:type/ /xs:unique /xs:element In the sample xml that follows, I am expecting validation errors because more than one Item node of the same xsi:type share the same address value. I get no constraint error from the parser. sample xml: RootNode xsi:noNamespaceSchemaLocation=TestSchema.xsd xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; ListNode Item xsi:type=SpecificItemType1 address=1 file=file1.xml name=Item1/ Item xsi:type=SpecificItemType1 address=1 file=file2.xml name=Item2/ Item xsi:type=SpecificItemType2 address=1 file=file3.xml name=Item3/ /ListNode /RootNode Here is the full schema representation. sample xsd: xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:cs=TestSchema.xsd elementFormDefault=qualified attributeFormDefault=unqualified xs:simpleType name=AddressType1 xs:restriction base=xs:int xs:minInclusive value=1/ xs:maxInclusive value=254/ /xs:restriction /xs:simpleType xs:simpleType name=AddressType2 xs:restriction base=xs:int xs:minInclusive value=0/ xs:maxInclusive value=655519/ /xs:restriction /xs:simpleType xs:complexType name=AListType xs:sequence xs:element name=Item type=AbstractItemType minOccurs=0 maxOccurs=32/ /xs:sequence /xs:complexType xs:complexType name=AbstractItemType abstract=true xs:attribute name=name type=xs:string use=required/ xs:attribute name=file type=xs:string use=required/ /xs:complexType xs:complexType name=SpecificItemType1 xs:complexContent xs:extension base=AbstractItemType xs:attribute name=address type=AddressType1 use=required/ /xs:extension /xs:complexContent /xs:complexType xs:complexType name=SpecificItemType2 xs:complexContent xs:extension base=AbstractItemType xs:attribute name=address type=AddressType2 use=required/ /xs:extension /xs:complexContent /xs:complexType xs:element name=RootNode xs:complexType xs:sequence xs:element name=ListNode type=AListType minOccurs=0 xs:unique name=Constraint1 xs:selector xpath=./Item/ xs:field xpath=@address/ xs:field xpath=@xsi:type/ /xs:unique /xs:element /xs:sequence /xs:complexType /xs:element /xs:schema -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1797) The xsi:type attribute should be an allowed field in an identity constraint
[ https://issues.apache.org/jira/browse/XERCESC-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1797. -- Resolution: Invalid You need to add xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; to your schema. With this fix and 2.8.0 I get: Error at file /tmp/test.xml, line 4, column 95 Message: Duplicate unique value declared for identity constraint of element 'ListNode'. The xsi:type attribute should be an allowed field in an identity constraint --- Key: XERCESC-1797 URL: https://issues.apache.org/jira/browse/XERCESC-1797 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0 Environment: Fedora 4 Linux (Embedded System) Reporter: Katrina Griffith Would someone please clarify why the following unique constraint does not work? It is an allowed construct in the W3C schema specification, so this may be a bug in the Parser. sample constraint: xs:element name=ListNode type=ListType minOccurs=0 xs:unique name=Constraint1 xs:selector xpath=./Item/ xs:field xpath=@address/ xs:field xpath=@xsi:type/ /xs:unique /xs:element In the sample xml that follows, I am expecting validation errors because more than one Item node of the same xsi:type share the same address value. I get no constraint error from the parser. sample xml: RootNode xsi:noNamespaceSchemaLocation=TestSchema.xsd xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; ListNode Item xsi:type=SpecificItemType1 address=1 file=file1.xml name=Item1/ Item xsi:type=SpecificItemType1 address=1 file=file2.xml name=Item2/ Item xsi:type=SpecificItemType2 address=1 file=file3.xml name=Item3/ /ListNode /RootNode Here is the full schema representation. sample xsd: xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:cs=TestSchema.xsd elementFormDefault=qualified attributeFormDefault=unqualified xs:simpleType name=AddressType1 xs:restriction base=xs:int xs:minInclusive value=1/ xs:maxInclusive value=254/ /xs:restriction /xs:simpleType xs:simpleType name=AddressType2 xs:restriction base=xs:int xs:minInclusive value=0/ xs:maxInclusive value=655519/ /xs:restriction /xs:simpleType xs:complexType name=AListType xs:sequence xs:element name=Item type=AbstractItemType minOccurs=0 maxOccurs=32/ /xs:sequence /xs:complexType xs:complexType name=AbstractItemType abstract=true xs:attribute name=name type=xs:string use=required/ xs:attribute name=file type=xs:string use=required/ /xs:complexType xs:complexType name=SpecificItemType1 xs:complexContent xs:extension base=AbstractItemType xs:attribute name=address type=AddressType1 use=required/ /xs:extension /xs:complexContent /xs:complexType xs:complexType name=SpecificItemType2 xs:complexContent xs:extension base=AbstractItemType xs:attribute name=address type=AddressType2 use=required/ /xs:extension /xs:complexContent /xs:complexType xs:element name=RootNode xs:complexType xs:sequence xs:element name=ListNode type=AListType minOccurs=0 xs:unique name=Constraint1 xs:selector xpath=./Item/ xs:field xpath=@address/ xs:field xpath=@xsi:type/ /xs:unique /xs:element /xs:sequence /xs:complexType /xs:element /xs:schema -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1792) xerces (-c + -j) does not validate a valid xml file against schema
[ https://issues.apache.org/jira/browse/XERCESC-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1792: - Fix Version/s: 2.9.0 3.0.0 I've done some initial investigations (BTW, the sample XML document is part of the schema package from the link above). The original version of FlexRay_Cluster_Example.xml is broken in that it does not specify the proper schema via schemaLocation. Howevere, after changing the schema location to read: xsi:schemaLocation=http://www.asam.net/xml/fbx/flexray fibex4flexray.xsd I don't see why Xerces-C++ keeps reporting the errors. So I tend to think this is a bug. xerces (-c + -j) does not validate a valid xml file against schema --- Key: XERCESC-1792 URL: https://issues.apache.org/jira/browse/XERCESC-1792 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: Nightly build (please specify the date), 2.8.0 Environment: Windows XP 32 bit, MinGW (gcc 3.4.5), MS Visual Studio 2005, xerces-c 2.8.0 and svn-trunk of 2. April, xerces-j 2.9.1 Reporter: Dominik Holler Fix For: 3.0.0, 2.9.0 I want to validate a xml file against a schema, the example file and the schema files are part of the stabdard (FBX) FIBEX - Field Bus Exchange Format [1]. MSXML and xsv does validate the file successful, and I does not see a error in the file, too. The root element of the file FlexRay_Cluster_Example.xml has the attribute xsi:schemaLocation=http://www.asam.net/xml/fbx/all fibex4multiplatform.xsd . The validation with xerces-c via SAX2Count.exe -v=always -p -f results to Error at file F:\xxx\fibex/FlexRay_Cluster_Example.xml, line 120, char 52 Message: Unknown element 'fx:PDU-TRIGGERING' Error at file F:\xxx\fibex/FlexRay_Cluster_Example.xml, line 120, char 52 Message: Attribute 'ID' is not declared for element 'fx:PDU-TRIGGERING' Error at file F:\xxx\fibex/FlexRay_Cluster_Example.xml, line 124, char 52 Message: Unknown element 'fx:PDU-TRIGGERING' Error at file F:\xxx\fibex/FlexRay_Cluster_Example.xml, line 124, char 52 Message: Attribute 'ID' is not declared for element 'fx:PDU-TRIGGERING' Error at file F:\xxx\fibex/FlexRay_Cluster_Example.xml, line 154, char 52 Message: Unknown element 'fx:PDU-TRIGGERING' ... The validation with xerces-j via sax.Counter -n -np -v -s -f -hs -va results to [Error] FlexRay_Cluster_Example.xml:33:55: cvc-elt.1: Cannot find the declaration of element 'fx:FIBEX'. [Error] FlexRay_Cluster_Example.xml:40:76: cvc-elt.4.2: Cannot resolve 'flexray:CLUSTER-TYPE' to a type definition for element 'fx:CLUSTER'. ... Because fibex4multiplatform.xsd imorts fibex4flexray.xsd and fibex.xsd, the schemaLocation of the root element of the xml file is changed to xsi:schemaLocation=http://www.asam.net/xml/fbx/flexray fibex4flexray.xsd http://www.asam.net/xml/fbx fibex.xsd sax.Counter of xerces-j validates the xml now successful: FlexRay_Cluster_Example.xml: 1060 ms (961 elems, 369 attrs, 0 spaces, 19497 chars) and xerces-c is producing the same errors. [1] http://www.asam.net/03_standards_06.php -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1791) missing copyright information in NOTICE file
[ https://issues.apache.org/jira/browse/XERCESC-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1791: - Fix Version/s: 3.0.0 Jay, thanks for reporting this! Copyright 1998-2004 W3C (MIT, ERCIM, Keio) This one comes from the schemas in the regression test for XERCESC-1512. Instead of polluting NOTICE I think we should come up with a minimal test case which does not reuse any third-party schemas. Copyright (C) 1999-2007 Free Software Foundation, Inc. Copyright (C) 1994 X Consortium I am not sure about these two. The files that have these copyrights are copied into the distribution by the autotools bootstrap process. There are no files with such copyrights in the repository. I wonder what the policy is on this case. missing copyright information in NOTICE file Key: XERCESC-1791 URL: https://issues.apache.org/jira/browse/XERCESC-1791 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.0.0 Reporter: Jay Berkenbilt Fix For: 3.0.0 Thanks to the debian ftp masters for noticing thisthe apache software license requires additional copyrights to be acknowledged in the NOTICE file along with the source distribution. Xerces-c has a NOTICE file that acknowledges IBM, but searching through all the files with the distribution, I also found copyrights assigned to the following other organizations: Copyright 1998-2004 W3C (MIT, ERCIM, Keio) Copyright (C) 1999-2007 Free Software Foundation, Inc. Copyright (C) 1994 X Consortium I believe that, in order to be fully compliant with the apache software licenses, these should be acknowledged in the NOTICE file as well. In any case, they are now acknowledged in the debian copyright file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1789) trailing whitespace on error messages
[ https://issues.apache.org/jira/browse/XERCESC-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1789: - Fix Version/s: 3.0.0 trailing whitespace on error messages - Key: XERCESC-1789 URL: https://issues.apache.org/jira/browse/XERCESC-1789 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.0.0 Environment: debian Reporter: Jay Berkenbilt Fix For: 3.0.0 Attachments: a.err, a.xml In testing the beta of xerces-c 3.0.0 using the automated test suite for some code I have that uses it, I noticed that errors returned by xerces::SAXParseException::getMessage() have trailing whitespace that they did not previously have. All of my error condition tests failed because of the trailing whitespace on the messages. This is trivial to reproduce. Just run samples/SAXPrint on an xml file with an error, such as this one: a This results in the following output: ?xml version=1.0 encoding=LATIN1? a Fatal Error at file /tmp/a.xml, line 2, char 1 Message: The input ended before all started tags were ended. Last tag started was 'a' but there is an extraneous blank after the end of the message. I will attach the input file (a.xml) and the output file (a.err) so you can see this. I left the priority as Major of this, but if it were my project, I'd set it as Blocker -- this will have a massive impact on anyone who has automated tests that may include these error messages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1730) scoped memory management
[ https://issues.apache.org/jira/browse/XERCESC-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1730. -- Resolution: Fixed Assignee: Boris Kolpackov James, I believe in Xerces-C++ exceptions are sometimes used for ordinary codnitions. I noticed that during XML parsing ReaderMgr uses exceptions to inidicate the end of token conditions or some such. For more information, grep for EndOfEntityException in the scanner source code. Needless to say this is not the way to do it. Luckily this exception does not use memory manager so this patch won't affect its performance. Tobias, I've commited a modified version of your patch (I've made getExceptionMemoryManager pure virtual in the MemoryManager interface, as well as added similar to XMLException code to DOMException). Please verify that it still satisfies your requirements. scoped memory management Key: XERCESC-1730 URL: https://issues.apache.org/jira/browse/XERCESC-1730 Project: Xerces-C++ Issue Type: Improvement Reporter: Tobias Schuette Assignee: Boris Kolpackov Priority: Minor Fix For: 3.0.0 Attachments: MemoryManager.diff, XMLException.diff passing scoped memory managers to certain helper functions (xercesc/util/...) only works in non-exceptional or catch-all circumstances. If those functions (e.g. XMLString::parseInt) throw an exception the scoped memory manager is passed via ThrowXMLwithMemMgrXXX to the exception during construction. The exception allocates memory for its internal buffers (message/source file) from that memory manager. If the exception is not caught before the scoped memory manager goes out-of-scope, dereferencing/deallocating the memory during reporting/destruction yields undefined behaviour. the attached diffs against trunk are a proposal to change the MemoryManager interface of Xerces-C's pluggable memory management and the exception base class XMLException in such a way that implementors of the MemoryManager interface are able to handle memory requests coming from exceptions separately as discussed on the mailing-list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1663) IconvGNU and IconvFBSD based transcoders assume UCS-2 as XMLCh encoding
[
https://issues.apache.org/jira/browse/XERCESC-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1663:
-
Priority: Blocker (was: Major)
Fix Version/s: 2.9.0
3.0.0
Seeing that GNU Iconv, when available, is preferred over Iconv, we should try
to fix this for 3.0.0.
IconvGNU and IconvFBSD based transcoders assume UCS-2 as XMLCh encoding
---
Key: XERCESC-1663
URL: https://issues.apache.org/jira/browse/XERCESC-1663
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 2.7.0
Environment: any
Reporter: Boris Kolpackov
Priority: Blocker
Fix For: 3.0.0, 2.9.0
I was studying the code in IconvGNU and IconvFBSD transcoders and it appears
that they assume UCS-2 is the encoding for XMLCh when it's actually UTF-16. I
believe this can result in the loss of data.
The encoding that is used for XMLCh is stored in the fUnicodeCP variable
which is initialized in the Iconv{GNU,FBSD}TransServices c-tor. The
initialization code just tries all encodings from the
gIconv{GNU,FBSD}Encodings array which for GNU contains only UCS-2 and for
FreeBSD contains UCS-2 and UCS-4 encodings.
I tried to add a UTF-16LE to this array (as a first item) and it works fine
for GNU (I double checked that UTF-16LE ends up in fUnicodeCP). Does anybody
knows what's going on here? Should we add UTF-16 to these arrays?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1769) xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and various other problems
[ https://issues.apache.org/jira/browse/XERCESC-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574398#action_12574398 ] Boris Kolpackov commented on XERCESC-1769: -- The xerces-c-2.8.0-icu_ressource_fix.patch was applied to the trunk and xerces-2. My understanding is that this patch only fixed d) with a)-c) still open. xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and various other problems - Key: XERCESC-1769 URL: https://issues.apache.org/jira/browse/XERCESC-1769 Project: Xerces-C++ Issue Type: Bug Affects Versions: 2.8.0 Environment: Gentoo Linux 2007.0 AMD64, ICU 3.6 and 3.8 Reporter: Tiziano Müller Fix For: 3.0.0, 2.9.0 Attachments: xerces-c-2.8.0-icu_ressource_fix.patch a) the .res-file can't be used as a fallback if the memory-blob can't be loaded, but it should be the .dat-file (as far as I understood it) b) loading the messages using a full file-path is deprecated (according to http://www.icu-project.org/apiref/icu4c/ures_8h.html#c4d72fc9f7cc63a05f646cabee4be167) and it really doesn't work c) When using make install to install the library, the library libXercesMessages.so.28.0 doesn't get installed which leads to a unresolved symbol error when linking against libxerces-c.so.28.0 d) When trying to run a test or a sample linked against xerces-c++ built with ICU message loader support, xerces-c++ panics with the error Cannot load message domain, whether or not libXercesMessages and the .res/.dat-file in /usr/msg are available or not. The patch I'm going to attach fixes this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1783) Finish makefiles for the ICU message loader
[ https://issues.apache.org/jira/browse/XERCESC-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1783. -- Resolution: Fixed Assignee: Boris Kolpackov The fix is in the trunk. Finish makefiles for the ICU message loader --- Key: XERCESC-1783 URL: https://issues.apache.org/jira/browse/XERCESC-1783 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.0.0 Environment: autotools-based Reporter: Boris Kolpackov Assignee: Boris Kolpackov Priority: Blocker Fix For: 3.0.0 Makefile in util/MsgLoaders/ICU/resources needs completeion. In particular, the install target is missing. We should also probably disable the automatic selection of this MsgLoader in configure since it doesn't add much except an extra library. Also see this bug report: https://issues.apache.org/jira/browse/XERCESC-1769 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1735) Fast append optimization for the DOM parser
[ https://issues.apache.org/jira/browse/XERCESC-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1735: - Fix Version/s: 3.0.0 Fast append optimization for the DOM parser --- Key: XERCESC-1735 URL: https://issues.apache.org/jira/browse/XERCESC-1735 Project: Xerces-C++ Issue Type: Improvement Components: DOM Affects Versions: 3.0.0 Environment: any Reporter: Boris Kolpackov Fix For: 3.0.0 Attachments: fast-append.patch The attached patch adds the appendChildFast function to the DOMParentNode internal interface which skips a number of actions and checks compared to the vanilla appendChild function that are unnecessary in the controlled environment of building a new DOM document. The patch also changes AbstractDOMParser to call appendChildFast instead of appendChild. This change results in 25-30% parsing speed improvement depending on the workload used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1783) Finish makefiles for the ICU message loader
[ https://issues.apache.org/jira/browse/XERCESC-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1783: - Priority: Blocker (was: Major) Finish makefiles for the ICU message loader --- Key: XERCESC-1783 URL: https://issues.apache.org/jira/browse/XERCESC-1783 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.0.0 Environment: autotools-based Reporter: Boris Kolpackov Priority: Blocker Fix For: 3.0.0 Makefile in util/MsgLoaders/ICU/resources needs completeion. In particular, the install target is missing. We should also probably disable the automatic selection of this MsgLoader in configure since it doesn't add much except an extra library. Also see this bug report: https://issues.apache.org/jira/browse/XERCESC-1769 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1745) Inheritance by restriction does not detect a missing type from an imported schema
[ https://issues.apache.org/jira/browse/XERCESC-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1745: - Priority: Major (was: Blocker) Inheritance by restriction does not detect a missing type from an imported schema - Key: XERCESC-1745 URL: https://issues.apache.org/jira/browse/XERCESC-1745 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0 Environment: any Reporter: Boris Kolpackov Fix For: 3.0.0, 2.9.0 Attachments: a.xsd, b.xml, b.xsd If you run the attached XML (with two schemas) throught DOMCount with validation enabled, you will get no errors even thought the B type in b.xsd inherits from a:A which does not exist. See comments in b.xsd for various interesting ways to change the schema in order to get different behavior. This problem is present in both 2.7.0 and 2.8.0 and probably in the trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1784) Website support for Xerces-C++ 2 and 3-series
[ https://issues.apache.org/jira/browse/XERCESC-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1784: - Priority: Blocker (was: Major) Website support for Xerces-C++ 2 and 3-series - Key: XERCESC-1784 URL: https://issues.apache.org/jira/browse/XERCESC-1784 Project: Xerces-C++ Issue Type: Task Components: Documentation Reporter: Boris Kolpackov Assignee: Boris Kolpackov Priority: Blocker Fix For: 3.0.0 I think it will be a good idea to have online documentation (build instructions, API references, etc.) for both 2 (2.8.0) and 3 (3.0.0)-series. The reason for this is that 3.0.0 introduces a number of backwards-incompatible changes and I expect a sizable chunk of the user base to stick with the 2-series for some time. My idea on how to do this is to have two sets of menu links in the left menu bar. One for 2.8.0 and one for 3.0.0 (some links, e.g., Charter, Release Info, Feedback, etc.) are common for both releases and won't be in the release-specific sections. In other words, the menu will look like this: * Readme * Charter * Release Info * Download -- 2.8.0: * Installation * Build Instructions * Programming Guide * Samples * FAQs * API Reference * DOM C++ Binding * Migration Guide - 3.0.0: * Installation * Build Instructions * Programming Guide * Samples * FAQs * API Reference * DOM C++ Binding * Migration Guide - * Feedback * Bug Reporting * Mailing Lists * Source Repository * Applications For this to work we will need to divorce the website source from the library source itself (which I believe is a good idea on its own) and put it into a separate SVN project. The complete website copy will then be built by using the release-independent part plus the release-specific parts from the latest releases of 2 and 3-series. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1785) Build and test on all supported platforms
Build and test on all supported platforms - Key: XERCESC-1785 URL: https://issues.apache.org/jira/browse/XERCESC-1785 Project: Xerces-C++ Issue Type: Task Components: Build Reporter: Boris Kolpackov Priority: Blocker Fix For: 3.0.0 We need to make sure that building, testing and installation work on all platforms that we have committed to support. See the following Wiki page for the status: http://wiki.apache.org/xerces/XercescBuildStatus -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1675) 64-bit failure under gcc on Solaris 2.10
[ https://issues.apache.org/jira/browse/XERCESC-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1675. 64-bit failure under gcc on Solaris 2.10 Key: XERCESC-1675 URL: https://issues.apache.org/jira/browse/XERCESC-1675 Project: Xerces-C++ Issue Type: Bug Environment: Main Memory is8192 Megabytes Manufacturer is Sun (Sun Microsystems) System Model is Sun-Fire-V490 ROM Version isOBP 4.15.6 2005/01/06 04:24 Number of CPUs is 4 App Architecture is sparc Kernel Version is sun4u OS Name isSunOS OS Version is 5.10 OS Distribution isSolaris 10 1/06 s10s_u1wos_19a SPARC Kernel Version is SunOS iptsd022.mcilink.com 5.10 Generic_118833-20 sun4u sparc SUNW,Sun-Fire-V490 cc version: cc: Sun C 5.8 Patch 121015-02 2006/03/29 CC version: CC: Sun C++ 5.8 Patch 121017-02 2006/04/19 Reporter: K. M. Van Horn Fix For: 2.8.0 (see comment) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1675) 64-bit failure under gcc on Solaris 2.10
[ https://issues.apache.org/jira/browse/XERCESC-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1675. -- Resolution: Fixed Fix Version/s: 2.8.0 64-bit failure under gcc on Solaris 2.10 Key: XERCESC-1675 URL: https://issues.apache.org/jira/browse/XERCESC-1675 Project: Xerces-C++ Issue Type: Bug Environment: Main Memory is8192 Megabytes Manufacturer is Sun (Sun Microsystems) System Model is Sun-Fire-V490 ROM Version isOBP 4.15.6 2005/01/06 04:24 Number of CPUs is 4 App Architecture is sparc Kernel Version is sun4u OS Name isSunOS OS Version is 5.10 OS Distribution isSolaris 10 1/06 s10s_u1wos_19a SPARC Kernel Version is SunOS iptsd022.mcilink.com 5.10 Generic_118833-20 sun4u sparc SUNW,Sun-Fire-V490 cc version: cc: Sun C 5.8 Patch 121015-02 2006/03/29 CC version: CC: Sun C++ 5.8 Patch 121017-02 2006/04/19 Reporter: K. M. Van Horn Fix For: 2.8.0 (see comment) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1735) Fast append optimization for the DOM parser
[ https://issues.apache.org/jira/browse/XERCESC-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1735: - Affects Version/s: (was: 2.7.0) 3.0.0 We should probably also apply this optimization to the trunk (3.0.0). Fast append optimization for the DOM parser --- Key: XERCESC-1735 URL: https://issues.apache.org/jira/browse/XERCESC-1735 Project: Xerces-C++ Issue Type: Improvement Components: DOM Affects Versions: 3.0.0 Environment: any Reporter: Boris Kolpackov Attachments: fast-append.patch The attached patch adds the appendChildFast function to the DOMParentNode internal interface which skips a number of actions and checks compared to the vanilla appendChild function that are unnecessary in the controlled environment of building a new DOM document. The patch also changes AbstractDOMParser to call appendChildFast instead of appendChild. This change results in 25-30% parsing speed improvement depending on the workload used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1776) bug in schema processing (using the xsd:extension for an another file) since v2.8.0
[ https://issues.apache.org/jira/browse/XERCESC-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1776: - Fix Version/s: 2.9.0 3.0.0 Would be good to fix for 3.0.0 and 2.9.0. bug in schema processing (using the xsd:extension for an another file) since v2.8.0 -- Key: XERCESC-1776 URL: https://issues.apache.org/jira/browse/XERCESC-1776 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2, Validating Parser (Schema) (Xerces 1.5 or up only) Affects Versions: 2.8.0, 3.0.0 Environment: Linux kernel 2.6.18-5-k7 i386 debian gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Reporter: Pawel Stawicki Fix For: 3.0.0, 2.9.0 Attachments: patch.tag_2_8_0, test.tar.gz I have 2 schema files: 1. smerf.xsd: ?xml version=1.0 encoding=UTF-8? schema xmlns=http://www.w3.org/2001/XMLSchema; xmlns:g=http://gargamel; targetNamespace=http://smerf; elementFormDefault=qualified import namespace=http://gargamel;schemaLocation=gargamel.xsd / element name=Alert !-- type=g:gargamelType -- complexType complexContent extension base=g:gargamelType / /complexContent /complexType /element /schema 2.gargamel.xsd : ?xml version=1.0 encoding=UTF-8? xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; targetNamespace=http://gargamel; elementFormDefault=qualified xsd:complexType name=gargamelType xsd:sequence xsd:element name=Data xsd:complexType xsd:sequence xsd:element name=Object type=xsd:string/ /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType /xsd:schema when i try to parse my xml file: ?xml version=1.0 encoding=UTF-8? s:Alert xmlns:s=http://smerf; xmlns:g=http://gargamel; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation='http://smerf smerf.xsd' g:Data g:Object pawel /g:Object /g:Data /s:Alert I get an error: # SAX2Print -v=always test.xml ?xml version=1.0 encoding=LATIN1? s:Alert xsi:schemaLocation=http://smerf smerf.xsd g:Data Cannot load message domain this error is generated by the trunk version of xerces-c (r616373) a similar error occur i version 2.8.0 but not in 2.7.0 It happens only when the element Alert is an xsd:extension for gargamelType no when: element name=Alert type=g:gargamelType/ in version 2.8.0 I get (when using the SAX2 api): Xml:While parsing: Xerces-c error: At line 31, char 50, Unknown element 'g:Object', std -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1780) OSX 10.5 (Leopard): Xerces uses CoreFoundation library calls and crashes...
[ https://issues.apache.org/jira/browse/XERCESC-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1780: - Fix Version/s: 3.0.0 I wonder if this problem is also present in the trunk (3.0.0). I saw a comment to another bug report which said that the trunk code base uses POSIX APIs on OS X. I am also not sure if we should try to fix this for 2.9.0 if it is fixed in 3.0.0. OSX 10.5 (Leopard): Xerces uses CoreFoundation library calls and crashes... --- Key: XERCESC-1780 URL: https://issues.apache.org/jira/browse/XERCESC-1780 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 2.8.0 Environment: MacOS X 10.5 Server (Leopard), i386 or x86_64 architecture. Apache 2.2.6, Prefork, non-threaded, 64bit (default OSX 10.5 httpd server) Reporter: Valery Tschopp Fix For: 3.0.0 The Shibboleth apache2 module (see http://shibboleth.internet2.edu) uses the Xerces-C library to process XML messages. When the module is loaded by apache2, the shared Xercecs-C library is loaded too and initialized. At initialization, first some error messages appear, then the whole httpd process crashes. Error messages in /var/log/apache2/error_log (a lot of them): The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug. Stack trace in crash report: Application Specific Information: *** single-threaded process forked *** Thread 0 Crashed: 0 com.apple.CoreFoundation 0x961479c1 __CFRunLoopFindMode + 353 1 com.apple.CoreFoundation 0x961496ec CFRunLoopAddSource + 124 2 com.apple.DiskArbitration 0x9308ada4 DAApprovalSessionScheduleWithRunLoop + 61 3 ...ple.CoreServices.CarbonCore0x9621b846 _FSGetDiskArbSession(__DASession**, __DAApprovalSession**) + 646 4 ...ple.CoreServices.CarbonCore0x9621b58e CreateDiskArbDiskForMountPath(char const*) + 94 5 ...ple.CoreServices.CarbonCore0x9621a3d2 FSCacheableClient_GetVolumeCachedInfo(char const*, statfs const*, CachedVolumeInfo*, __DADisk*, __DADisk**) + 364 6 ...ple.CoreServices.CarbonCore0x96219d11 MountVolume(char const*, statfs*, unsigned char, unsigned char, __DADisk*, short*) + 537 7 ...ple.CoreServices.CarbonCore0x96219a0a MountInitialVolumes() + 258 8 ...ple.CoreServices.CarbonCore0x96219609 INIT_FileManager() + 219 9 ...ple.CoreServices.CarbonCore0x962194b6 GetRetainedVolFSVCBByVolumeID(unsigned long) + 36 10 ...ple.CoreServices.CarbonCore0x96217c96 PathGetObjectInfo(char const*, unsigned long, unsigned long, VolumeInfo**, unsigned long*, unsigned long*, char*, unsigned long*, unsigned char*) + 202 11 ...ple.CoreServices.CarbonCore0x96217b66 FSPathMakeRefInternal(unsigned char const*, unsigned long, unsigned long, FSRef*, unsigned char*) + 90 12 ...ple.CoreServices.CarbonCore0x962236bb FSPathMakeRef + 47 13 ...ple.CoreServices.CarbonCore0x96236e2b FilterRelevantFilesFromDirectory + 347 14 ...ple.CoreServices.CarbonCore0x96236679 CacheFMMapData + 1565 15 ...ple.CoreServices.CarbonCore0x96235395 IntlFCOpenComponentData + 206 16 ...ple.CoreServices.CarbonCore0x96237be9 InitScriptBundleComponent + 85 17 ...ple.CoreServices.CarbonCore0x96237b8d SMInitIntlSpec + 17 18 ...ple.CoreServices.CarbonCore0x962377a2 LMGetIntlSpec + 76 19 ...ple.CoreServices.CarbonCore0x96238b2c GetScriptManagerVariable + 28 20 ...ple.CoreServices.CarbonCore0x962410cd LocaleRefOrNULLToTagEntryPtr + 74 21 ...ple.CoreServices.CarbonCore0x96240f2e LocaleRefGetPartString + 57 22 ...ple.CoreServices.CarbonCore0x962401c5 SetDefaultLocaleString + 195 23 ...ple.CoreServices.CarbonCore0x962400e0 _ReloadUnicodeUtilData + 92 24 ...ple.CoreServices.CarbonCore0x9623ff16 UCRefreshThreadGlobals + 183 25 ...ple.CoreServices.CarbonCore0x9626fe3f UCCreateCollator + 133 26 libxerces-c.28.dylib 0x0059b1cf xercesc_2_8::MacOSUnicodeConverter::MacOSUnicodeConverter() + 79 27 libxerces-c.28.dylib 0x00598d7a xercesc_2_8::XMLPlatformUtils::makeTransService() + 64 28 libxerces-c.28.dylib 0x005ab68d xercesc_2_8::XMLPlatformUtils::Initialize(char const*, char const*, xercesc_2_8::PanicHandler*, xercesc_2_8::MemoryManager*, bool) + 347 29 libsaml.5.dylib 0x0020b733 saml::SAMLInternalConfig::init() + 259 30 libshib-target.dylib 0x00079be1 shibtarget::STConfig::init(char const*) + 351 31 mod_shib_22.so0x00e17d4f shib_child_init + 137
[jira] Resolved: (XERCESC-1244) Support gcc/g++ compilers on HP-UX.
[
https://issues.apache.org/jira/browse/XERCESC-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov resolved XERCESC-1244.
--
Resolution: Fixed
Fix Version/s: 2.8.0
Support gcc/g++ compilers on HP-UX.
---
Key: XERCESC-1244
URL: https://issues.apache.org/jira/browse/XERCESC-1244
Project: Xerces-C++
Issue Type: Improvement
Affects Versions: 2.5.0
Environment: HP-UX gcc-3.3.4
Reporter: Chris Olsen
Priority: Minor
Fix For: 2.8.0
Need to support he gcc / g++ compilers on HP-UX.
I modified the Makefile.incl and built the package using:
./runConfigure -p hp-11 -c gcc -x g++ -P /home/colsen/tools
Things seem to have built fine. Patch for Makefile.incl:
diff Makefile.incl Makefile.incl-gcc-support
486,501d485
else
TEMPLATESREPOSITORY = ${XML_OBJ_DIR}/ptrepository
COMMON_COMPILE_OPTIONS = -D_HP_UX -DXERCES_TMPLSINC \
-D${OSVERDEFINE} +DAportable +eh +Z -Z +a1 +d
ifeq ($(MODULE), dom)
PLATFORM_COMPILE_OPTIONS = -DDOM_PROJ $(COMMON_COMPILE_OPTIONS)
else
PLATFORM_COMPILE_OPTIONS = $(COMMON_COMPILE_OPTIONS)
-ptr${TEMPLATESREPOSITORY}
endif
MAKE_SHARED = $(CXX) $(PLATFORM_COMPILE_OPTIONS) $(XML_INCL) ${LDFLAGS}
MAKE_SHARED_C = $(CC) $(PLATFORM_COMPILE_OPTIONS) $(XML_INCL) ${LDFLAGS}
ifeq (${TRANSCODER}, ICU)
ALLLIBS = ${LIBS} -licuuc -licudata
else
ALLLIBS = ${LIBS}
endif
503,505c487,497
ifeq (${MESSAGELOADER}, ICU)
ALLLIBS = ${LIBS} -licuuc -licudata -lXercesMessages
endif
---
## Compiler switch to embed a library name
LD_SONAME = -Wl,+h,${SO_NAME}
endif
# Support the gcc compiler on HP-UX 11
ifeq (${CXX}, g++)
MAKE_SHARED = ${CXX} -D${PLATFORM} -shared -fPIC ${LDFLAGS}
MAKE_SHARED_C = ${CC} -D${PLATFORM} -shared -fPIC ${LDFLAGS}
PLATFORM_COMPILE_OPTIONS = -fPIC -D${PLATFORM}
ALLLIBS = ${LIBS}
507d498
EXTRA_LINK_OPTIONS = -b -Wl,+s -Wl,+b,. -Wl,-a,shared
511,512c502
## Compiler switch to embed a library name
LD_SONAME = -Wl,+h,${SO_NAME}
---
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1244) Support gcc/g++ compilers on HP-UX.
[
https://issues.apache.org/jira/browse/XERCESC-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1244.
Support gcc/g++ compilers on HP-UX.
---
Key: XERCESC-1244
URL: https://issues.apache.org/jira/browse/XERCESC-1244
Project: Xerces-C++
Issue Type: Improvement
Affects Versions: 2.5.0
Environment: HP-UX gcc-3.3.4
Reporter: Chris Olsen
Priority: Minor
Fix For: 2.8.0
Need to support he gcc / g++ compilers on HP-UX.
I modified the Makefile.incl and built the package using:
./runConfigure -p hp-11 -c gcc -x g++ -P /home/colsen/tools
Things seem to have built fine. Patch for Makefile.incl:
diff Makefile.incl Makefile.incl-gcc-support
486,501d485
else
TEMPLATESREPOSITORY = ${XML_OBJ_DIR}/ptrepository
COMMON_COMPILE_OPTIONS = -D_HP_UX -DXERCES_TMPLSINC \
-D${OSVERDEFINE} +DAportable +eh +Z -Z +a1 +d
ifeq ($(MODULE), dom)
PLATFORM_COMPILE_OPTIONS = -DDOM_PROJ $(COMMON_COMPILE_OPTIONS)
else
PLATFORM_COMPILE_OPTIONS = $(COMMON_COMPILE_OPTIONS)
-ptr${TEMPLATESREPOSITORY}
endif
MAKE_SHARED = $(CXX) $(PLATFORM_COMPILE_OPTIONS) $(XML_INCL) ${LDFLAGS}
MAKE_SHARED_C = $(CC) $(PLATFORM_COMPILE_OPTIONS) $(XML_INCL) ${LDFLAGS}
ifeq (${TRANSCODER}, ICU)
ALLLIBS = ${LIBS} -licuuc -licudata
else
ALLLIBS = ${LIBS}
endif
503,505c487,497
ifeq (${MESSAGELOADER}, ICU)
ALLLIBS = ${LIBS} -licuuc -licudata -lXercesMessages
endif
---
## Compiler switch to embed a library name
LD_SONAME = -Wl,+h,${SO_NAME}
endif
# Support the gcc compiler on HP-UX 11
ifeq (${CXX}, g++)
MAKE_SHARED = ${CXX} -D${PLATFORM} -shared -fPIC ${LDFLAGS}
MAKE_SHARED_C = ${CC} -D${PLATFORM} -shared -fPIC ${LDFLAGS}
PLATFORM_COMPILE_OPTIONS = -fPIC -D${PLATFORM}
ALLLIBS = ${LIBS}
507d498
EXTRA_LINK_OPTIONS = -b -Wl,+s -Wl,+b,. -Wl,-a,shared
511,512c502
## Compiler switch to embed a library name
LD_SONAME = -Wl,+h,${SO_NAME}
---
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1694) Warnings on gcc from xercesc/validators/schema/SchemaElementDecl.hpp
[
https://issues.apache.org/jira/browse/XERCESC-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov resolved XERCESC-1694.
--
Resolution: Fixed
Fix Version/s: 2.8.0
Warnings on gcc from xercesc/validators/schema/SchemaElementDecl.hpp
Key: XERCESC-1694
URL: https://issues.apache.org/jira/browse/XERCESC-1694
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (Schema) (Xerces 1.5 or up only)
Affects Versions: 2.7.0
Environment: I see this warning on both Linux (x86 and amd64 with
gcc-4.1.1) and Mac (Intel and PPC with gcc 4.0.x)
Reporter: Greg Wolodkin
Priority: Minor
Fix For: 2.8.0
Create a simple .cpp file
#include xercesc/validators/schema/SchemaElementDecl.hpp
and compile it like so (adding Xerces-C to the include path if necessary with
-I...)
gcc -W -c tt.cpp
I see:
...include/xercesc/validators/schema/SchemaElementDecl.hpp: In member
function 'virtual bool xercesc_2_7::SchemaElementDecl::isGlobalDecl() const':
...include/xercesc/validators/schema/SchemaElementDecl.hpp:508: warning:
comparison between signed and unsigned integer expressions
I fixed it like this:
$ p4 diff -du SchemaElementDecl.hpp
//3rdparty/tmw/xerces-c/src/xercesc/validators/schema/SchemaElementDecl.hpp#2
-
/sandbox/greg/Amake/3p/sources/xerces-c/src/xercesc/validators/schema/SchemaElementDecl.hpp
@@ -505,7 +505,7 @@
inline bool SchemaElementDecl::isGlobalDecl() const {
-return (fEnclosingScope == Grammar::TOP_LEVEL_SCOPE);
+return (fEnclosingScope == static_castint(Grammar::TOP_LEVEL_SCOPE));
}
inline SchemaElementDecl*
but you may want to fix it differently by getting all of the types here in
alignment. I didn't see this warning in 2.6.
Thanks for your time!
Greg
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1694) Warnings on gcc from xercesc/validators/schema/SchemaElementDecl.hpp
[
https://issues.apache.org/jira/browse/XERCESC-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1694.
Warnings on gcc from xercesc/validators/schema/SchemaElementDecl.hpp
Key: XERCESC-1694
URL: https://issues.apache.org/jira/browse/XERCESC-1694
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (Schema) (Xerces 1.5 or up only)
Affects Versions: 2.7.0
Environment: I see this warning on both Linux (x86 and amd64 with
gcc-4.1.1) and Mac (Intel and PPC with gcc 4.0.x)
Reporter: Greg Wolodkin
Priority: Minor
Fix For: 2.8.0
Create a simple .cpp file
#include xercesc/validators/schema/SchemaElementDecl.hpp
and compile it like so (adding Xerces-C to the include path if necessary with
-I...)
gcc -W -c tt.cpp
I see:
...include/xercesc/validators/schema/SchemaElementDecl.hpp: In member
function 'virtual bool xercesc_2_7::SchemaElementDecl::isGlobalDecl() const':
...include/xercesc/validators/schema/SchemaElementDecl.hpp:508: warning:
comparison between signed and unsigned integer expressions
I fixed it like this:
$ p4 diff -du SchemaElementDecl.hpp
//3rdparty/tmw/xerces-c/src/xercesc/validators/schema/SchemaElementDecl.hpp#2
-
/sandbox/greg/Amake/3p/sources/xerces-c/src/xercesc/validators/schema/SchemaElementDecl.hpp
@@ -505,7 +505,7 @@
inline bool SchemaElementDecl::isGlobalDecl() const {
-return (fEnclosingScope == Grammar::TOP_LEVEL_SCOPE);
+return (fEnclosingScope == static_castint(Grammar::TOP_LEVEL_SCOPE));
}
inline SchemaElementDecl*
but you may want to fix it differently by getting all of the types here in
alignment. I didn't see this warning in 2.6.
Thanks for your time!
Greg
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1405) IRIX 6.5.19m compile/configure issues with Base64.cpp
[
https://issues.apache.org/jira/browse/XERCESC-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov resolved XERCESC-1405.
--
Resolution: Won't Fix
I don't think we will be supporting IRIX in any future versions unless someone
with knowledge and access will step up to maintain it (in which case feel free
to reopen this bug).
IRIX 6.5.19m compile/configure issues with Base64.cpp
-
Key: XERCESC-1405
URL: https://issues.apache.org/jira/browse/XERCESC-1405
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 2.6.0
Environment: SGI Irix 6.5.19m
C++ Compiler vers 7.4.1m
gcc version 2.8.1
8 500 MHZ IP35 Processors
CPU: MIPS R14000 Processor Chip Revision: 2.4
FPU: MIPS R14010 Floating Point Chip Revision: 2.4
Reporter: Gesner Herard, Jr.
Even after finding closest existing bugs to problem 1256/1252 and employing
the listed changes, still yielding the same errors.
Also tried runConfigure combos:
./runConfigure -p irix -c cc -x CC
./runConfigure -p irix -c cc -x CC -b 64
./runConfigure -p irix -c cc -x CC -b 64 -z -64 -l -64
--
Base64.cpp: creating precompiled header file Base64.pch.
cc-1299 CC: ERROR File = Base64.cpp, Line = 137
An inline specifier is only allowed on function declarations.
static inline void* getExternalMemory(MemoryManager* const allocator
^
cc-1020 CC: ERROR File = Base64.cpp, Line = 137
The identifier MemoryManager is undefined.
static inline void* getExternalMemory(MemoryManager* const allocator
^
cc-1029 CC: ERROR File = Base64.cpp, Line = 137
An expression is expected at this point.
static inline void* getExternalMemory(MemoryManager* const allocator
^
cc-1018 CC: ERROR File = Base64.cpp, Line = 138
An unmatched left parentheses ( appears in an expression.
, unsigned int const sizeToAllocate)
^
cc-1065 CC: ERROR File = Base64.cpp, Line = 139
A semicolon is expected at this point.
{
^
cc-3193 CC: ERROR File = Base64.cpp, Line = 190
The MemoryManager is not a type name.
, MemoryManager* const memMgr)
^
cc-1143 CC: ERROR File = Base64.cpp, Line = 187
Declaration is incompatible with XMLByte *Base64::encode(const XMLByte *,
unsigned int, unsigned int *) (declared at line 98 of
/usr/local/include/xercesc/util/Base64.hpp).
XMLByte* Base64::encode(const XMLByte* const inputData
^
cc-1108 CC: ERROR File = Base64.cpp, Line = 212
The indicated expression must have pointer-to-function type.
XMLByte *encodedData = (XMLByte*) getExternalMemory(memMgr,
(quadrupletCount*FOURBYTE+lineCount+1) * sizeof(XMLByte));
^
cc-3193 CC: ERROR File = Base64.cpp, Line = 297
The MemoryManager is not a type name.
, MemoryManager* const manager
^
cc-1020 CC: ERROR File = Base64.cpp, Line = 298
The identifier Conformance is undefined.
, Conformance conform )
^
cc-1143 CC: ERROR File = Base64.cpp, Line = 296
Declaration is incompatible with int Base64::getDataLength(const XMLCh *)
(declared at line 144 of
/usr/local/include/xercesc/util/Base64.hpp).
int Base64::getDataLength(const XMLCh* const inputData
^
cc-1278 CC: ERROR File = Base64.cpp, Line = 302
No instance of overloaded function Base64::decode matches the argument
list.
The argument types are: (const XMLCh *const, unsigned int *,
error-type *const, error-type).
XMLCh* decodedData = decode(inputData, retLen, manager, conform);
^
cc-1020 CC: ERROR File = Base64.cpp, Line = 308
The identifier returnExternalMemory is undefined.
returnExternalMemory(manager, decodedData);
^
cc-3193 CC: ERROR File = Base64.cpp, Line = 315
The MemoryManager is not a type name.
, MemoryManager* const memMgr
^
cc-1020 CC: ERROR File = Base64.cpp, Line = 316
The identifier Conformance is undefined.
, Conformance conform )
^
cc-1474 CC: ERROR File = Base64.cpp, Line = 313
No instance of overloaded function Base64::decode matches the specified
type.
XMLByte* Base64::decode(const XMLByte* const inputData
^
cc-1278 CC: ERROR File =
[jira] Closed: (XERCESC-1405) IRIX 6.5.19m compile/configure issues with Base64.cpp
[
https://issues.apache.org/jira/browse/XERCESC-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1405.
IRIX 6.5.19m compile/configure issues with Base64.cpp
-
Key: XERCESC-1405
URL: https://issues.apache.org/jira/browse/XERCESC-1405
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 2.6.0
Environment: SGI Irix 6.5.19m
C++ Compiler vers 7.4.1m
gcc version 2.8.1
8 500 MHZ IP35 Processors
CPU: MIPS R14000 Processor Chip Revision: 2.4
FPU: MIPS R14010 Floating Point Chip Revision: 2.4
Reporter: Gesner Herard, Jr.
Even after finding closest existing bugs to problem 1256/1252 and employing
the listed changes, still yielding the same errors.
Also tried runConfigure combos:
./runConfigure -p irix -c cc -x CC
./runConfigure -p irix -c cc -x CC -b 64
./runConfigure -p irix -c cc -x CC -b 64 -z -64 -l -64
--
Base64.cpp: creating precompiled header file Base64.pch.
cc-1299 CC: ERROR File = Base64.cpp, Line = 137
An inline specifier is only allowed on function declarations.
static inline void* getExternalMemory(MemoryManager* const allocator
^
cc-1020 CC: ERROR File = Base64.cpp, Line = 137
The identifier MemoryManager is undefined.
static inline void* getExternalMemory(MemoryManager* const allocator
^
cc-1029 CC: ERROR File = Base64.cpp, Line = 137
An expression is expected at this point.
static inline void* getExternalMemory(MemoryManager* const allocator
^
cc-1018 CC: ERROR File = Base64.cpp, Line = 138
An unmatched left parentheses ( appears in an expression.
, unsigned int const sizeToAllocate)
^
cc-1065 CC: ERROR File = Base64.cpp, Line = 139
A semicolon is expected at this point.
{
^
cc-3193 CC: ERROR File = Base64.cpp, Line = 190
The MemoryManager is not a type name.
, MemoryManager* const memMgr)
^
cc-1143 CC: ERROR File = Base64.cpp, Line = 187
Declaration is incompatible with XMLByte *Base64::encode(const XMLByte *,
unsigned int, unsigned int *) (declared at line 98 of
/usr/local/include/xercesc/util/Base64.hpp).
XMLByte* Base64::encode(const XMLByte* const inputData
^
cc-1108 CC: ERROR File = Base64.cpp, Line = 212
The indicated expression must have pointer-to-function type.
XMLByte *encodedData = (XMLByte*) getExternalMemory(memMgr,
(quadrupletCount*FOURBYTE+lineCount+1) * sizeof(XMLByte));
^
cc-3193 CC: ERROR File = Base64.cpp, Line = 297
The MemoryManager is not a type name.
, MemoryManager* const manager
^
cc-1020 CC: ERROR File = Base64.cpp, Line = 298
The identifier Conformance is undefined.
, Conformance conform )
^
cc-1143 CC: ERROR File = Base64.cpp, Line = 296
Declaration is incompatible with int Base64::getDataLength(const XMLCh *)
(declared at line 144 of
/usr/local/include/xercesc/util/Base64.hpp).
int Base64::getDataLength(const XMLCh* const inputData
^
cc-1278 CC: ERROR File = Base64.cpp, Line = 302
No instance of overloaded function Base64::decode matches the argument
list.
The argument types are: (const XMLCh *const, unsigned int *,
error-type *const, error-type).
XMLCh* decodedData = decode(inputData, retLen, manager, conform);
^
cc-1020 CC: ERROR File = Base64.cpp, Line = 308
The identifier returnExternalMemory is undefined.
returnExternalMemory(manager, decodedData);
^
cc-3193 CC: ERROR File = Base64.cpp, Line = 315
The MemoryManager is not a type name.
, MemoryManager* const memMgr
^
cc-1020 CC: ERROR File = Base64.cpp, Line = 316
The identifier Conformance is undefined.
, Conformance conform )
^
cc-1474 CC: ERROR File = Base64.cpp, Line = 313
No instance of overloaded function Base64::decode matches the specified
type.
XMLByte* Base64::decode(const XMLByte* const inputData
^
cc-1278 CC: ERROR File = Base64.cpp, Line = 319
No instance of overloaded function Base64::decode matches the argument
list.
The argument types are: (const XMLByte *const, unsigned int *,
XMLByte *,
[jira] Resolved: (XERCESC-1243) HPUX 11 with GCC compilation
[
https://issues.apache.org/jira/browse/XERCESC-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov resolved XERCESC-1243.
--
Resolution: Fixed
Fix Version/s: 2.8.0
HPUX 11 with GCC compilation
Key: XERCESC-1243
URL: https://issues.apache.org/jira/browse/XERCESC-1243
Project: Xerces-C++
Issue Type: Improvement
Components: Build
Affects Versions: 2.5.0
Environment: HPUX 11
GCC 3.2
Reporter: Wilfried Goemaere
Fix For: 2.8.0
For compilation with gcc 3.2 on HPUX 11, I have made some changes.
in file : src/xercesc/Makefile.incl
I add gcc section section line 487 to line 504
459 #= HP SPECIFIC OPTIONS ===
460
461 ifeq (${PLATFORM}, HPUX)
462
463OSVERDEFINE=HPUX11
464ifeq (${OSVER}, HPUX10)
465 OSVERDEFINE=HPUX10
466endif
467
468ifeq (${CXX}, aCC)
469 PLATFORM_COMPILE_OPTIONS = -D_HP_UX -DHPaCC \
470 -D${OSVERDEFINE} +DAportable +Z
471 MAKE_SHARED = ${CXX} -D${PLATFORM} ${LDFLAGS}
472 MAKE_SHARED_C = ${CC} -D${PLATFORM} ${LDFLAGS}
473 ifeq (${TRANSCODER}, ICU)
474 ALLLIBS = ${LIBS} -licuuc -licudata
475 else
476 ALLLIBS = ${LIBS}
477 endif
478
479 ifeq (${MESSAGELOADER}, ICU)
480 ALLLIBS = ${LIBS} -licuuc -licudata -lXercesMessages
481 endif
482
483 EXTRA_LINK_OPTIONS = -b -Wl,+s -Wl,+b,.
484 SHLIBSUFFIX=.sl
485 ICUSHLIBSUFFIX=.sl
486else
487 ifeq (${GXX}, yes)
488PLATFORM_COMPILE_OPTIONS = -fPIC -D${PLATFORM} -D_REENTRANT
489MAKE_SHARED = ${CXX} -D${PLATFORM_COMPILE_OPTIONS} -shared
${LDFLAGS}
490MAKE_SHARED_C = ${CC} -D${PLATFORM_COMPILE_OPTIONS} -shared
${LDFLAGS}
491ifeq (${TRANSCODER}, ICU)
492 ALLLIBS = ${LIBS} -licuuc -licudata -L/usr/lib -L/usr/local/lib
-L/usr/ccs/lib -lm -lgen
493else
494 ALLLIBS = ${LIBS} -L/usr/lib -L/usr/local/lib -L/usr/ccs/lib -lm
-lgen
495endif
496
497ifeq (${MESSAGELOADER}, ICU)
498 ALLLIBS = ${LIBS} -licuuc -licudata -lXercesMessages -L/usr/lib
-L/usr/local/lib -L/usr/ccs/lib -lm -lgen
499endif
500
501EXTRA_LINK_OPTIONS = -b -Wl,+s -Wl,+b,.
502SHLIBSUFFIX=.sl
503ICUSHLIBSUFFIX=.sl
504 else
505TEMPLATESREPOSITORY = ${XML_OBJ_DIR}/ptrepository
506COMMON_COMPILE_OPTIONS = -D_HP_UX -DXERCES_TMPLSINC \
507 -D${OSVERDEFINE} +DAportable +eh +Z -Z +a1 +d
508ifeq ($(MODULE), dom)
509 PLATFORM_COMPILE_OPTIONS = -DDOM_PROJ $(COMMON_COMPILE_OPTIONS)
510else
511 PLATFORM_COMPILE_OPTIONS = $(COMMON_COMPILE_OPTIONS)
-ptr${TEMPLATESREPOSITORY}
512endif
513MAKE_SHARED = $(CXX) $(PLATFORM_COMPILE_OPTIONS) $(XML_INCL)
${LDFLAGS}
514MAKE_SHARED_C = $(CC) $(PLATFORM_COMPILE_OPTIONS) $(XML_INCL)
${LDFLAGS}
515ifeq (${TRANSCODER}, ICU)
516 ALLLIBS = ${LIBS} -licuuc -licudata
517else
518 ALLLIBS = ${LIBS}
519endif
520
521ifeq (${MESSAGELOADER}, ICU)
522 ALLLIBS = ${LIBS} -licuuc -licudata -lXercesMessages
523endif
524
525EXTRA_LINK_OPTIONS = -b -Wl,+s -Wl,+b,. -Wl,-a,shared
526SHLIBSUFFIX=.sl
527ICUSHLIBSUFFIX=.sl
528 endif
529endif
530## Compiler switch to embed a library name
531LD_SONAME = -Wl,+h,${SO_NAME}
532 endif
And I modify the source file
src/xercesc/util/Transcoders/Iconv/IconvTransService.cpp
line 82 I add !defined(XML_HPUX) :
82 #elif !defined(XML_OPENSERVER) !defined(XML_HPUX)
83 #include wctype.h
84 #endif
Can you add those changes in further released ?
Wilfried GOEMAERE
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1243) HPUX 11 with GCC compilation
[
https://issues.apache.org/jira/browse/XERCESC-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1243.
HPUX 11 with GCC compilation
Key: XERCESC-1243
URL: https://issues.apache.org/jira/browse/XERCESC-1243
Project: Xerces-C++
Issue Type: Improvement
Components: Build
Affects Versions: 2.5.0
Environment: HPUX 11
GCC 3.2
Reporter: Wilfried Goemaere
Fix For: 2.8.0
For compilation with gcc 3.2 on HPUX 11, I have made some changes.
in file : src/xercesc/Makefile.incl
I add gcc section section line 487 to line 504
459 #= HP SPECIFIC OPTIONS ===
460
461 ifeq (${PLATFORM}, HPUX)
462
463OSVERDEFINE=HPUX11
464ifeq (${OSVER}, HPUX10)
465 OSVERDEFINE=HPUX10
466endif
467
468ifeq (${CXX}, aCC)
469 PLATFORM_COMPILE_OPTIONS = -D_HP_UX -DHPaCC \
470 -D${OSVERDEFINE} +DAportable +Z
471 MAKE_SHARED = ${CXX} -D${PLATFORM} ${LDFLAGS}
472 MAKE_SHARED_C = ${CC} -D${PLATFORM} ${LDFLAGS}
473 ifeq (${TRANSCODER}, ICU)
474 ALLLIBS = ${LIBS} -licuuc -licudata
475 else
476 ALLLIBS = ${LIBS}
477 endif
478
479 ifeq (${MESSAGELOADER}, ICU)
480 ALLLIBS = ${LIBS} -licuuc -licudata -lXercesMessages
481 endif
482
483 EXTRA_LINK_OPTIONS = -b -Wl,+s -Wl,+b,.
484 SHLIBSUFFIX=.sl
485 ICUSHLIBSUFFIX=.sl
486else
487 ifeq (${GXX}, yes)
488PLATFORM_COMPILE_OPTIONS = -fPIC -D${PLATFORM} -D_REENTRANT
489MAKE_SHARED = ${CXX} -D${PLATFORM_COMPILE_OPTIONS} -shared
${LDFLAGS}
490MAKE_SHARED_C = ${CC} -D${PLATFORM_COMPILE_OPTIONS} -shared
${LDFLAGS}
491ifeq (${TRANSCODER}, ICU)
492 ALLLIBS = ${LIBS} -licuuc -licudata -L/usr/lib -L/usr/local/lib
-L/usr/ccs/lib -lm -lgen
493else
494 ALLLIBS = ${LIBS} -L/usr/lib -L/usr/local/lib -L/usr/ccs/lib -lm
-lgen
495endif
496
497ifeq (${MESSAGELOADER}, ICU)
498 ALLLIBS = ${LIBS} -licuuc -licudata -lXercesMessages -L/usr/lib
-L/usr/local/lib -L/usr/ccs/lib -lm -lgen
499endif
500
501EXTRA_LINK_OPTIONS = -b -Wl,+s -Wl,+b,.
502SHLIBSUFFIX=.sl
503ICUSHLIBSUFFIX=.sl
504 else
505TEMPLATESREPOSITORY = ${XML_OBJ_DIR}/ptrepository
506COMMON_COMPILE_OPTIONS = -D_HP_UX -DXERCES_TMPLSINC \
507 -D${OSVERDEFINE} +DAportable +eh +Z -Z +a1 +d
508ifeq ($(MODULE), dom)
509 PLATFORM_COMPILE_OPTIONS = -DDOM_PROJ $(COMMON_COMPILE_OPTIONS)
510else
511 PLATFORM_COMPILE_OPTIONS = $(COMMON_COMPILE_OPTIONS)
-ptr${TEMPLATESREPOSITORY}
512endif
513MAKE_SHARED = $(CXX) $(PLATFORM_COMPILE_OPTIONS) $(XML_INCL)
${LDFLAGS}
514MAKE_SHARED_C = $(CC) $(PLATFORM_COMPILE_OPTIONS) $(XML_INCL)
${LDFLAGS}
515ifeq (${TRANSCODER}, ICU)
516 ALLLIBS = ${LIBS} -licuuc -licudata
517else
518 ALLLIBS = ${LIBS}
519endif
520
521ifeq (${MESSAGELOADER}, ICU)
522 ALLLIBS = ${LIBS} -licuuc -licudata -lXercesMessages
523endif
524
525EXTRA_LINK_OPTIONS = -b -Wl,+s -Wl,+b,. -Wl,-a,shared
526SHLIBSUFFIX=.sl
527ICUSHLIBSUFFIX=.sl
528 endif
529endif
530## Compiler switch to embed a library name
531LD_SONAME = -Wl,+h,${SO_NAME}
532 endif
And I modify the source file
src/xercesc/util/Transcoders/Iconv/IconvTransService.cpp
line 82 I add !defined(XML_HPUX) :
82 #elif !defined(XML_OPENSERVER) !defined(XML_HPUX)
83 #include wctype.h
84 #endif
Can you add those changes in further released ?
Wilfried GOEMAERE
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1668) Good schema rejected - simpleContent/complexContent
[ https://issues.apache.org/jira/browse/XERCESC-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1668: - Component/s: Validating Parser (Schema) (Xerces 1.5 or up only) Good schema rejected - simpleContent/complexContent --- Key: XERCESC-1668 URL: https://issues.apache.org/jira/browse/XERCESC-1668 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (Schema) (Xerces 1.5 or up only) Affects Versions: 2.7.0 Reporter: Jochen Schwarze Attachments: test.xml, test.xsd The attached schema does not validate the attached instance: file:///.../test.xsd:12,36: The type 'xs:anyType' specified as the base in the simpleContent element must not have complexContent Both schema and instance validate in Xerces-J 2.9 (with schema-full-checking), with MSXML 4.0 and 6.0, Saxon-SA 8.8, XSV 2.10-1 and with Alphaworks' SchemaQualityChecker. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1743) Xerces reports it can not find the elment when including the other schema.
[
https://issues.apache.org/jira/browse/XERCESC-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1743:
-
Component/s: Validating Parser (Schema) (Xerces 1.5 or up only)
Xerces reports it can not find the elment when including the other schema.
--
Key: XERCESC-1743
URL: https://issues.apache.org/jira/browse/XERCESC-1743
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (Schema) (Xerces 1.5 or up only)
Affects Versions: 2.7.0
Environment: Solaris 10.
Reporter: PeiHua
Xerces reports it can not find the elment when including the other schema and
the schema's element depended on the othe elment.
But it validates ok in XmlSpy and Oxygen.
void XercesParser::doValidation(const char *theStr, bool setDefaultValue,
bool ignoreError)
{
REPORT_INFO([XercesParser] doValidation);
// create parser if it is not available
if (myParser == NULL)
{
myParser = XMLReaderFactory::createXMLReader();
myParser-setFeature(XMLUni::fgSAX2CoreValidation, true);
myParser-setFeature(XMLUni::fgSAX2CoreNameSpaces, true);
myParser-setFeature(XMLUni::fgXercesSchema, true);
myParser-setFeature(XMLUni::fgXercesDynamic, true);
myParser-setFeature(XMLUni::fgXercesSchemaFullChecking, true);
myParser-setFeature(XMLUni::fgSAX2CoreNameSpacePrefixes, true);
myParser-setFeature(XMLUni::fgXercesCacheGrammarFromParse, true);
myParser-setFeature(XMLUni::fgXercesUseCachedGrammarInParse, true);
mySchema = XMLString::transcode(mySchemaLoc.data());
myParser-setProperty(XMLUni::fgXercesSchemaExternalSchemaLocation,
mySchema);
}
REPORT_INFO(doValidation, mySchemaLoc: mySchemaLoc);
REPORT_INFO(doValidation, theStr: theStr);
if(setDefaultValue)
myParser-setContentHandler(myHandler);
else
myParser-setContentHandler(NULL);
if(!ignoreError)
myParser-setErrorHandler(myHandler);
else
myParser-setErrorHandler(NULL);
try
{
// added for supporting file parsing
RWURL url(theStr);
if (url.isValid() == false)
{
int len = strlen(theStr);
const char *bufId = ABC;
// the buffer must be allocated dynamically
MemBufInputSource theMBIS(reinterpret_castconst
XMLByte*(theStr), (const unsigned int)len, bufId);
myParser-parse(theMBIS);
}
else
myParser-parse(theStr);
}
{
// handle request format error
throw e;
}
catch (...)
{
// handle other errors
XMLString::release(mySchema);
// the parser must be released here
delete myParser;
myParser = NULL;
throw FDSException::FDSStandardException(doValidation, An error
occurred during parsing., 0);
}
}
void XercesParser::doValidation(const FDSNamedValue theNV, bool
setDefaultValue, bool ignoreError)
{
REPORT_INFO([XercesParser] doValidation);
ostrstream tmpStr;
theNV.print(tmpStr, 0);
tmpStr.put('\0');
char *tmpStr1 = tmpStr.str();
RWCString tmpStr2(tmpStr1);
delete[] tmpStr1;
doValidation(tmpStr2.data(), setDefaultValue, ignoreError);
}
And Invoke the functions before.
---
const RWCString schemaLoc = http://www.xxx.com/ test.xsd;
.
// get parser object
XercesParser* theParser = theObj-getObj();
// do validation
try
{
theParser-doValidation(*theNV);
}
catch (FDSException::FDSStandardException e)
{
// release cached object
ObjectPool::getInstance()-releaseObject(theObj);
cout [testMain] Error: e.information() endl;
cout [testMain] Reason: e.reason() endl;
}
schema and xml below.
Xml - A.xsd
A.xsd include B.xsd
?xml version=1.0 encoding=UTF-8?
createService groupId=1234561702 serviceProviderId=1234561702
xmlns=http://www.xxx.com/abc/;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.xxx.com/abc/ A.xsd
serviceProviderId1234561702/serviceProviderId
groupId1234561702/groupId
serviceNameEnhanced Outgoing Calling Plan/serviceName
/createService
A.xsd
xs:schema xmlns=http://www.xxx.com/abc/
xmlns:base=http://www.xxx.com/base/;
[jira] Updated: (XERCESC-1742) Xerces can not check the xs namespace elements when doing validation
[
https://issues.apache.org/jira/browse/XERCESC-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1742:
-
Component/s: Validating Parser (Schema) (Xerces 1.5 or up only)
Xerces can not check the xs namespace elements when doing validation
--
Key: XERCESC-1742
URL: https://issues.apache.org/jira/browse/XERCESC-1742
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (Schema) (Xerces 1.5 or up only)
Affects Versions: 2.7.0
Environment: Solaris 10
Reporter: PeiHua
I use Xerices c++ 2.7.0 to validate xml.But I found it can not check the xs
element itself.
void XercesParser::doValidation(const char *theStr, bool setDefaultValue,
bool ignoreError)
{
REPORT_INFO([XercesParser] doValidation);
// create parser if it is not available
if (myParser == NULL)
{
myParser = XMLReaderFactory::createXMLReader();
myParser-setFeature(XMLUni::fgSAX2CoreValidation, true);
myParser-setFeature(XMLUni::fgSAX2CoreNameSpaces, true);
myParser-setFeature(XMLUni::fgXercesSchema, true);
myParser-setFeature(XMLUni::fgXercesDynamic, true);
myParser-setFeature(XMLUni::fgXercesSchemaFullChecking, true);
myParser-setFeature(XMLUni::fgSAX2CoreNameSpacePrefixes, true);
myParser-setFeature(XMLUni::fgXercesCacheGrammarFromParse, true);
myParser-setFeature(XMLUni::fgXercesUseCachedGrammarInParse, true);
mySchema = XMLString::transcode(mySchemaLoc.data());
myParser-setProperty(XMLUni::fgXercesSchemaExternalSchemaLocation,
mySchema);
}
REPORT_INFO(doValidation, mySchemaLoc: mySchemaLoc);
REPORT_INFO(doValidation, theStr: theStr);
if(setDefaultValue)
myParser-setContentHandler(myHandler);
else
myParser-setContentHandler(NULL);
if(!ignoreError)
myParser-setErrorHandler(myHandler);
else
myParser-setErrorHandler(NULL);
try
{
// added for supporting file parsing
RWURL url(theStr);
if (url.isValid() == false)
{
int len = strlen(theStr);
const char *bufId = ABC;
// the buffer must be allocated dynamically
MemBufInputSource theMBIS(reinterpret_castconst
XMLByte*(theStr), (const unsigned int)len, bufId);
myParser-parse(theMBIS);
}
else
myParser-parse(theStr);
}
{
// handle request format error
throw e;
}
catch (...)
{
// handle other errors
XMLString::release(mySchema);
// the parser must be released here
delete myParser;
myParser = NULL;
throw FDSException::FDSStandardException(doValidation, An error
occurred during parsing., 0);
}
}
void XercesParser::doValidation(const FDSNamedValue theNV, bool
setDefaultValue, bool ignoreError)
{
REPORT_INFO([XercesParser] doValidation);
ostrstream tmpStr;
theNV.print(tmpStr, 0);
tmpStr.put('\0');
char *tmpStr1 = tmpStr.str();
RWCString tmpStr2(tmpStr1);
delete[] tmpStr1;
doValidation(tmpStr2.data(), setDefaultValue, ignoreError);
}
And Invoke the functions before.
---
const RWCString schemaLoc = http://www.xxx.com/CommPilotExpress/
/home/ehuapei/tools/validation
/bin/test.xsd;
.
// get parser object
XercesParser* theParser = theObj-getObj();
// do validation
try
{
theParser-doValidation(*theNV);
}
catch (FDSException::FDSStandardException e)
{
// release cached object
ObjectPool::getInstance()-releaseObject(theObj);
cout [testMain] Error: e.information() endl;
cout [testMain] Reason: e.reason() endl;
}
schema and xml below.
?xml version=1.0 encoding=UTF-8?^M
xs:schema xmlns:base=ht
tp://www.xxx.com/base/ xmlns=http://www.xxx.com/CommPilotExpress/;
xmlns:xs=http:
//www.w3.org/2001/XMLSchema
targetNamespace=http://www.xxx.com/CommPilotExpress/; elementFormDe
fault=qualified attributeFormDefault=qualified^M
^M
xs:element name=setService^M
xs:annotation^M
xs:documentationTarget
CommPilotExpress/xs:documentation^M
/xs:annotation^M
xs:complexType^M
xs:sequence^M
xs:element name=serviceSpecificData^M
xs:complexType^M
[jira] Updated: (XERCESC-1718) Invalid anonymous type definition with the name attribute is not caught in some situations
[ https://issues.apache.org/jira/browse/XERCESC-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1718: - Fix Version/s: 2.9.0 3.0.0 Would be good to fix for 3.0.0 and 2.9.0. Invalid anonymous type definition with the name attribute is not caught in some situations -- Key: XERCESC-1718 URL: https://issues.apache.org/jira/browse/XERCESC-1718 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (Schema) (Xerces 1.5 or up only) Affects Versions: 2.7.0 Environment: any Reporter: Boris Kolpackov Fix For: 3.0.0, 2.9.0 Attachments: test.xml, test.xsd Run domprint on the attached test.xml: domprint -v=always -n -s -f test.xml It does not report any errors even though there is one in test.xsd, line 13. If I change the name of the first type to list1 then the error is detected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1782) size_t-Bug in IconvGNUWrapper
[ https://issues.apache.org/jira/browse/XERCESC-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1782: - Fix Version/s: 2.9.0 3.0.0 Would be good to fix for 3.0.0 and 2.9.0. size_t-Bug in IconvGNUWrapper - Key: XERCESC-1782 URL: https://issues.apache.org/jira/browse/XERCESC-1782 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.7.0 Reporter: Florian Bous Fix For: 3.0.0, 2.9.0 In IconvGNUTransService.cpp there are two cases where addresses of unsigned int-variables are casted to size_t *, and handed over to a IconvGNUWrapper::iconvTo. IconvGNUWrapper::iconvTo in turn calls ::iconvTo. In our environment, where size_t is not the same as unsigned int, this call crashes fatally with a signal. When I copy the unsigned int-variables to size_t-variables and call IconvGNUWrapper::iconvTo with the addresses of the size_t-variables, everything works fine. In both cases, the unsigned int-variables are called wLent. The first such occurence is in IconvGNULCPTranscoder::transcode(const XMLCh* const), the second in IconvGNULCPTranscoder::transcode(const XMLCh* const, MemoryManager* const). We use Version 2.7, but as far as I could see, the bug was still there in 2.8 - the latest version I had a look at. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1781) Removing the content handler from SAX2XMLReader mid-parse causes a null-pointer exception in some circumstances
[ https://issues.apache.org/jira/browse/XERCESC-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1781: - Fix Version/s: 2.9.0 3.0.0 Removing the content handler from SAX2XMLReader mid-parse causes a null-pointer exception in some circumstances --- Key: XERCESC-1781 URL: https://issues.apache.org/jira/browse/XERCESC-1781 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2 Affects Versions: 2.8.0 Reporter: Alex Smith Priority: Minor Fix For: 3.0.0, 2.9.0 Attachments: xerces-c-handler-checking.patch The documentation for SAX2XMLReader states that one may change the handlers (e.g. content handler) during a parse (i.e. from a handler callback) and the new handler will be used immediately. This is true but in some circumstances it is possible cause a null-pointer exception by removing a handler from within a callback. For example consider an application which has installed an advanced document handler but also wants access to the Locator object so initially sets a regular content handler (this is how I came across this issue). The content handler need only implement the setDocumentLocator method and once this method has been called and the pointer to the locator saved it can be removed. Indeed it is desirable to remove it once its work is done to reduce overhead. However a call to setContentHandler(NULL) of the SAX2XMLReader from within the setDocumentLocator handler method causes a null-pointer exception. This is because the startDocument handler method is called immediately afterwards without checking that the handler pointer is still valid. Of course the work-around is trivial; move the setContentHandler(NULL) call to the startDocument handler. There are various other handler methods where similar problems could occur. For example endElement is called after startElement in the case of an empty element and again it is assumed that the handler pointer remains valid. The situation here might be an application which needs to examine only the root element (e.g. to obtain information about the namespace) but wishes to parse the whole document to obtain any error information (so only the content handler is removed in startElement, not the error handler). This would work fine for most documents and the flaw would likely not be noticed but a document with an empty root element would crash the application (potential a security issue). The LexicalHandler also has one instance where this problem could arise. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1586) IconvGNU doesn't work at all on x86_64 (SIGSEGV)
[ https://issues.apache.org/jira/browse/XERCESC-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1586: - Fix Version/s: 2.9.0 3.0.0 Would be good to fix for 3.0.0 and 2.9.0. IconvGNU doesn't work at all on x86_64 (SIGSEGV) Key: XERCESC-1586 URL: https://issues.apache.org/jira/browse/XERCESC-1586 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.7.0 Environment: CentOS 4.3 x86_64 Reporter: Stefan Ring Fix For: 3.0.0, 2.9.0 When xerces-c is configured with -tIconvGNU, it just doesn't work at all on x86_64. I tried on Fedora Core 5 and CentOS 4.3, xerces-c 2.6 and 2.7. For building, I used the supplied .spec file and just replaced -tnative with -tIconvGNU. While it works fine with -tnative, the same cannot be said about the iconv configuration. [EMAIL PROTECTED] bin]$ pwd /usr/src/redhat/BUILD/xerces-c-src_2_7_0/bin [EMAIL PROTECTED] bin]$ LD_LIBRARY_PATH=../lib gdb ./SAX2Print GNU gdb Red Hat Linux (6.3.0.0-1.96rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib64/tls/libthread_db.so.1. (gdb) r /tmp/IMEX.xml Starting program: /usr/src/redhat/BUILD/xerces-c-src_2_7_0/bin/SAX2Print /tmp/IMEX.xml (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 182908767616 (LWP 17384)] (no debugging symbols found) (no debugging symbols found) ?xml version=1.0 encoding=LATIN1? Fatal Error at file , line 0, char 0 Message: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 182908767616 (LWP 17384)] 0x002a95f3179c in __gconv_transform_ucs2_internal () from /lib64/tls/libc.so.6 (gdb) bt #0 0x002a95f3179c in __gconv_transform_ucs2_internal () from /lib64/tls/libc.so.6 #1 0x002a95f2c538 in __gconv () from /lib64/tls/libc.so.6 #2 0x002a95f2bb9b in iconv () from /lib64/tls/libc.so.6 #3 0x002a9587dd20 in xercesc_2_7::IconvGNUWrapper::iconvTo () from ../lib/libxerces-c.so.27 #4 0x002a9587ed78 in xercesc_2_7::IconvGNULCPTranscoder::transcode () from ../lib/libxerces-c.so.27 #5 0x002a9592d441 in xercesc_2_7::XMLString::transcode () from ../lib/libxerces-c.so.27 #6 0x0040a23d in SAX2PrintHandlers::fatalError () #7 0x002a958b2874 in xercesc_2_7::SAX2XMLReaderImpl::error () from ../lib/libxerces-c.so.27 #8 0x002a95928a70 in xercesc_2_7::XMLScanner::emitError () from ../lib/libxerces-c.so.27 #9 0x002a9586ec0e in xercesc_2_7::IGXMLScanner::scanDocument () from ../lib/libxerces-c.so.27 #10 0x002a9592793d in xercesc_2_7::XMLScanner::scanDocument () from ../lib/libxerces-c.so.27 #11 0x002a959279bb in xercesc_2_7::XMLScanner::scanDocument () from ../lib/libxerces-c.so.27 #12 0x002a958b13b0 in xercesc_2_7::SAX2XMLReaderImpl::parse () from ../lib/libxerces-c.so.27 #13 0x00408e40 in main () It doesn't really matter what the file IMEX.xml looks like but for the sake of completenes, that's all there is: ?xml version=1.0 encoding=UTF-8? imex /imex -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1783) Finish makefiles for the ICU message loader
Finish makefiles for the ICU message loader --- Key: XERCESC-1783 URL: https://issues.apache.org/jira/browse/XERCESC-1783 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.0.0 Environment: autotools-based Reporter: Boris Kolpackov Fix For: 3.0.0 Makefile in util/MsgLoaders/ICU/resources needs completeion. In particular, the install target is missing. We should also probably disable the automatic selection of this MsgLoader in configure since it doesn't add much except an extra library. Also see this bug report: https://issues.apache.org/jira/browse/XERCESC-1769 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1784) Website support for Xerces-C++ 2 and 3-series
Website support for Xerces-C++ 2 and 3-series - Key: XERCESC-1784 URL: https://issues.apache.org/jira/browse/XERCESC-1784 Project: Xerces-C++ Issue Type: Task Components: Documentation Reporter: Boris Kolpackov Assignee: Boris Kolpackov Fix For: 3.0.0 I think it will be a good idea to have online documentation (build instructions, API references, etc.) for both 2 (2.8.0) and 3 (3.0.0)-series. The reason for this is that 3.0.0 introduces a number of backwards-incompatible changes and I expect a sizable chunk of the user base to stick with the 2-series for some time. My idea on how to do this is to have two sets of menu links in the left menu bar. One for 2.8.0 and one for 3.0.0 (some links, e.g., Charter, Release Info, Feedback, etc.) are common for both releases and won't be in the release-specific sections. In other words, the menu will look like this: * Readme * Charter * Release Info * Download -- 2.8.0: * Installation * Build Instructions * Programming Guide * Samples * FAQs * API Reference * DOM C++ Binding * Migration Guide - 3.0.0: * Installation * Build Instructions * Programming Guide * Samples * FAQs * API Reference * DOM C++ Binding * Migration Guide - * Feedback * Bug Reporting * Mailing Lists * Source Repository * Applications For this to work we will need to divorce the website source from the library source itself (which I believe is a good idea on its own) and put it into a separate SVN project. The complete website copy will then be built by using the release-independent part plus the release-specific parts from the latest releases of 2 and 3-series. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1024) CVS contains LF-only project files
[
https://issues.apache.org/jira/browse/XERCESC-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1024.
CVS contains LF-only project files
--
Key: XERCESC-1024
URL: https://issues.apache.org/jira/browse/XERCESC-1024
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 2.3.0
Environment: Operating System: Windows NT/2K
Platform: PC
Reporter: Ronald Landheer-Cieslak
Fix For: 2.8.0
The .dsp and .dsw files in CVS contain LF(\n)-only .dsp and .dsw files which
results in MSVC6 silently failing to read them.
The solution is simple: check out and do
$ find . \( -name '*.dsp' -o -name '*.dsw' \) -exec unix2dos \{\} \;
to fix the line-endings and
$ find . \( -name '*.dsp' -o -name '*.dsw' \) -exec cvs admin -kb \{\} \;
to put the binary flag on all of them
You'll have to re-commit the files to make it stick.
I've just done the former of the two and it fixed the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1095) App on IRIX fails to compile with 2.4.0 include file
[
https://issues.apache.org/jira/browse/XERCESC-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1095.
App on IRIX fails to compile with 2.4.0 include file
Key: XERCESC-1095
URL: https://issues.apache.org/jira/browse/XERCESC-1095
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 2.4.0
Environment: Operating System: Other
Platform: Other
Reporter: Karl Schultz
The compiler message is:
cc-1460 CC: WARNING File
= /xercesc_2_4_0/validators/schema/SchemaAttDef.hpp, Line = 419
Function function SchemaAttDef::getValidationAttempted is redeclared
inline after being called.
inline PSVIDefs::Validation SchemaAttDef::getValidationAttempted() const {
end compiler message
IRIX 6.5 with MIPSpro Compilers: Version 7.30
I fixed this by adding inline to the function prototype at line 194.
Also had to do it for getTypeAnonymous at line 218 and getMemberTypeAnonymous
at line 238.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-992) Internal compiler error
[ https://issues.apache.org/jira/browse/XERCESC-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-992. --- Internal compiler error --- Key: XERCESC-992 URL: https://issues.apache.org/jira/browse/XERCESC-992 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.3.0 Environment: Operating System: Linux Platform: PC Reporter: Christian Knoke Fix For: 2.8.0 I cannot build xerces on a SuSE 7.3 distribution. I checked two ways of build: with runConfigure and configure (without params) I get: /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c: In method `xercesc_2_3::DOMDeepNodeListPoolxercesc_2_3::DOMDeepNodeListImpl::DOMDeepNodeListPool(long unsigned int, bool, long unsigned int = 128)': DOMDocumentImpl.cpp:900: instantiated from here /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: Internal compiler error. /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: Please submit a full bug report. /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. make[2]: *** [DOMDocumentImpl.o] Error 1 make[2]: Leaving directory `/home/chris/tmp/xerces-c-src_2_3_0/src/xercesc/dom/impl' make[1]: *** [impl] Error 2 make[1]: Leaving directory `/home/chris/tmp/xerces-c-src_2_3_0/src/xercesc/dom' make: *** [Dom] Error 2 I have: [EMAIL PROTECTED]:~/tmp/xerces-c-src_2_3_0/doc gcc --version 2.95.3 Any clues? Christian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-348) Xerces 1.3 support for SunPro 5.3, HP aCC 3.33, IBM VA 5.0.2, GCC 2.96, static builds
[ https://issues.apache.org/jira/browse/XERCESC-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-348. - Resolution: Fixed Assignee: (was: Xerces-C Developers Mailing List) Building of static and shared libraries for these platforms compilers (or their newer versions) is supported in 2.8.0. Xerces 1.3 support for SunPro 5.3, HP aCC 3.33, IBM VA 5.0.2, GCC 2.96, static builds - Key: XERCESC-348 URL: https://issues.apache.org/jira/browse/XERCESC-348 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 1.6.0 Environment: Operating System: All Platform: All Reporter: kevinj Attachments: xerces16patch.tar.gz In the next update, I will attach the source code changes needed to port the Xerces 1.3 release to the following platforms for both static and shared libraries: Solaris 8, Forte 6, update 2 patch 111685-03 (32 bit) HP-UX 11i aCC A.3.33 (32 bit) AIX 5L 5.1.0.10 VisualAge 5.0.21 (32 bit) Red Hat Linux 7.2, gcc C++ 2.96 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1360) compile error for 64bit solaris binary by GCC 3.3.2
[ https://issues.apache.org/jira/browse/XERCESC-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1360. -- Resolution: Won't Fix Bug in an obsolete compiler. compile error for 64bit solaris binary by GCC 3.3.2 --- Key: XERCESC-1360 URL: https://issues.apache.org/jira/browse/XERCESC-1360 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.6.0 Reporter: Constellation Energy I am trying to build 64 bits xercesc 2.6 with gcc 3.3.2 on SunOS 5.9, and got an error in an assemble file, here my steps: xerces-c-src_2_6_0/src/xercesc uname -a SunOS sasapp-msw-01 5.9 Generic_117171-15 sun4u sparc SUNW,Sun-Fire-V440 xerces-c-src_2_6_0/src/xercesc ./runConfigure -psolaris -cgcc -xg++ -minmem -nsocket -tnative -rpthread -l-m64 -l-mcpu=v9 -z-m64 -z-mcpu=v9 xerces-c-src_2_6_0/src/xercesc make ... ... ... g++ -fPIC -DSOLARIS -D_REENTRANT -c -I/home/e11190/hawru/3rd_party/xerces-c-src_2_6_0/include -m64 -mcpu=v9 -w -O -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM -DPROJ_DEPRECATED_DOM -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DXML_USE_PTHREADS -DXML_USE_NETACCESSOR_SOCKET -o /home/e11190/hawru/3rd_party/xerces-c-src_2_6_0/obj/SOLARIS/DFAContentModel.o DFAContentModel.cpp /usr/ccs/bin/as: /usr/tmp/ccCniKYa.s, line 2096: error: invalid (misaligned) register make[2]: *** [DFAContentModel.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-348) Xerces 1.3 support for SunPro 5.3, HP aCC 3.33, IBM VA 5.0.2, GCC 2.96, static builds
[ https://issues.apache.org/jira/browse/XERCESC-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-348. --- Xerces 1.3 support for SunPro 5.3, HP aCC 3.33, IBM VA 5.0.2, GCC 2.96, static builds - Key: XERCESC-348 URL: https://issues.apache.org/jira/browse/XERCESC-348 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 1.6.0 Environment: Operating System: All Platform: All Reporter: kevinj Attachments: xerces16patch.tar.gz In the next update, I will attach the source code changes needed to port the Xerces 1.3 release to the following platforms for both static and shared libraries: Solaris 8, Forte 6, update 2 patch 111685-03 (32 bit) HP-UX 11i aCC A.3.33 (32 bit) AIX 5L 5.1.0.10 VisualAge 5.0.21 (32 bit) Red Hat Linux 7.2, gcc C++ 2.96 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-992) Internal compiler error
[ https://issues.apache.org/jira/browse/XERCESC-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-992. - Resolution: Won't Fix Fix Version/s: 2.8.0 Assignee: (was: Xerces-C Developers Mailing List) Bug in obsolete compiler. Internal compiler error --- Key: XERCESC-992 URL: https://issues.apache.org/jira/browse/XERCESC-992 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.3.0 Environment: Operating System: Linux Platform: PC Reporter: Christian Knoke Fix For: 2.8.0 I cannot build xerces on a SuSE 7.3 distribution. I checked two ways of build: with runConfigure and configure (without params) I get: /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c: In method `xercesc_2_3::DOMDeepNodeListPoolxercesc_2_3::DOMDeepNodeListImpl::DOMDeepNodeListPool(long unsigned int, bool, long unsigned int = 128)': DOMDocumentImpl.cpp:900: instantiated from here /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: Internal compiler error. /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: Please submit a full bug report. /home/chris/tmp/xerces-c-src_2_3_0/include/xercesc/dom/impl/DOMDeepNodeListPool.c:104: See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. make[2]: *** [DOMDocumentImpl.o] Error 1 make[2]: Leaving directory `/home/chris/tmp/xerces-c-src_2_3_0/src/xercesc/dom/impl' make[1]: *** [impl] Error 2 make[1]: Leaving directory `/home/chris/tmp/xerces-c-src_2_3_0/src/xercesc/dom' make: *** [Dom] Error 2 I have: [EMAIL PROTECTED]:~/tmp/xerces-c-src_2_3_0/doc gcc --version 2.95.3 Any clues? Christian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-381) Changes required to build with gcc 2.95.2 on hpux and aix
[
https://issues.apache.org/jira/browse/XERCESC-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-381.
---
Resolution: Fixed
Fix Version/s: 2.8.0
Assignee: (was: Xerces-C Developers Mailing List)
Changes required to build with gcc 2.95.2 on hpux and aix
-
Key: XERCESC-381
URL: https://issues.apache.org/jira/browse/XERCESC-381
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 1.6.0
Environment: Operating System: HP-UX
Platform: HP
Reporter: Bhushan Khanal
Fix For: 2.8.0
Here are the changes we had to make to build xerces 1.6 with gcc 2.95.2 on
hpux
11.
./idom/IDDocumentImpl.hpp
// avoid the size_t error on hpux
#ifdef HPUX
#include stdio.h
#endif
./parsers/IDOMParser.cpp
---
// avoid the size_t error on hpux
#ifdef HPUX
#include stdio.h
#endif
./util/Transcoders/Iconv/IconvTransService.cpp
---
// need to skip this ifdef on HPUX
#if !defined(XML_HPUX)
#if defined (XML_GCC) || defined (XML_PTX) || defined (XML_IBMVAOS2)
#include wctype.h
#endif
#endif
makefile.incl diff
---
1c1
# -*- makefile -*-
---
#
195,207c195
ifeq (${CXX}, g++)
# flags for compiling with gcc on aix.
PLATFORM_COMPILE_OPTIONS= -D${PLATFORM} -gxcoff+ -Wno-format -Wno-
comment -Wno-return-type -fhuge-objects -D_THREAD_SAFE -D_REENTRANT -mthreads
MAKE_SHARED = ${CXX} -D${PLATFORM} -shared -gxcoff+ -mthreads -
Xlinker -bbigtoc ${LDFLAGS}
MAKE_SHARED_C = ${CC} -D${PLATFORM} -shared -gxcoff+ -mthreads -
Xlinker -bbigtoc ${LDFLAGS}
else
PLATFORM_COMPILE_OPTIONS = -qnotempinc -D_THREAD_SAFE
MAKE_SHARED = makeC++SharedLib_r -p 5000 -brtl ${LDFLAGS}
MAKE_SHARED_C = makeC++SharedLib_r -p 5000 -brtl ${LDFLAGS}
EXTRA_LINK_OPTIONS = -bmap:$(XML_OBJ)/${LIBNAME}${VER}.map
endif
ifeq (${TRANSCODER}, ICU)
---
ifeq (${TRANSCODER}, ICU)
209,213c197,204
else
ALLLIBS = $(LIBS)
endif
SHLIBSUFFIX=.a
---
else
ALLLIBS = ${LIBS} -L/usr/lpp/xlC/lib
endif
PLATFORM_COMPILE_OPTIONS = -qnotempinc -D_THREAD_SAFE
MAKE_SHARED = makeC++SharedLib_r -p 5000 -brtl ${LDFLAGS}
MAKE_SHARED_C = makeC++SharedLib_r -p 5000 -brtl ${LDFLAGS}
EXTRA_LINK_OPTIONS = -bmap:$(XML_OBJ)/${LIBNAME}${VER}.map
SHLIBSUFFIX=.a
333,346d323
# add stuff for g++
endif
ifeq (${CXX}, g++)
PLATFORM_COMPILE_OPTIONS= -D${PLATFORM} -fPIC -D__POSIX_C_SOURCE=199506L
MAKE_SHARED = ${CXX} -D${PLATFORM} -shared -fPIC ${LDFLAGS}
MAKE_SHARED_C = ${CC} -D${PLATFORM} -shared -fPIC ${LDFLAGS}
ALLLIBS = ${LIBS}
ifeq (${TRANSCODER}, ICU)
ALLLIBS = ${LIBS} -L/usr/lib -L/usr/local/lib -L/usr/ccs/lib
-licuuc -
licudata -lc
else
ALLLIBS = ${LIBS}
endif
SHLIBSUFFIX=.sl
# end of added stuff
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-468) Xerces-C precompiled headers do not exist upon install
[ https://issues.apache.org/jira/browse/XERCESC-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-468. --- Xerces-C precompiled headers do not exist upon install -- Key: XERCESC-468 URL: https://issues.apache.org/jira/browse/XERCESC-468 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 1.7.0 Environment: Operating System: Windows NT/2K Platform: PC Reporter: Jamie L. Mascherino Fix For: 2.8.0 The Xerces-com project is setup to use precompiled headers. However, the precompiled headers do not exist when the project is first installed. You must first change the project settings not to use precompiled headers, compile the project and then change the settings back. If this is the appropriate process, the installation instructions should state such. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1769) xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and various other problems
[ https://issues.apache.org/jira/browse/XERCESC-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1769: - Fix Version/s: 2.9.0 3.0.0 The trunk most likely has the same problems. Would be good to fix for 3.0.0. xerces-c++ 2.8.0 ICU message loader broken due to deprecated API usage and various other problems - Key: XERCESC-1769 URL: https://issues.apache.org/jira/browse/XERCESC-1769 Project: Xerces-C++ Issue Type: Bug Affects Versions: 2.8.0 Environment: Gentoo Linux 2007.0 AMD64, ICU 3.6 and 3.8 Reporter: Tiziano Müller Fix For: 3.0.0, 2.9.0 Attachments: xerces-c-2.8.0-icu_ressource_fix.patch a) the .res-file can't be used as a fallback if the memory-blob can't be loaded, but it should be the .dat-file (as far as I understood it) b) loading the messages using a full file-path is deprecated (according to http://www.icu-project.org/apiref/icu4c/ures_8h.html#c4d72fc9f7cc63a05f646cabee4be167) and it really doesn't work c) When using make install to install the library, the library libXercesMessages.so.28.0 doesn't get installed which leads to a unresolved symbol error when linking against libxerces-c.so.28.0 d) When trying to run a test or a sample linked against xerces-c++ built with ICU message loader support, xerces-c++ panics with the error Cannot load message domain, whether or not libXercesMessages and the .res/.dat-file in /usr/msg are available or not. The patch I'm going to attach fixes this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1753) Xerces crashes when a invalid file is passed an input.
[ https://issues.apache.org/jira/browse/XERCESC-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1753. Xerces crashes when a invalid file is passed an input. -- Key: XERCESC-1753 URL: https://issues.apache.org/jira/browse/XERCESC-1753 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2 Affects Versions: 2.4.0 Environment: Sun Solaris Reporter: Sunil Dandamudi Fix For: 2.6.0 When a invalid file like a excel sheet is passed as input to SAX Parser, the xerces is gpf with the following stack trace. This has been fixed in 2.6. libxerces-c.so.24.0:__1cLxercesc_2_4MXMLException2T5B6M_v_+0x4 libxerces-c.so.24.0:__1cLxercesc_2_4RXMLUTF8TranscoderNtranscodeFrom6MkpkCkIkpH5rIkpC_I_+0x550 libxerces-c.so.24.0:__1cLxercesc_2_4JXMLReaderOxcodeMoreChars6MkpHkpCkI_I_+0x98 libxerces-c.so.24.0:__1cLxercesc_2_4JXMLReaderRrefreshCharBuffer6M_b_+0x270 libxerces-c.so.24.0:__1cLxercesc_2_4JReaderMgrMpeekNextChar6M_H_+0x24 libxerces-c.so.24.0:__1cLxercesc_2_4KXMLScannerKscanProlog6M_v_+0x74 libdstxxmlparser.so:__1cLxercesc_2_4OXMLScannerMscanDocument6Mrkn0ALInputSource__v_+0x78 libdstxxmlparser.so:__1cLxercesc_2_4NSAXParserFparse6Mrkn0ALInputSource__v_+0x6c Any patch available for 2.4 ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1753) Xerces crashes when a invalid file is passed an input.
[ https://issues.apache.org/jira/browse/XERCESC-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1753. -- Resolution: Fixed Xerces crashes when a invalid file is passed an input. -- Key: XERCESC-1753 URL: https://issues.apache.org/jira/browse/XERCESC-1753 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2 Affects Versions: 2.4.0 Environment: Sun Solaris Reporter: Sunil Dandamudi Fix For: 2.6.0 When a invalid file like a excel sheet is passed as input to SAX Parser, the xerces is gpf with the following stack trace. This has been fixed in 2.6. libxerces-c.so.24.0:__1cLxercesc_2_4MXMLException2T5B6M_v_+0x4 libxerces-c.so.24.0:__1cLxercesc_2_4RXMLUTF8TranscoderNtranscodeFrom6MkpkCkIkpH5rIkpC_I_+0x550 libxerces-c.so.24.0:__1cLxercesc_2_4JXMLReaderOxcodeMoreChars6MkpHkpCkI_I_+0x98 libxerces-c.so.24.0:__1cLxercesc_2_4JXMLReaderRrefreshCharBuffer6M_b_+0x270 libxerces-c.so.24.0:__1cLxercesc_2_4JReaderMgrMpeekNextChar6M_H_+0x24 libxerces-c.so.24.0:__1cLxercesc_2_4KXMLScannerKscanProlog6M_v_+0x74 libdstxxmlparser.so:__1cLxercesc_2_4OXMLScannerMscanDocument6Mrkn0ALInputSource__v_+0x78 libdstxxmlparser.so:__1cLxercesc_2_4NSAXParserFparse6Mrkn0ALInputSource__v_+0x6c Any patch available for 2.4 ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1351) MacOSX: Build Fails for libxerces-depmod.26.dylib
[ https://issues.apache.org/jira/browse/XERCESC-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1351. -- Resolution: Fixed Fix Version/s: 2.8.0 This works in 2.8.0 on OS X 10.4. Reopen the issue if it is still a problem. MacOSX: Build Fails for libxerces-depmod.26.dylib - Key: XERCESC-1351 URL: https://issues.apache.org/jira/browse/XERCESC-1351 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.6.0 Environment: MacOSX 10.3 (Panther) Reporter: Mitch Oliver Fix For: 2.8.0 After following the Mac OS X Command Line build instructions, the make tast for libxerces-depmod.26.dylib fails. It is unable to link against a number of object files (XMemory, XMLException, etc.). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1699) Link options wrong for hpux11.....
[
https://issues.apache.org/jira/browse/XERCESC-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1699.
Link options wrong for hpux11.
--
Key: XERCESC-1699
URL: https://issues.apache.org/jira/browse/XERCESC-1699
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 2.7.0
Environment: HPUX 11
Reporter: kappen
Fix For: 2.7.0
If you do change the flags according to:
LD_SONAME = -Wl,+h,${SO_NAME}
LD_SODEPDOM = -Wl,+h,${SO_DEPDOM}
You will not be able to move the file as all programs that link the file will
requere a specific path, this is subject to be added as the default flags.
There is no realy use of a so file if you can not move it from the build
directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1699) Link options wrong for hpux11.....
[
https://issues.apache.org/jira/browse/XERCESC-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov resolved XERCESC-1699.
--
Resolution: Invalid
Don't understand what the bug report is about. AFAIK, the options mentioned
make sure that only the library name (without the path) is used when linking
executables. Please reopen the bug report with a description of the step you
take and the problem you observe if you still believe there is a bug.
Link options wrong for hpux11.
--
Key: XERCESC-1699
URL: https://issues.apache.org/jira/browse/XERCESC-1699
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 2.7.0
Environment: HPUX 11
Reporter: kappen
Fix For: 2.7.0
If you do change the flags according to:
LD_SONAME = -Wl,+h,${SO_NAME}
LD_SODEPDOM = -Wl,+h,${SO_DEPDOM}
You will not be able to move the file as all programs that link the file will
requere a specific path, this is subject to be added as the default flags.
There is no realy use of a so file if you can not move it from the build
directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1608) Building Xerces-c on Mac OS X
[ https://issues.apache.org/jira/browse/XERCESC-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1608. Building Xerces-c on Mac OS X - Key: XERCESC-1608 URL: https://issues.apache.org/jira/browse/XERCESC-1608 Project: Xerces-C++ Issue Type: Test Components: Build Affects Versions: 2.6.0 Environment: Macintosh powerpc Mac OS X Darwin Kernel Version 8.6.0 Compilers- gcc and g++ Reporter: Ganesh Kumar Fix For: 2.8.0 I built xerces-c on Mac OS X using the compilers gcc and g++. I could build the libraries successfully. But when I tried to build the tests I got the following error: test -d /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/bin || mkdir /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/bin Building DOMMemTest make -C DOM/DOMMemTest mkdir -p /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/tests/DOM/DOMMemTest c++ -DMACOSX -L/usr/lib -L/usr/local/lib /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/tests/DOM/DOMMemTest/DOMMemTest.o -o /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/bin/DOMMemTest -L/Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/lib -lxerces-c /usr/bin/ld: warning -L: directory name (/usr/local/lib) does not exist /usr/bin/ld: Undefined symbols: typeinfo for xercesc_2_6::DOMException typeinfo for xercesc_2_6::XMLException collect2: ld returned 1 exit status make[1]: *** [/Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/bin/DOMMemTest] Error 1 make: *** [dommemtest] Error 2 Unless I build the tests and samples, I cannot be sure that I have built xerces-c successfully. Has anyone built xerces-c libraries as well as tests and samples successfully on Mac OS X Thanks Ganesh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1065) Problems with partial build
[ https://issues.apache.org/jira/browse/XERCESC-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1065. -- Resolution: Fixed Fix Version/s: 3.0.0 Assignee: (was: Xerces-C Developers Mailing List) I believe this is addressed with the move to autotools in 3.0.0. Problems with partial build --- Key: XERCESC-1065 URL: https://issues.apache.org/jira/browse/XERCESC-1065 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: Nightly build (please specify the date) Environment: Operating System: All Platform: All Reporter: Jeroen N. Witmond Fix For: 3.0.0 I am working with / on the CVS version of Xerces. A full build (after `cvs checkout`, after `gmake distclean` or after `gmake clean`) works as expected. However, after changing files (either manually or as a result of `cvs update`, gmake does not build Xerces correctly. So far, I have seen the following problems: 1. gmake does not compile anything after changing src/xercesc/util/XMLUri.h. This file is included by 7 files in Xerces itself. 2. Makefile not recreated when Makefile.in changes. One result is that new header files are not copied into the include directory, therefore the compiler cannot find them. I am willing to make a fix for this kind of build errors, but I need some guidance on what kind of fix will be acceptable. There probably are many options, but I think they can be summarized as: 1. Update all Makefile.in files to contain all dependencies. 2. Automate the generation of the dependencies, for instance with automake. I can be contacted via the development mailing list or by direct email. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1712) Russian Locale ru_RU.iso88595 document parsing has a problem
[ https://issues.apache.org/jira/browse/XERCESC-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1712. -- Resolution: Fixed Fix Version/s: (was: 2.6.0) 2.8.0 I've tested both 2.8.0 and trunk (3.0.0) versions built with ICU and they both parse the attached test case without any problems. Russian Locale ru_RU.iso88595 document parsing has a problem - Key: XERCESC-1712 URL: https://issues.apache.org/jira/browse/XERCESC-1712 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2 Affects Versions: 2.6.0 Environment: HPUX 11i , local = ru_RU.iso88595, Xereces C++ Reporter: Ajay Kumar Fix For: 2.8.0 Attachments: objstr_system.xml Hello Developers, I work for BMC software and here is one bug we are experiencing with Russian locale on HPUX (11i). We are using 32 bit XML C++ parser version 2.6 for parsing the document. I am attaching the document. The Russian locale I have used is LANG=ru_RU.iso88595 LC_ALL=ru_RU.iso88595 Here is the stack trace where the error occurs. Some more info just to show that it is completely in the xerex parser (gdb) up #1 0xc7f80a6c in xercesc_2_6::SAX2XMLReaderImpl::error () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 -Error while scanning. (gdb) up #2 0xc80145e8 in xercesc_2_6::XMLScanner::emitError () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 (gdb) up #3 0xc80156e0 in xercesc_2_6::XMLScanner::scanProlog () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 (gdb) up #4 0xc7f3f60c in xercesc_2_6::IGXMLScanner::scanDocument () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 (gdb) up #5 0xc7f7db50 in xercesc_2_6::SAX2XMLReaderImpl::parse () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 (gdb) up #6 0x00682f88 in ParseXMLDocument (parserHandle=0x7a789094, xmlInputDoc=0x7a7890a8, objectsToParse=0x7a785344, parsedStream=0x7a789098, -à Got the doc parsedObjects=0x7a7890b0, appBlockNameList=0x0, status=0x7a786d54) at arxml.cpp:869 869 arxml.cpp: No such file or directory. in arxml.cpp My question here is, if this is documented/known bug we are encountering which is fixed in 2.7? Or we may be missing something while configuring xml parser for Russian locale on HPUX? Or it is a user error in the given the document? Or you need some more information from my side for this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1351) MacOSX: Build Fails for libxerces-depmod.26.dylib
[ https://issues.apache.org/jira/browse/XERCESC-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1351. MacOSX: Build Fails for libxerces-depmod.26.dylib - Key: XERCESC-1351 URL: https://issues.apache.org/jira/browse/XERCESC-1351 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.6.0 Environment: MacOSX 10.3 (Panther) Reporter: Mitch Oliver Fix For: 2.8.0 After following the Mac OS X Command Line build instructions, the make tast for libxerces-depmod.26.dylib fails. It is unable to link against a number of object files (XMemory, XMLException, etc.). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1742) Xerces can not check the xs namespace elements when doing validation
[
https://issues.apache.org/jira/browse/XERCESC-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1742:
-
Fix Version/s: (was: 2.7.0)
Xerces can not check the xs namespace elements when doing validation
--
Key: XERCESC-1742
URL: https://issues.apache.org/jira/browse/XERCESC-1742
Project: Xerces-C++
Issue Type: Bug
Affects Versions: 2.7.0
Environment: Solaris 10
Reporter: PeiHua
I use Xerices c++ 2.7.0 to validate xml.But I found it can not check the xs
element itself.
void XercesParser::doValidation(const char *theStr, bool setDefaultValue,
bool ignoreError)
{
REPORT_INFO([XercesParser] doValidation);
// create parser if it is not available
if (myParser == NULL)
{
myParser = XMLReaderFactory::createXMLReader();
myParser-setFeature(XMLUni::fgSAX2CoreValidation, true);
myParser-setFeature(XMLUni::fgSAX2CoreNameSpaces, true);
myParser-setFeature(XMLUni::fgXercesSchema, true);
myParser-setFeature(XMLUni::fgXercesDynamic, true);
myParser-setFeature(XMLUni::fgXercesSchemaFullChecking, true);
myParser-setFeature(XMLUni::fgSAX2CoreNameSpacePrefixes, true);
myParser-setFeature(XMLUni::fgXercesCacheGrammarFromParse, true);
myParser-setFeature(XMLUni::fgXercesUseCachedGrammarInParse, true);
mySchema = XMLString::transcode(mySchemaLoc.data());
myParser-setProperty(XMLUni::fgXercesSchemaExternalSchemaLocation,
mySchema);
}
REPORT_INFO(doValidation, mySchemaLoc: mySchemaLoc);
REPORT_INFO(doValidation, theStr: theStr);
if(setDefaultValue)
myParser-setContentHandler(myHandler);
else
myParser-setContentHandler(NULL);
if(!ignoreError)
myParser-setErrorHandler(myHandler);
else
myParser-setErrorHandler(NULL);
try
{
// added for supporting file parsing
RWURL url(theStr);
if (url.isValid() == false)
{
int len = strlen(theStr);
const char *bufId = ABC;
// the buffer must be allocated dynamically
MemBufInputSource theMBIS(reinterpret_castconst
XMLByte*(theStr), (const unsigned int)len, bufId);
myParser-parse(theMBIS);
}
else
myParser-parse(theStr);
}
{
// handle request format error
throw e;
}
catch (...)
{
// handle other errors
XMLString::release(mySchema);
// the parser must be released here
delete myParser;
myParser = NULL;
throw FDSException::FDSStandardException(doValidation, An error
occurred during parsing., 0);
}
}
void XercesParser::doValidation(const FDSNamedValue theNV, bool
setDefaultValue, bool ignoreError)
{
REPORT_INFO([XercesParser] doValidation);
ostrstream tmpStr;
theNV.print(tmpStr, 0);
tmpStr.put('\0');
char *tmpStr1 = tmpStr.str();
RWCString tmpStr2(tmpStr1);
delete[] tmpStr1;
doValidation(tmpStr2.data(), setDefaultValue, ignoreError);
}
And Invoke the functions before.
---
const RWCString schemaLoc = http://www.xxx.com/CommPilotExpress/
/home/ehuapei/tools/validation
/bin/test.xsd;
.
// get parser object
XercesParser* theParser = theObj-getObj();
// do validation
try
{
theParser-doValidation(*theNV);
}
catch (FDSException::FDSStandardException e)
{
// release cached object
ObjectPool::getInstance()-releaseObject(theObj);
cout [testMain] Error: e.information() endl;
cout [testMain] Reason: e.reason() endl;
}
schema and xml below.
?xml version=1.0 encoding=UTF-8?^M
xs:schema xmlns:base=ht
tp://www.xxx.com/base/ xmlns=http://www.xxx.com/CommPilotExpress/;
xmlns:xs=http:
//www.w3.org/2001/XMLSchema
targetNamespace=http://www.xxx.com/CommPilotExpress/; elementFormDe
fault=qualified attributeFormDefault=qualified^M
^M
xs:element name=setService^M
xs:annotation^M
xs:documentationTarget
CommPilotExpress/xs:documentation^M
/xs:annotation^M
xs:complexType^M
xs:sequence^M
xs:element name=serviceSpecificData^M
xs:complexType^M
xs:sequence^M
[jira] Closed: (XERCESC-1712) Russian Locale ru_RU.iso88595 document parsing has a problem
[ https://issues.apache.org/jira/browse/XERCESC-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1712. Russian Locale ru_RU.iso88595 document parsing has a problem - Key: XERCESC-1712 URL: https://issues.apache.org/jira/browse/XERCESC-1712 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2 Affects Versions: 2.6.0 Environment: HPUX 11i , local = ru_RU.iso88595, Xereces C++ Reporter: Ajay Kumar Fix For: 2.8.0 Attachments: objstr_system.xml Hello Developers, I work for BMC software and here is one bug we are experiencing with Russian locale on HPUX (11i). We are using 32 bit XML C++ parser version 2.6 for parsing the document. I am attaching the document. The Russian locale I have used is LANG=ru_RU.iso88595 LC_ALL=ru_RU.iso88595 Here is the stack trace where the error occurs. Some more info just to show that it is completely in the xerex parser (gdb) up #1 0xc7f80a6c in xercesc_2_6::SAX2XMLReaderImpl::error () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 -Error while scanning. (gdb) up #2 0xc80145e8 in xercesc_2_6::XMLScanner::emitError () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 (gdb) up #3 0xc80156e0 in xercesc_2_6::XMLScanner::scanProlog () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 (gdb) up #4 0xc7f3f60c in xercesc_2_6::IGXMLScanner::scanDocument () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 (gdb) up #5 0xc7f7db50 in xercesc_2_6::SAX2XMLReaderImpl::parse () from /usr/ar/headsup/bin/libxerces-cbmc.sl.26 (gdb) up #6 0x00682f88 in ParseXMLDocument (parserHandle=0x7a789094, xmlInputDoc=0x7a7890a8, objectsToParse=0x7a785344, parsedStream=0x7a789098, -à Got the doc parsedObjects=0x7a7890b0, appBlockNameList=0x0, status=0x7a786d54) at arxml.cpp:869 869 arxml.cpp: No such file or directory. in arxml.cpp My question here is, if this is documented/known bug we are encountering which is fixed in 2.7? Or we may be missing something while configuring xml parser for Russian locale on HPUX? Or it is a user error in the given the document? Or you need some more information from my side for this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1608) Building Xerces-c on Mac OS X
[ https://issues.apache.org/jira/browse/XERCESC-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1608. -- Resolution: Fixed Fix Version/s: 2.8.0 Building Xerces-c on Mac OS X - Key: XERCESC-1608 URL: https://issues.apache.org/jira/browse/XERCESC-1608 Project: Xerces-C++ Issue Type: Test Components: Build Affects Versions: 2.6.0 Environment: Macintosh powerpc Mac OS X Darwin Kernel Version 8.6.0 Compilers- gcc and g++ Reporter: Ganesh Kumar Fix For: 2.8.0 I built xerces-c on Mac OS X using the compilers gcc and g++. I could build the libraries successfully. But when I tried to build the tests I got the following error: test -d /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/bin || mkdir /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/bin Building DOMMemTest make -C DOM/DOMMemTest mkdir -p /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/tests/DOM/DOMMemTest c++ -DMACOSX -L/usr/lib -L/usr/local/lib /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/tests/DOM/DOMMemTest/DOMMemTest.o -o /Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/bin/DOMMemTest -L/Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/lib -lxerces-c /usr/bin/ld: warning -L: directory name (/usr/local/lib) does not exist /usr/bin/ld: Undefined symbols: typeinfo for xercesc_2_6::DOMException typeinfo for xercesc_2_6::XMLException collect2: ld returned 1 exit status make[1]: *** [/Users/tsbld/TechStackBuild/Components/xerces-c-2.6.0-WithoutICU/temp/xerces-c-src_2_6_0/bin/DOMMemTest] Error 1 make: *** [dommemtest] Error 2 Unless I build the tests and samples, I cannot be sure that I have built xerces-c successfully. Has anyone built xerces-c libraries as well as tests and samples successfully on Mac OS X Thanks Ganesh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1678) PSVIAttributeList::getPSVIAttributeToFill not const correct
[ https://issues.apache.org/jira/browse/XERCESC-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1678: - Affects Version/s: (was: 2.7.0) 2.9.0 3.0.0 Would be good to fix for 3.0.0, 2.9.0. PSVIAttributeList::getPSVIAttributeToFill not const correct --- Key: XERCESC-1678 URL: https://issues.apache.org/jira/browse/XERCESC-1678 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 2.7.0 Environment: MacOSX, Linux GCC 4.1 Reporter: kent williams Priority: Minor Fix For: 3.0.0, 2.9.0 I get warnings in this inline method (getPSVIAttributeToFill) about casts from const XMLCh * to XMLCh *. For example: Line 185, PSVIAttributeList.hpp : rAttrNameList-addElement((XMLCh *)attrName); The real problem is that the addElement method takes a non-const XMLCh *, so getPSVIAttributeToFill has to cast its const argument to non-const or this would be compiler error. I don't know if anyone is committed to fixing up const-correctness in Xerces-C++ -- if it wasn't written in a const-paranoid manner, this would be a pretty large job. But at a minimum, using const_castXMLCh *() instead of C-style casting would shut GCC4 up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1672) DOMPrint Gives following Error Fatal Error at file , line 0, char 0 Message: An exception occurred! Type:RuntimeException, Message:The primary document entity could no
[ https://issues.apache.org/jira/browse/XERCESC-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov resolved XERCESC-1672. -- Resolution: Invalid Looks like a toolchain problem. DOMPrint Gives following Error Fatal Error at file , line 0, char 0 Message: An exception occurred! Type:RuntimeException, Message:The primary document entity could not be opened. Id=. We are using IBM XML Toolkit V1.6. -- Key: XERCESC-1672 URL: https://issues.apache.org/jira/browse/XERCESC-1672 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 1.6.0 Environment: ZOS [ OS/390 TCSMVSY 17.00 03 2064 ( this seems to be 64 bit machine ).] Reporter: Makarand M Kulkarni Fix For: 1.6.0 Error in DOMPrint on ZOS machine using IBM XML Toolkit V1.6 : -- DOMPrint Gives following Error Fatal Error at file , line 0, char 0 Message: An exception occurred! Type:RuntimeException, Message:The primary document entity could not be opened. Id=. We are using IBM XML Toolkit V1.6. I was able to run Same DOMPrint program and other executable created out of CPP program some time before. Recently we have upgraded the ZOS machine to V 1.7. Current configuartion of the machine as follows OS/390 TCSMVSY 17.00 03 2064 ( this seems to be 64 bit machine ). Needs urgent help on this. Any suggestion is highly appreciated. Any issues because of upgradation ? OR DO I need to install new XML toolkit version for ZOS 1.7 machine. Waiting for the reply. -Regards Makarand -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1670) Problem building on HP-UX 11.23
[
https://issues.apache.org/jira/browse/XERCESC-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1670.
Problem building on HP-UX 11.23
---
Key: XERCESC-1670
URL: https://issues.apache.org/jira/browse/XERCESC-1670
Project: Xerces-C++
Issue Type: Bug
Components: Build
Affects Versions: 2.7.0
Environment: HP-UX 11.23 on Itanium
Compiler: aCC rev. C.11.23.09
Reporter: Botho Hohbaum
Priority: Blocker
I configured using the following command:
./runConfigure -p hp-11 -c /opt/aCC/bin/aCC -x /opt/aCC/bin/aCC
Afterwards, to make a successful build, i had to do these changes:
Makefile.incl:
remove +a1 and +DAportable from line 519
remove -ptr${TEMPLATESREPOSITORY} from line 523
These parameters are unknown to the compiler.
RangeTokenMap.cpp:
add #include xercesc/util/Janitor.hpp in line 38
XMLAttDef.cpp:
add #include xercesc/util/Janitor.hpp in line 29
XMLEntityDecl.cpp:
add #include xercesc/util/Janitor.hpp in line 28
XMLNotationDecl.cpp:
add #include xercesc/util/Janitor.hpp in line 27
XSAttributeGroupDefinition.cpp:
add #include xercesc/util/StringPool.hpp in line 25
XSModelGroupDefinition.cpp:
add #include xercesc/util/StringPool.hpp in line 25
XSNamespaceItem.hpp:
add #include xercesc/util/RefHashTableOf.hpp in line 27
XSNotationDeclaration.cpp:
add #include xercesc/util/StringPool.hpp in line 25
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1672) DOMPrint Gives following Error Fatal Error at file , line 0, char 0 Message: An exception occurred! Type:RuntimeException, Message:The primary document entity could not
[ https://issues.apache.org/jira/browse/XERCESC-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1672. DOMPrint Gives following Error Fatal Error at file , line 0, char 0 Message: An exception occurred! Type:RuntimeException, Message:The primary document entity could not be opened. Id=. We are using IBM XML Toolkit V1.6. -- Key: XERCESC-1672 URL: https://issues.apache.org/jira/browse/XERCESC-1672 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 1.6.0 Environment: ZOS [ OS/390 TCSMVSY 17.00 03 2064 ( this seems to be 64 bit machine ).] Reporter: Makarand M Kulkarni Fix For: 1.6.0 Error in DOMPrint on ZOS machine using IBM XML Toolkit V1.6 : -- DOMPrint Gives following Error Fatal Error at file , line 0, char 0 Message: An exception occurred! Type:RuntimeException, Message:The primary document entity could not be opened. Id=. We are using IBM XML Toolkit V1.6. I was able to run Same DOMPrint program and other executable created out of CPP program some time before. Recently we have upgraded the ZOS machine to V 1.7. Current configuartion of the machine as follows OS/390 TCSMVSY 17.00 03 2064 ( this seems to be 64 bit machine ). Needs urgent help on this. Any suggestion is highly appreciated. Any issues because of upgradation ? OR DO I need to install new XML toolkit version for ZOS 1.7 machine. Waiting for the reply. -Regards Makarand -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1332) 64-bit Windows build failures
[
https://issues.apache.org/jira/browse/XERCESC-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1332.
64-bit Windows build failures
-
Key: XERCESC-1332
URL: https://issues.apache.org/jira/browse/XERCESC-1332
Project: Xerces-C++
Issue Type: Bug
Components: Samples/Tests
Affects Versions: 2.6.0
Environment: Windows XP a64, Visual Studio 2005 Beta
Reporter: Robert Buck
Fix For: 2.8.0
Issue: Coding error; longs are not 64-bits on 64-bit Windows.
[1]
SimpleHashPtr.cpp
..\..\..\..\..\tests\MemHandlerTest\SimpleHashPtr.cpp(32) : error C2440:
'type cast' : cannot convert from 'const void *const ' to 'long'
The target is not large enough
unsigned int SimpleHashPtr::getHashVal(const void *const key, unsigned int
mod)
{
return ((long)key % (unsigned long)mod);
}
[2]
PSVIWriterHandlers.cpp
..\..\..\..\..\samples\PSVIWriter\PSVIWriterHandlers.cpp(1618) : error C2440:
'type cast' : cannot convert from 'xercesc_2_6::XSObject *' to 'unsigned long'
The target is not large enough
XMLString::binToText((unsigned long)obj, objLoc, 8, 16);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1772) MacOS 64 bit Support for xerces-2
[ https://issues.apache.org/jira/browse/XERCESC-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1772: - Fix Version/s: (was: 2.8.0) 2.9.0 3.0.0 Should any of these fixes also go into 3.0.0 or is everything fixed there already? MacOS 64 bit Support for xerces-2 - Key: XERCESC-1772 URL: https://issues.apache.org/jira/browse/XERCESC-1772 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.8.0 Environment: MacOS 64 bit Reporter: cargilld Fix For: 3.0.0, 2.9.0 Attachments: macsvn.diff The MacOS code in the Xerces-2 branch was not building in 64 bits. Attaching patch of source changes I made to specific MacOS files to get it to work. I would commit them directly but thought it would be best if someone review them first. Changes are pretty much a result of pulling fixes from the xerces-c trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1332) 64-bit Windows build failures
[
https://issues.apache.org/jira/browse/XERCESC-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov resolved XERCESC-1332.
--
Resolution: Fixed
Fix Version/s: 2.8.0
64-bit Windows build failures
-
Key: XERCESC-1332
URL: https://issues.apache.org/jira/browse/XERCESC-1332
Project: Xerces-C++
Issue Type: Bug
Components: Samples/Tests
Affects Versions: 2.6.0
Environment: Windows XP a64, Visual Studio 2005 Beta
Reporter: Robert Buck
Fix For: 2.8.0
Issue: Coding error; longs are not 64-bits on 64-bit Windows.
[1]
SimpleHashPtr.cpp
..\..\..\..\..\tests\MemHandlerTest\SimpleHashPtr.cpp(32) : error C2440:
'type cast' : cannot convert from 'const void *const ' to 'long'
The target is not large enough
unsigned int SimpleHashPtr::getHashVal(const void *const key, unsigned int
mod)
{
return ((long)key % (unsigned long)mod);
}
[2]
PSVIWriterHandlers.cpp
..\..\..\..\..\samples\PSVIWriter\PSVIWriterHandlers.cpp(1618) : error C2440:
'type cast' : cannot convert from 'xercesc_2_6::XSObject *' to 'unsigned long'
The target is not large enough
XMLString::binToText((unsigned long)obj, objLoc, 8, 16);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1524) Xerces fails to validate a valid XML document when the schema contains forward references to element-types in certain circumstances.
[
https://issues.apache.org/jira/browse/XERCESC-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1524.
Xerces fails to validate a valid XML document when the schema contains
forward references to element-types in certain circumstances.
--
Key: XERCESC-1524
URL: https://issues.apache.org/jira/browse/XERCESC-1524
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (Schema) (Xerces 1.5 or up only)
Affects Versions: 2.7.0
Environment: msvc6 / win2k
Reporter: Alain Le Guennec
Fix For: 2.8.0
Attachments: BugValidationSchema.xml, BugValidationSchema.xsd
When running sax2print BugValidationSchema.xml (xml file attached), I get
the following error:
Message: Attribute 'attr2' is not declared for element 'Level4'
The schema (also attached) simply contains 4 element/element-types
declarations
('Level1', 'Level2', 'Level3' and 'Level4', forming an extension chain).
Attribute 'attr2' is declared within 'Level2', and so should be legal within
Level4 too.
'Level2' also contains a sub-element declaration of type 'Level4'.
It turns out that commenting out that sub-element declaration renders the xml
file valid.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
