[jira] Closed: (XERCESC-1898) LocalFileFormatTarget dtor may throw an exception
[ https://issues.apache.org/jira/browse/XERCESC-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1898. Resolution: Fixed The fix is in SVN. LocalFileFormatTarget dtor may throw an exception - Key: XERCESC-1898 URL: https://issues.apache.org/jira/browse/XERCESC-1898 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.0.0, 3.0.1 Reporter: peter Assignee: Boris Kolpackov Fix For: 3.1.0 The destructor of LocalFileFormatTarget is calling flushBuffer() which in turn may throw exceptions. Throwing exceptions in dtor however is dangerous since it may lead to program termination if the exception is thrown during stack unwind. Example: DOMLSSerializer::writeToURI() is causing imediate program termination if there is no space left on disk. The reason is an exception thrown in DOMLSSerializer::write(). During stack unwind the dtor of LocalFileFormatTarget is called throwing another exception which is illegal and leads to program termination. Example stacktrace from real world application: msvcr90d.dll!__NMSG_WRITE() + 0x75 Bytes msvcr90d.dll!_abort() + 0x2d Bytes msvcr90d.dll!terminate() + 0x6e Bytes msvcr90d.dll!___FrameUnwindFilter() + 0x40 Bytes msvcr90d.dll!___FrameUnwindToState() + 0x106 Bytes msvcr90d.d...@_eh4_callfilterfunc@8() + 0x12 Bytes ntdll.dll!executehandl...@20() + 0x26 Bytes ntdll.dll!executehand...@20() + 0x24 Bytes ntdll.dll!_kiuserexceptiondispatc...@8() + 0xf Bytes kernel32.dll!_raiseexcept...@16() + 0x59 Bytes msvcr90d.dll!__cxxthrowexcept...@8() + 0x52 Bytes xerces-c_3_0D.dll!xercesc_3_0::WindowsFileMgr::fileWrite(void * f=0x0900, unsigned long byteCount=1022, const unsigned char * buffer=0x115e5d18, xercesc_3_0::MemoryManager * const manager=0x0498f758) Zeile 314C++ xerces-c_3_0D.dll!xercesc_3_0::XMLPlatformUtils::writeBufferToFile(void * const theFile=0x0900, unsigned long toWrite=1022, const unsigned char * const toFlush=0x115e5d18, xercesc_3_0::MemoryManager * const memmgr=0x0498f758) Zeile 608C++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::flushBuffer() Zeile 120 + 0x21 BytesC++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::~LocalFileFormatTarget() Zeile 83C++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::`vector deleting destructor'() + 0x4d BytesC++ xerces-c_3_0D.dll!xercesc_3_0::Janitorxercesc_3_0::XMLFormatTarget::reset(xercesc_3_0::XMLFormatTarget * p=0x) Zeile 90 + 0x22 BytesC++ xerces-c_3_0D.dll!xercesc_3_0::Janitorxercesc_3_0::XMLFormatTarget::~Janitorxercesc_3_0::XMLFormatTarget() Zeile 44C++ msvcr90d.dll!__callsettingfr...@12() + 0x26 Bytes msvcr90d.dll!___FrameUnwindToState() + 0xf4 Bytes msvcr90d.dll!___InternalCxxFrameHandler() + 0x7f Bytes msvcr90d.dll!___CxxFrameHandler3() + 0x2c Bytes ntdll.dll!executehandl...@20() + 0x26 Bytes ntdll.dll!executehand...@20() + 0x24 Bytes msvcr90d.dll!_UnwindNestedFrames() + 0x2f Bytes msvcr90d.dll!___FrameUnwindToState() + 0x1cf Bytes msvcr90d.dll!___InternalCxxFrameHandler() + 0x48a Bytes msvcr90d.dll!___InternalCxxFrameHandler() + 0x147 Bytes msvcr90d.dll!___CxxFrameHandler3() + 0x2c Bytes ntdll.dll!executehandl...@20() + 0x26 Bytes ntdll.dll!executehand...@20() + 0x24 Bytes ntdll.dll!_kiuserexceptiondispatc...@8() + 0xf Bytes kernel32.dll!_raiseexcept...@16() + 0x59 Bytes msvcr90d.dll!__cxxthrowexcept...@8() + 0x52 Bytes xerces-c_3_0D.dll!xercesc_3_0::WindowsFileMgr::fileWrite(void * f=0x0900, unsigned long byteCount=1022, const unsigned char * buffer=0x115e5d18, xercesc_3_0::MemoryManager * const manager=0x0498f758) Zeile 314C++ xerces-c_3_0D.dll!xercesc_3_0::XMLPlatformUtils::writeBufferToFile(void * const theFile=0x0900, unsigned long toWrite=1022, const unsigned char * const toFlush=0x115e5d18, xercesc_3_0::MemoryManager * const memmgr=0x0498f758) Zeile 608C++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::flushBuffer() Zeile 120 + 0x21 BytesC++ xerces-c_3_0D.dll!xercesc_3_0::LocalFileFormatTarget::flush() Zeile 92 C++ xerces-c_3_0D.dll!xercesc_3_0::DOMLSSerializerImpl::write(const xercesc_3_0::DOMNode * nodeToWrite=0x11776040, xercesc_3_0::DOMLSOutput * const destination=0x1909f76c) Zeile 542C++ xerces-c_3_0D.dll!xercesc_3_0::DOMLSSerializerImpl::writeToURI(const xercesc_3_0::DOMNode * nodeToWrite=0x11776040, const
[jira] Closed: (XERCESC-1337) DOMMemTest fails with Segmentation violation(xserces1.7 + ICU transcode + windows2000)
[ https://issues.apache.org/jira/browse/XERCESC-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1337. Resolution: Fixed Fix Version/s: 3.0.1 Assuming fixed in the latest release. DOMMemTest fails with Segmentation violation(xserces1.7 + ICU transcode + windows2000) Key: XERCESC-1337 URL: https://issues.apache.org/jira/browse/XERCESC-1337 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 1.7.0 Environment: windows2000 + xseces 1.7 Reporter: Leon Zhang Priority: Critical Fix For: 3.0.1 Attachments: DOMMemTest.cpp When I run DOMMemTest testcase after build xerces with ICU trascode option, DOMMemTest always fails with Segmentation violation. I am not sure this is a DOMString bug or ICUTransService.cpp bug. But it seesm that this is not a DOMString bug, since after build serces with WIN32 transcode. It seems that xseces 2.5 have the same bug, so other guys have to build xerces with WIN32 transcode. I need your help. (You some products are embeded in xerces). Thanks a lot! -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1205) primary document entity could not be opened - on Win98
[
https://issues.apache.org/jira/browse/XERCESC-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1205.
Resolution: Fixed
Fix Version/s: 3.0.1
Win98 is no longer supported.
primary document entity could not be opened - on Win98
--
Key: XERCESC-1205
URL: https://issues.apache.org/jira/browse/XERCESC-1205
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 2.1.0, 2.4.0, 2.5.0
Environment: Together with Xalan. I have had the bug on Win98 (1st
and 2nd edition). Reading the code I think Win95 and WinME may have the same
problem.
Reporter: Florian Nowotny
Fix For: 3.0.1
When I use an unc path as the input parameter of the constructor of Xalan's
XSLTInputSource( const char* )
on Win98 systems Xerces raises the error:
The primary document entitiy could not be opened.
Id=\\server\shared\..path-to-xml-file
I traced through Xerces' code an found that
- the constructor of Xerces' InputSource( const XMLCh* const SystemId,
MemoryManager*) is called internally and the systemId is
file:/server/shared/...
- later in Win32PlatformUtils.cpp the Windows API method CreateFileA is
called and tmpName is //server/shared/...
BUT: CreateFileA can't open an UNC-Path with forward slashes on both
Win98-PCs that I have tested (Win98 1st and 2nd Edition).
It's unfriendly that the error message reports the file-to-open-path with
back slashes?
I fixed the problem by patching
xerces/src/xercesc/util/Platforms/Win32/Win32PlatformUtils.cpp (Xerces
version 2.5.0) in method
openFile(const XMLCh* const fileName, MemoryManager* const manager).
Here is my code beginning with line 326:
else
{
//
// We are Win 95 / 98. Take the Unicode file name back to (char *)
//so that we can open it.
//
char* tmpName = XMLString::transcode(nameToOpen, manager);
//
// Bugfix:
// I'm replacing all forward slashes with backward slashes
//
int len = strlen(tmpName);
for ( int i = 0; i len; ++i )
{
if ( tmpName[i] == '/' )
tmpName[i] = '\\';
}
retVal = ::CreateFileA
(
tmpName
, GENERIC_READ
, FILE_SHARE_READ
, 0
, OPEN_EXISTING
, FILE_FLAG_SEQUENTIAL_SCAN
, 0
);
manager-deallocate(tmpName);//delete [] tmpName;
}
--
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: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1127) ABW: Array bounds write xercesc_2_4::HashBase::HashBase #Nvariant 1() [XMLString.hpp:1612]
[ https://issues.apache.org/jira/browse/XERCESC-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1127. Resolution: Fixed Fix Version/s: 3.0.1 Assignee: (was: Xerces-C Developers Mailing List) The latest releases has been checked extensively with valgrind so I assume this has been fixed. ABW: Array bounds write xercesc_2_4::HashBase::HashBase #Nvariant 1() [XMLString.hpp:1612] -- Key: XERCESC-1127 URL: https://issues.apache.org/jira/browse/XERCESC-1127 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.4.0 Environment: Operating System: Solaris Platform: Other Reporter: Greg Franks Fix For: 3.0.1 Attachments: bugzilla This error is popping up during object allocation. It may be that the xerces memory allocation is confusing purify, in which case, this is a non problem. The stack trace is attached. ABWArray bounds write CORRUPTING An ABW message indicates that your program is about to write a value to before the beginning or after the end of an allo- cated block. Common causes include: o making an array too small (e.g. failing to account for the terminating NULL in a string); o forgetting to multiply by sizeof(type) when allocating for an array of objects; o using an array index too large or negative; o failing to NULL terminate a string; or o being off-by-one in copying elements up or down an array. -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1105) transcode function on AIX returns incorrect value
[
https://issues.apache.org/jira/browse/XERCESC-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1105.
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
No reply from the reporter. Assuming invalid.
transcode function on AIX returns incorrect value
-
Key: XERCESC-1105
URL: https://issues.apache.org/jira/browse/XERCESC-1105
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 2.2.0
Environment: Operating System: AIX
Platform: Other
Reporter: Karen Bradshaw
XMLString::transcode always returns 1 regardless of the provided buffer size.
// const char * str;
// XMLCh * buffer;
// size_t buffer_size;
if(XMLString::transcode(str, buffer, buffer_size - 4))
{
return buffer;
}
--
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: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-777) XMLPlatformUtils::Initialize() fails to execute any code when called from an shared object
[
https://issues.apache.org/jira/browse/XERCESC-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-777.
---
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
I am pretty sure this is a compiler issue.
XMLPlatformUtils::Initialize() fails to execute any code when called from an
shared object
--
Key: XERCESC-777
URL: https://issues.apache.org/jira/browse/XERCESC-777
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 2.1.0
Environment: Operating System: Solaris
Platform: Sun
Reporter: mstorrs
I have compiled Xerces2.1 (stable) on Solaris 2.8 using g++ 2.95.3. The
samples execute properly. I am linking the xerces.so to another shared
object
I am creating. This shared object is loaded by an application at run time,
when I call XMLPlatformUtils::Initialize() from the shared object the code
executes the call, but never actually performs any code within that function
-
I know this because I have editted the Initialize() function and outputed a
debug statement to a file (this works successfully during execution of one of
the samples). After Initialize returns, the code continues and then once the
code tries to execute getDOMImplementation(), the shared object core dumps,
because the global mutex lock is null, since the new XMLMutex statement is
never executed within Initialize(). I placed debug statements in this Xerces
code as well, and know that the function executes, and crashes once the code
tries to lock to set the cleanupfunction.
Is there any reason that Initialize wouldn't execute the code?? I have
attached the shared object code as well as the Makefile. I also tried with
c++, and that failed the exact same way.
Here is the shared object code:
extern C unsigned int OBLIX_DLLEXPORT Crap(const char *eventName, ObPPPData
*data)
{
int iStatus = STATUS_PPP_OK;// Return code
AbstractDOMParser::ValSchemes valScheme = AbstractDOMParser::Val_Auto;
bool doNamespaces = false;
bool doSchema = false;
bool schemaFullChecking = false;
bool errorOccurred = false;
try
{
FILE *fp = fopen(/opt/netpoint/custom/xerces.txt, w);
fprintf(fp, Before Initialize\n);
fclose(fp);
XMLPlatformUtils::Initialize();
fp = fopen(/opt/netpoint/custom/xerces.txt, a);
fprintf(fp, After Initialize\n);
fclose(fp);
}
catch (const XMLException toCatch)
{
data-SetResultString(NonInternalUser: XML Exception occured);
return STATUS_PPP_ABORT;
}
catch (...)
{
data-SetResultString(S Happens);
return STATUS_PPP_ABORT;
}
try
{
// Instantiate the DOM parser.
static const XMLCh gLS[] = { chLatin_L, chLatin_S, chNull };
DOMImplementation *impl =
DOMImplementationRegistry::getDOMImplementation(gLS);
DOMBuilder*parser = ((DOMImplementationLS*)impl)-
createDOMBuilder(DOMImplementationLS:
:MODE_SYNCHRONOUS, 0);
parser-setFeature(XMLUni::fgDOMNamespaces, doNamespaces);
parser-setFeature(XMLUni::fgXercesSchema, doSchema);
parser-setFeature(XMLUni::fgXercesSchemaFullChecking,
schemaFullChecking);
if (valScheme == AbstractDOMParser::Val_Auto)
{
parser-setFeature(XMLUni::fgDOMValidateIfSchema, true);
}
else if (valScheme == AbstractDOMParser::Val_Never)
{
parser-setFeature(XMLUni::fgDOMValidation, false);
}
else if (valScheme == AbstractDOMParser::Val_Always)
{
parser-setFeature(XMLUni::fgDOMValidation, true);
etc.
Makefile
--
CC = g++
SHARED_LIB_EXT = so
CFLAGS = -c -DSOLARIS -D_REENTRANT -fpic -Wall -g -O2 -I.
-I/usr/local/include -
I/opt/netpoint/identity
/oblix/include/ppp -I/opt/netpoint/custom/xerces-c-src2_1_0/include -
I/opt/netpoint/custom/ldap/include
LOADFLAG = -DSOLARIS -fpic -mt -shared -L/usr/lib -L/usr/local/lib -
L/opt/netpoint/custom/ldap/lib -L/o
pt/netpoint/custom/xerces-c-src2_1_0/lib -lxerces-c -lldap50 -lpthread
all : fed.$(SHARED_LIB_EXT)
fed.$(SHARED_LIB_EXT) : common.o FedHandler.o InternalUser.o
NonInternalUser.o
IntUserToServices.o test
.o
$(CC) $(LOADFLAG) -o $@ common.o FedHandler.o InternalUser.o
NonInternalUser.o IntUserToServices.o
test.o
common.o : common.cpp
$(CC) $(CFLAGS) common.cpp -o $@
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (XERCESC-501) Xerces hangs in ThrowXML
[
https://issues.apache.org/jira/browse/XERCESC-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-501.
---
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
Can you try to reproduce this problem with the latest release? If it is still
there, can you reopen this bug and provide a test case?
Xerces hangs in ThrowXML
Key: XERCESC-501
URL: https://issues.apache.org/jira/browse/XERCESC-501
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 1.7.0
Environment: Operating System: Windows NT/2K
Platform: PC
Reporter: Mikael Widenfalk
I have several threads (CWinThread) that use Xerces. Sooner or later one
specific thread gets stuck in ThrowXML. The exact point varies depending on
what
I send in systemID. This is one example:
void XMLURL::setURL(const XMLCh* constbaseURL
, const XMLCh* constrelativeURL)
{
cleanup();
// Parse our URL string
parse(relativeURL);
//
// If its relative and the base is non-null and non-empty, then
// parse the base URL string and conglomerate them.
//
if (isRelative() baseURL)
{
if (*baseURL)
{
XMLURL basePart(baseURL);
if (!conglomerateWithBase(basePart, false))
{
cleanup();
ThrowXML(MalformedURLException,
XMLExcepts::URL_RelativeBaseURL);
}
}
}
}
[ baseURL = Client relativeURL = Information-1-0.dtd ]
The calltree proceeds with:
msvcrtd!__cxxthrowexcept...@8
KERNEL32!77e989d1()
so there are no more clues there I guess. The CPU is at 0% and it appears as
though everything is stuck in some mutex.
I've made a (large) test program that spawns 50 threads and parses 50 DTD'd
XML
documents in each and it also occasionally gets stucks.
Brief facts of the case are:
* Single thread single point of initialization.
* Uses SAX.
* New parser, etc. for each document read.
* Uses MemBufInputSource.
* Uses MS VS6 sp5.
Sorry if this provides little clue as to what goes on. Please contact me for
more specfic information, if needed.
--
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: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-481) pthread_mutex_lock is slow on solaris
[
https://issues.apache.org/jira/browse/XERCESC-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-481.
---
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
I believe this has been addressed in Solaris.
pthread_mutex_lock is slow on solaris
-
Key: XERCESC-481
URL: https://issues.apache.org/jira/browse/XERCESC-481
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 1.7.0
Environment: Operating System: Solaris
Platform: Sun
Reporter: Case Larsen
Since this is used a lot in the string pool, it impacts performance. here is
a fix which we use and it works.
// this returns old value, so we need to add or subtract value to get true
value
inline int ink_atomic_increment(void *mem, int value)
{
volatile int * memp = (int *)mem;
for (;;) {
int current = *memp;
int new_value = current+value;
asm(cas %2,%3,%0 : =r (new_value) : 0 (new_value), m (*memp),
r (current));
if (new_value == current) return current;
}
}
int XMLPlatformUtils::atomicIncrement(int location)
{
return ink_atomic_increment(location,1) + 1;
}
int XMLPlatformUtils::atomicDecrement(int location)
{
return ink_atomic_increment(location,-1) - 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: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1455) Template ValueVectorOf does not call destructors for removing objects. A memory leak could result from this.
[
https://issues.apache.org/jira/browse/XERCESC-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1455.
Resolution: Fixed
Fix Version/s: 3.0.1
I see that there is now the callDestructor flag in ValueVectorOf. So I assume
this has been fixed (in an ugly way).
Template ValueVectorOf does not call destructors for removing objects. A
memory leak could result from this.
Key: XERCESC-1455
URL: https://issues.apache.org/jira/browse/XERCESC-1455
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 2.3.0
Environment: Solaris
Reporter: Alex Akula
Assignee: David Bertoni
Fix For: 3.0.1
Attachments: patch.txt
When objects get removed from ValueVectorOf object type container no
destructors are called for the objects. Amemory leak could result from this.
This could be fixed by changing the code:
template class TElem void ValueVectorOfTElem::
removeElementAt(const unsigned int removeAt)
{
if (removeAt = fCurCount)
ThrowXML(ArrayIndexOutOfBoundsException, XMLExcepts::Vector_BadIndex);
fElemList[removeAt] = 0; // akula -- this is the fix for classes in
which assign operator is overloaded appropriate way.
if (removeAt == fCurCount-1)
{
fCurCount--;
return;
}
// Copy down every element above remove point
for (unsigned int index = removeAt; index fCurCount-1; index++)
fElemList[index] = fElemList[index+1];
// And bump down count
fCurCount--;
}
--
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: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1656) Project uses deprecated Mac OS X functions and data types.
[ https://issues.apache.org/jira/browse/XERCESC-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1656. Resolution: Fixed Fix Version/s: 3.0.1 Assuming this is fixed in the 3-series. Project uses deprecated Mac OS X functions and data types. -- Key: XERCESC-1656 URL: https://issues.apache.org/jira/browse/XERCESC-1656 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.7.0 Environment: Mac OS X 10.4 with Xcode 2.4.1 Reporter: Kevin Hoyt Assignee: James Berry Fix For: 3.0.1 All functions that take an FSSpec are depricated. These functions need to be replaced with FSRef based functions so Xerces can still be used once these functions become obsolete. Also, I vote for removing support for Classic (Mac OS 9). If anyone really needs this, they can use an older release. And, I'd say the same thing about supporting CodeWarrior. These are the files that need to be updated. MacOSPLatformUtils.cpp MacOSPlatformUtils.hpp MacOSUnicodeConverter.cpp Is anyone working on updating the Mac specific code for Xerces??? -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
How to have an attribute which contains XML
We have blocks of XML which represents dialog templates. Here is an example with 2 buttons and one number edit control: dialogex caption=Activity charset=1 cx=522 cy=348 decplaces=5 field=activity fontname=MS Shell Dlg italic=0 major_version=1 minor_version=0 ptsize=8 resid=130 style=DS_SETFONT|DS_MODALFRAME|DS_FIXEDSYS|WS_POPUP|WS_CAPTION|WS_SYSMENU type=DIALOGEX weight=400 x=0 y=0 pushbutton caption=OK cx=63 cy=15 resid=IDOK style=WS_TABSTOP x=453 y=7/ pushbutton caption=Cancel cx=63 cy=15 resid=IDCANCEL style=WS_TABSTOP x=453 y=28/ editnumber cx=100 cy=12 decplaces=3 field=no_CSP formula=.//activity/@LCSP - .//activity/@FCSP + 1 numeric=int resid=218 style=ES_AUTOHSCROLL|ES_READONLY|WS_BORDER|WS_TABSTOP x=84 y=297/ /dialogex You can see that the editnumber element has an attribute called formula which contains an XQuery expression. This works fine until the XQuery expression contains something like the following: data.//activity/@status/data The problem is that Xerces does not like an attribute value that contains the '' and '' characters. When I try to parse the dialogex element with a formula attribute containing the above XQuery expression, it goes wobbly, and fails. Does anyone know a way around this? (Of course I could pre-parse the formula string, and replace all '' characters with @@lt for example, and similarly for '', and hope that our formula never needs to contain @@lt and @@gt. But I'd rather find a more elegant method.) -- View this message in context: http://old.nabble.com/How-to-have-an-attribute-which-contains-XML-tp26392607p26392607.html Sent from the Xerces - C - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
RE: How to have an attribute which contains XML
Are you saying that the document may be serialized with an element like the following? editnumber formula=data.//activity/@status/data If so, the serialization is invalid. See http://www.w3.org/TR/2006/REC-xml-20060816/#syntax. '' must be represented as a numeric character reference or 'lt;' when it's not used as a markup delimiter. If humans have to look at the markup, you might want to represent '' as 'gt;' for symmetry. Note that ampersands must also be escaped. A spec-compliant XML processor will take care of this for you. -Original Message- From: Leif Goodwin [mailto:lgood...@qgsl.com] Sent: Tue 11/17/2009 11:10 AM To: c-dev@xerces.apache.org Subject: How to have an attribute which contains XML We have blocks of XML which represents dialog templates. Here is an example with 2 buttons and one number edit control: dialogex caption=Activity charset=1 cx=522 cy=348 decplaces=5 field=activity fontname=MS Shell Dlg italic=0 major_version=1 minor_version=0 ptsize=8 resid=130 style=DS_SETFONT|DS_MODALFRAME|DS_FIXEDSYS|WS_POPUP|WS_CAPTION|WS_SYSMENU type=DIALOGEX weight=400 x=0 y=0 pushbutton caption=OK cx=63 cy=15 resid=IDOK style=WS_TABSTOP x=453 y=7/ pushbutton caption=Cancel cx=63 cy=15 resid=IDCANCEL style=WS_TABSTOP x=453 y=28/ editnumber cx=100 cy=12 decplaces=3 field=no_CSP formula=.//activity/@LCSP - .//activity/@FCSP + 1 numeric=int resid=218 style=ES_AUTOHSCROLL|ES_READONLY|WS_BORDER|WS_TABSTOP x=84 y=297/ /dialogex You can see that the editnumber element has an attribute called formula which contains an XQuery expression. This works fine until the XQuery expression contains something like the following: data.//activity/@status/data The problem is that Xerces does not like an attribute value that contains the '' and '' characters. When I try to parse the dialogex element with a formula attribute containing the above XQuery expression, it goes wobbly, and fails. Does anyone know a way around this? (Of course I could pre-parse the formula string, and replace all '' characters with @@lt for example, and similarly for '', and hope that our formula never needs to contain @@lt and @@gt. But I'd rather find a more elegant method.) -- View this message in context: http://old.nabble.com/How-to-have-an-attribute-which-contains-XML-tp26392607p26392607.html Sent from the Xerces - C - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1866) Crash with regular expression
[
https://issues.apache.org/jira/browse/XERCESC-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1866:
-
Fix Version/s: 3.1.0
Would be really nice to fix this for 3.1.0.
Crash with regular expression
-
Key: XERCESC-1866
URL: https://issues.apache.org/jira/browse/XERCESC-1866
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Environment: Windows XP, Visual Studio 2005
Reporter: Alexander Hartmann
Assignee: David Bertoni
Fix For: 3.1.0
Attachments: XERCESC-1866.patch
when I run the following test code my application crashes on the second
regEx.matches call:
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
{
XMLBuffer optionsBuf;
optionsBuf.append('i');
optionsBuf.append('H');
RegularExpression regEx(L^\\W*Excel\\W*$, optionsBuf.getRawBuffer());
regEx.matches(Excel);
}
some details I found during debugging:
- there is an instance of RangeToken where I have no idea where this is
created. I've set a breakpoint in the constructor but the debugger does not
stop.
- when RangeToken::getCaseInsensitiveToken is called a new RangeToken is
created and stored in fCaseIToken
- when parsing is finished the newly created RangeToken is deleted (through
~RegularExpression - ~TokenFactory), but the original RangeToken (where I
don't know where it is created) still exists and references the deleted
RangeToken in fCaseIToken
- the next time RangeToken::getCaseInsensitiveToken is called the invalid
reference fCaseIToken is returned and this leads to a crash when it is
accessed.
--
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: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1826) XMLURL::makeNewStream() fails to decode file:/// URLs containing the (properly escaped) % character
[ https://issues.apache.org/jira/browse/XERCESC-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1826: - Fix Version/s: 3.1.0 Assignee: Boris Kolpackov XMLURL::makeNewStream() fails to decode file:/// URLs containing the (properly escaped) % character --- Key: XERCESC-1826 URL: https://issues.apache.org/jira/browse/XERCESC-1826 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 2.5.0, 2.6.0, 2.7.0, 2.8.0, 3.0.0, 2.9.0, 3.1.0 Environment: Windows XP Prof. German, MS Visual Studio 2003 Reporter: Matteo Ceruti Assignee: Boris Kolpackov Fix For: 3.1.0 I truly believe that XMLURL::makeNewStream() (see src/xercesc/util/XMLURL.cpp) does not correctly handle file:///-URLs containing the escape-sequence %25 (that is the '%'-character itself). Consider you have a win32 filepath like C:\Documents\myfile_%_.xml . Its URL would be file:///C:/Documents/myfile_%25_.xml, right? But this URL is rejected by raising a MalformedURLException. makeNewStream() decodes the URL by searching and replacing the escape-sequences one by one. When it sucessfully replaced %25 by the '%'-character it continunes it's search for the next escape-sequence. The problem is, that it starts at the very position, where the last escape-sequence began. Therefore it suddenly finds a %-character again, because it had just been put there. This happens at least with xerces-c 2.5 and it seems that the current (revision=670359) http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/XMLURL.cpp still has this problem. So probably other releases may have the same issue. I think the line percentIndex = XMLString::indexOf(realPath, chPercent, percentIndex, fMemoryManager); should be replaced by percentIndex = XMLString::indexOf(realPath, chPercent, percentIndex + 1, fMemoryManager); This works for me. Please correct me, if I'm wrong. Thank you in advance. Best regards, Matteo -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1599) DTD grammar caching of failed grammer causes segmentation fault
[ https://issues.apache.org/jira/browse/XERCESC-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1599: - Affects Version/s: (was: 2.7.0) 3.0.1 I tried the attached test with 3.0.1. IGXMLScanner works without any problem, including under valgrind. DGXMLScanner on the other hand does cause some memory access/free errors. So it seems this has been fixed in the former but not the latter. DTD grammar caching of failed grammer causes segmentation fault --- Key: XERCESC-1599 URL: https://issues.apache.org/jira/browse/XERCESC-1599 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (DTD) Affects Versions: 3.0.1 Environment: All. Reporter: Michael Fuller Priority: Critical Attachments: test-12907.tar Problem: If you enable grammar caching and: * DTD validate a valid document * DTD validate an invalid document * DTD validate an valid document a segmentation fault, etc. occurs inside Xerces. Apparent cause: When parsing a document in DTD mode, the parser always creates a temporary grammar called [dtd]. If the parser successully parses the document, it puts the parsed DTD in [dtd] and then renames [dtd] to the real name of the DTD. However, if the parse does not succeed, the parser (erroneously?) just leaves [dtd] in the grammer cache. This means that [dtd] exists in the grammar cache when a new document is parsed later that uses a novel DTD, then the presence of [dtd] in the grammar cache will eventually cause a memory leak and double free, ultimately causing a crash (see attached dbx or gdb output). This affects users of the DGXMLScanner and the IGXMLScanner. A fix for the problem is to make sure that before [dtd] is placed in the grammar cache any existing [dtd] is removed. The attached test case failed under both Solaris and Linux. Under Solaris, depending on where the files were located, environment, etc. it would sometimes crash, and sometimes not. However, even when it did not crash, it was still double freeing, etc; this can be seen by running bcheck test-12907 (output attached). Under linux, it always seems to crash with: *** glibc detected *** free(): invalid pointer: 0x0050ed18 *** However, even if the erroneous code does not trigger a crash, valgrind should show the problem. We have developed a kludgy workaround, but I do not think that it is a good fix. See the attached diffs against 2.7.0. -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-372) Xerces-C++/1.7 parser can not handle % sign correctly
[ https://issues.apache.org/jira/browse/XERCESC-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-372. --- Resolution: Fixed Fix Version/s: 3.0.1 Assignee: (was: Xerces-C Developers Mailing List) Assuming fixed in the latest release. Xerces-C++/1.7 parser can not handle % sign correctly - Key: XERCESC-372 URL: https://issues.apache.org/jira/browse/XERCESC-372 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (DTD) Affects Versions: 1.7.0 Environment: Operating System: HP-UX Platform: HP Reporter: Yufan Zhang Fix For: 3.0.1 Your Xerces-C++/1.7 parser can not handle % sign correctly. If a #PCDATA element contains a value of %, this % will go away. But for %%, sometimes we get %, sometime get %% in the chars value of the documentHandler interface function ::characters(const XMLCh* chars, const unsigned int lenght). Do you know why? or we can not simply send %, in stead, we need to convert % to other string. If so, what string we need to convert to. If not, is there any special setting we forgot to do? Thanks, Yufan -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1630) Unclear error description when validation by schema
[ https://issues.apache.org/jira/browse/XERCESC-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1630. Resolution: Won't Fix I don't think anyone will ever try to do this. The code base is already complex enough. Unclear error description when validation by schema --- Key: XERCESC-1630 URL: https://issues.apache.org/jira/browse/XERCESC-1630 Project: Xerces-C++ Issue Type: Improvement Components: Validating Parser (DTD) Affects Versions: 2.4.0 Environment: Solaris Reporter: woods wang When using the Xerces to validate the xml by schema, for example, the content model is '((msisdn,imsi),region)', as you know, the msisdn and imsi is mandatory parameters, if the xml is missing the msisdn element, Xerces will report the error Message: Element 'imsi' is not valid for content model:'((msisdn,imsi),region)'!! I understand that the 'msisdn' is the first expected mandatory parameter, but xerces get the 'imsi' as the first parameter, so it complain the 'imsi' is not valid. But could it be possible to change the error description to make it more clear? like msisdn is missing something like that... thanks, //woods -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1859) DOMLSResourceResolver resolveResource() called for every instance of a DTD.
[ https://issues.apache.org/jira/browse/XERCESC-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779320#action_12779320 ] Boris Kolpackov commented on XERCESC-1859: -- Confirmed. The problem could be that DTDs don't have a key that can be used to ignore duplicate schemas like the target namespace is used in XML Schema caching. One way to address this would be to extend the fgXercesLoadSchema property to also apply to DTDs. DOMLSResourceResolver resolveResource() called for every instance of a DTD. --- Key: XERCESC-1859 URL: https://issues.apache.org/jira/browse/XERCESC-1859 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (DTD) Affects Versions: 3.0.1 Environment: x86 build Reporter: Ben Griffin Attachments: 12421546.zip By overriding DOMLSResourceResolver, it can be identified that every time a DTD based document is being validated, the DTD cache is being ignored, and DOMLSInput* DOMLSResourceResolver::resolveResource() is being called to locate the relevant resource. -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1202) GeneralAttributeCheck initialize fails
[ https://issues.apache.org/jira/browse/XERCESC-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1202. Resolution: Fixed Fix Version/s: 3.0.1 Assuming fixed in 3.0.1. GeneralAttributeCheck initialize fails -- Key: XERCESC-1202 URL: https://issues.apache.org/jira/browse/XERCESC-1202 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.3.0 Environment: Sun Solaris 8 Reporter: Michael Kopp Priority: Critical Fix For: 3.0.1 We are parsing the same xml in multiple threads, which contains a schema. Very frequently, at least once for every tinderbox build, we get the following core dump: =[1] xercesc_2_3::ValueHashTableOfunsigned short::findBucketElem(this = (nil), key = 0x8ec3a4, hashVal = 4265683276U), line 252 in ValueHashTableOf.c [2] xercesc_2_3::ValueHashTableOfunsigned short::get(this = (nil), key = 0x8ec3a4), line 199 in ValueHashTableOf.c dbx: warning: unexpected RTTI for type xercesc_2_3::XSDLocator [3] xercesc_2_3::GeneralAttributeCheck::getFacetId(this = 0xfc500c24, facetName = 0x8ec3a4), line 298 in GeneralAttributeCheck.hpp [4] xercesc_2_3::TraverseSchema::traverseByRestriction(this = 0xfc500b58, rootElem = 0x8ec008, contentElem = 0x8ec118, typeName = 0x453198, qualifiedName = 0x47b758, finalSet = 0), line 2981 in TraverseSchema.cpp [5] xercesc_2_3::TraverseSchema::traverseSimpleTypeDecl(this = 0xfc500b58, childElem = 0x8ec008, topLevel = false, baseRefContext = 0), line 1082 in TraverseSchema.cpp [6] xercesc_2_3::TraverseSchema::traverseAttributeDecl(this = 0xfc500b58, elem = 0x8ebdd8, typeInfo = 0x33eee0, topLevel = false), line 2053 in TraverseSchema.cpp [7] xercesc_2_3::TraverseSchema::processAttributes(this = 0xfc500b58, elem = 0x8eac50, attElem = 0x8ebdd8, baseRawName = (nil), baseLocalPart = (nil), baseURI = (nil), typeInfo = 0x33eee0, isBaseAnyType = false), line 6108 in TraverseSchema.cpp [8] xercesc_2_3::TraverseSchema::processComplexContent(this = 0xfc500b58, ctElem = 0x8eac50, typeName = 0x8ead70, childElem = 0x8eae40, typeInfo = 0x33eee0, baseRawName = (nil), baseLocalPart = (nil), baseURI = (nil), isMixed = false, isBaseAnyType = false), line 5906 in TraverseSchema.cpp [9] xercesc_2_3::TraverseSchema::traverseComplexTypeDecl(this = 0xfc500b58, elem = 0x8eac50, topLevel = true, recursingTypeName = (nil)), line 1269 in TraverseSchema.cpp [10] xercesc_2_3::TraverseSchema::processChildren(this = 0xfc500b58, root = 0x8ea5a8), line 4283 in TraverseSchema.cpp [11] xercesc_2_3::TraverseSchema::doTraverseSchema(this = 0xfc500b58, schemaRoot = 0x8ea5a8), line 276 in TraverseSchema.cpp [12] xercesc_2_3::TraverseSchema::TraverseSchema(this = 0xfc500b58, schemaRoot = 0x8ea5a8, uriStringPool = 0x43d0f0, schemaGrammar = 0x8cfe10, grammarResolver = 0x8844b8, xmlScanner = 0x21a458, schemaURL = 0x2126c0, entityHandler = (nil), errorReporter = 0x3ff874, manager = 0xd50b8), line 253 in TraverseSchema.cpp [13] xercesc_2_3::IGXMLScanner::resolveSchemaGrammar(this = 0x21a458, loc = 0x812458, uri = 0x213ad8), line 1421 in IGXMLScanner2.cpp [14] xercesc_2_3::IGXMLScanner::parseSchemaLocation(this = 0x21a458, schemaLocationStr = 0x262a58), line 1285 in IGXMLScanner2.cpp [15] xercesc_2_3::IGXMLScanner::scanRawAttrListforNameSpaces(this = 0x21a458, theRawAttrList = 0x7dbd30, attCount = 4), line 1247 in IGXMLScanner2.cpp [16] xercesc_2_3::IGXMLScanner::scanStartTagNS(this = 0x21a458, gotData = true), line 2034 in IGXMLScanner.cpp [17] xercesc_2_3::IGXMLScanner::scanContent(this = 0x21a458, extEntity = false), line 849 in IGXMLScanner.cpp [18] xercesc_2_3::IGXMLScanner::scanDocument(this = 0x21a458, src = CLASS), line 209 in IGXMLScanner.cpp [19] xercesc_2_3::XMLScanner::scanDocument(this = 0x21a458, systemId = 0x25b9b8), line 419 in XMLScanner.cpp [20] xercesc_2_3::XMLScanner::scanDocument(this = 0x21a458, systemId = 0x817d58 /view/auto_build_MessageMapper_Development-dcacpl1-2004-04-25.2135_view/dcaclearcase/vobs/eQuality/eBridge/../../eBridge/FormatDefinitions/swift/SwiftDataDictionary.xml), line 427 in XMLScanner.cpp [21] xercesc_2_3::SAX2XMLReaderImpl::parse(this = 0x3ff868, systemId = 0x817d58 /view/auto_build_MessageMapper_Development-dcacpl1-2004-04-25.2135_view/dcaclearcase/vobs/eQuality/eBridge/../../eBridge/FormatDefinitions/swift/SwiftDataDictionary.xml), line 637 in SAX2XMLReaderImpl.cpp [22] ftisoft::vendor::swift::Field::GetDictionary(toFill = CLASS, def_dir = CLASS), line 156 in DataDictionary.cpp ... I looked into it and found that the initialize of GeneralAttributeCheck::mapElements seems to fail. Although the mutex
[jira] Updated: (XERCESC-1748) parsing registry based authorities in URI fails
[ https://issues.apache.org/jira/browse/XERCESC-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1748: - Affects Version/s: (was: 2.7.0) 3.0.1 Fix Version/s: 3.1.0 Assignee: Boris Kolpackov parsing registry based authorities in URI fails --- Key: XERCESC-1748 URL: https://issues.apache.org/jira/browse/XERCESC-1748 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.0.1 Environment: Linux Reporter: G. Kramer Assignee: Boris Kolpackov Priority: Blocker Fix For: 3.1.0 Attachments: anyURITest.xml, anyURITest.xsd, xercesc-1748patch.txt validating documents against schema containing registry based authorities in anyURI typed attributes fails with: Message: Datatype error: Type:InvalidDatatypeValueException, Message:Value '...' is NOT a valid URI -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1659) Order sensitivity in schemaLocation and noNamespaceSchemaLocation
[ https://issues.apache.org/jira/browse/XERCESC-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1659: - Affects Version/s: (was: 2.7.0) 3.1.0 Fix Version/s: 3.1.0 Assignee: Boris Kolpackov Confirmed the problems are still present, even with multi-import enabled. Order sensitivity in schemaLocation and noNamespaceSchemaLocation - Key: XERCESC-1659 URL: https://issues.apache.org/jira/browse/XERCESC-1659 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Environment: all Reporter: Boris Kolpackov Assignee: Boris Kolpackov Fix For: 3.1.0 Attachments: test-case-1.tar.gz, test-case-2.tar.gz I am attaching two test cases (each consists of 3 schemas plus an XML instance). If you try to run domprint on the first test case, you will get the following error: $ domprint -v=always -n -s -f test-users.xml Error at file test-users.xml, line 6, column 78 Message: Unknown element 'b:UserDatabase' If you change the order of the schemaLocation and noNamespaceSchemaLocation attributes in test-users.xml then the error disappears. The second test case is a slight modification of the first test case with the only difference being the schemas with targetNamespace are now do not have a namespace, and the schema that used to be without a namespace (derived-user-config.xsd) now is in a namespace. If you run domprint on this test case, you will get the following error: $ domprint -v=always -n -s -f test-users.xml Error at file test-users.xml, line 6, column 55 Message: Unknown element 'UserDatabase' This seems to prove that for Xerces-C++, for some reason, it is important that the schema that declares the root element is mentioned in the first *Location attribute (nor matter whether schemaLocation or noNamespaceSchemaLocation). Now comes the surprise: if we reverse the order of the two attributes in the second test case, domprint terminates with segmentation fault. Examination of the core points to the IGXMLScanner.cpp, line 2288: elemDecl = fGrammar-getElemDecl( uriId, nameRawBuf, qnameRawBuf, currentScope ); -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1263) Abstract type not handled correctly by cached grammar
[ https://issues.apache.org/jira/browse/XERCESC-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1263: - Affects Version/s: (was: 2.5.0) (was: 2.3.0) 3.1.0 Fix Version/s: 3.1.0 The bug is still present in 3.1.0. Abstract type not handled correctly by cached grammar - Key: XERCESC-1263 URL: https://issues.apache.org/jira/browse/XERCESC-1263 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Reporter: Matthew Berry Fix For: 3.1.0 Details: I have managed to narrow the problem I am having to a simple test case. In the schema, I have an abstract type defined and am using xsi:type with a concrete type in the data file. If I have a xsi:schemaLocation attribute in my data file, then the test Xml file passes the validation. (I have used DOMCount to verify this) If I remove xsi:schemaLocation and instead from my source code call loadGrammar() and setFeature(XMLUni::fgXercesUseCachedGrammarInParse, true), I am getting the following error messages: Message: Element paramInstance is declared with a type that is abstract. Use xsi:type to specify a non-abstract type Message: Attribute 'name' is not declared for element 'paramInstance' Schema: --- xsd:schema targetNamespace=http://www.temp.org; xmlns:tmp=http://www.temp.org; xmlns:xsd=http://www.w3.org/2001/XMLSchema; !-- Define a 'paramInstance' element NOTE: We use an abstract base to allow for extension -- xsd:complexType name=ParamInstanceType abstract=true / xsd:element name=paramInstance type=ParamInstanceType / !-- Specifying a concrete type -- xsd:complexType name=ConcreteParamInstance xsd:complexContent xsd:extension base=tmp:ParamInstanceType xsd:attribute name=name type=xsd:string use=required / /xsd:extension /xsd:complexContent /xsd:complexType /xsd:schema Test data file: --- paramInstance xmlns=http://www.temp.org; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=ConcreteParamInstance name=param1 / -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1232) Access violation when validating against invalid schema
[ https://issues.apache.org/jira/browse/XERCESC-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1232: - Affects Version/s: (was: 2.5.0) 3.1.0 Segfault is still there in the 3.1.0 codebase. Access violation when validating against invalid schema --- Key: XERCESC-1232 URL: https://issues.apache.org/jira/browse/XERCESC-1232 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Environment: Windows XP - VC++ 6.0 SP5 Reporter: Alberto Massari Attachments: Feb2.xml, t1.xsd, x1.xsd, xsi.xsd I received an invalid schema, where a schema with no target namespace imported a second schema (with a target namespace) that, in turn, imported a third schema having no target namespace. When an instance of XML is validated against this schema, an access violation occurs when trying to use the fGrammar for the top level XML element, as it had already been deleted. This happens because TraverseSchema::preprocessImport is testing for a duplicate grammar being imported only if the grammar has a namespace; if a grammar with no namespace is imported, it is parsed again and placed in the grammar resolver. But the grammar resolver will delete the Grammar object previously associated with that key, and when that Grammar object will be restored at the end of the processing of the xs:import statement, it will be an invalid pointer. To reproduce the access violation, run DOMPrint -n -s feb2.xml on the attached files. Alberto -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1174) Error message doesnt contain all usefull informations if the schema-parsing isnt successfull
[
https://issues.apache.org/jira/browse/XERCESC-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1174.
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
No clear problem description provided.
Error message doesnt contain all usefull informations if the schema-parsing
isnt successfull
Key: XERCESC-1174
URL: https://issues.apache.org/jira/browse/XERCESC-1174
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 2.4.0
Environment: Operating System: Windows XP
Platform: PC
Reporter: Kai-Uwe Schmidt
Under M$ VC++ 6.0
The Information can be delivered to the user by modifying the resource String
table ID 16430 like this:
Datatype error: Type:{0}, Attribute: {2}, Message:{1}.
and upgrading:
emitError (XMLValid::DatatypeError, idve.getType(), idve.getMessage(),attDef-
getFullName());
in SchemaValidator::validateAttrValue.
--
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: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1187) Xerces SAX2 parser can not skip xs:any if xsi:nil is used in xml
[ https://issues.apache.org/jira/browse/XERCESC-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1187. Resolution: Fixed Fix Version/s: 3.1.0 Assignee: (was: Xerces-C Developers Mailing List) Works in 3.1.0. Xerces SAX2 parser can not skip xs:any if xsi:nil is used in xml Key: XERCESC-1187 URL: https://issues.apache.org/jira/browse/XERCESC-1187 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.4.0 Environment: Operating System: Solaris Platform: Sun Reporter: Andy Ding Fix For: 3.1.0 We're using Xerces-C++ version 2.4.0. Now we found an error about xerces SAX2 parser can not skip xs:any type if xsi:nil=true is used in xml. As you can see, in following note.xml, the element school should be validated by another schema file defining this element, not by the schema file defining xs:any. The schema example: ?xml version=1.0? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns=http://www.w3schools.com; elementFormDefault=qualified targetNamespace=http://www.w3schools.com; xs:element name=note xs:complexType xs:sequence xs:element name=to type=xs:string/ xs:element name=from type=xs:string/ xs:any namespace=##any processContents=skip maxOccurs=unbounded/ /xs:sequence /xs:complexType /xs:element /xs:schema The xml example: ?xml version=1.0? note xmlns=http://www.w3schools.com; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.w3schools.com note.xsd toTove/to fromJani/from school student xsi:nil=true/ /school /note The error message: Error at file 1, line 15, char 8 Message: Element note with attribute xsi:nil=true must be empty -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-991) When calling getContentModel() on element it throws exception for empty elements
[
https://issues.apache.org/jira/browse/XERCESC-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-991.
---
Resolution: Invalid
Assignee: (was: Xerces-C Developers Mailing List)
Please provide a test case if you believe this is still a problem.
When calling getContentModel() on element it throws exception for empty
elements
Key: XERCESC-991
URL: https://issues.apache.org/jira/browse/XERCESC-991
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 2.2.0
Environment: Operating System: Other
Platform: Other
Reporter: Hima Mukkamala
When getContentModel() is called on elem where
SchemaELementDecl* elem for an empty element declaration,
it throws an exception. Isn't it the right
approach to return null similar to SchemaElementDecl::Simple
typed elements.
Fix would be to add this code in ComplexTypeInfo::makeContentModel
// code
else if (fContentType == SchemaElementDecl::Empty) {
// just return nothing
}
in this function.
-thanks
hima
--
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: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-391) Make Error/Message Extension Of The XMLValidator Possible
[ https://issues.apache.org/jira/browse/XERCESC-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-391: Priority: Minor (was: Major) Assignee: (was: Xerces-C Developers Mailing List) Issue Type: New Feature (was: Bug) Make Error/Message Extension Of The XMLValidator Possible - Key: XERCESC-391 URL: https://issues.apache.org/jira/browse/XERCESC-391 Project: Xerces-C++ Issue Type: New Feature Components: Validating Parser (XML Schema) Affects Versions: 1.7.0 Environment: Operating System: Linux Platform: PC Reporter: Reid Spencer Priority: Minor Attachments: XMLValidator.cpp, XMLValidator.hpp, XMLValidityCodes.hpp The 1.7.0 xercesc/framework/XMLValidator class uses a message numbering and loading schema that does not lend itself to extension of the class. In my case, I am attempting to provide further semantic validation of a document by extending the class xercesc/validators/schema/SchemaValidator. To make XMLValidator a little more friendly to those wishing to extend it, I have made four new virtual functions in the XMLValidator interface. All four have default implementations and no code changes to any other classes were required. The new virtual functions are: getClassLoader, isWarning, isError, and isFatal. These four functions permit a subclass to determine which class loader gets loaded to generate the error message and to also decide which error codes are warnings, errors, or fatal. Previously, these capabilities were statically coded into XMLValidator and XMLValid. One other change is that XMLValid::Codes is now an unsigned integer rather than an enumeration. This change is needed in order to make it possible for subclasses to have their own range of error codes. XMLValidator reserves error numbers 0- for its own use. Subclasses can pick any other range for their error numbers. The change to implement this consists of only three files: xercesc/framework/XMLValidator.hpp xercesc/framework/XMLValidator.cpp xercesc/framework/XMLValidityCodes.hpp All three files are provided as attachments and have been tested in the following environment (i.e. all Sample Test programs work): Platform: PC (2 x 1GHz Pentium III ) Operating System: Linux 7.1 + updates (kernel = 2.4.9-31smp) Compiler: GCC 3.0.3 It would be great if these changes could be made to stick in future releases. -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[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: - Affects Version/s: (was: 2.7.0) 3.1.0 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 (XML Schema) Affects Versions: 3.1.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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1668) Good schema rejected - simpleContent/complexContent
[ https://issues.apache.org/jira/browse/XERCESC-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779345#action_12779345 ] Boris Kolpackov commented on XERCESC-1668: -- Still present in the 3.1.0 codebase. 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 (XML Schema) Affects Versions: 3.1.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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1576) lax wildcard is handled as strict wildcard in some cases
[ https://issues.apache.org/jira/browse/XERCESC-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1576. Resolution: Invalid Please provide a test case (schema and xml files) that reproduces this problem. lax wildcard is handled as strict wildcard in some cases Key: XERCESC-1576 URL: https://issues.apache.org/jira/browse/XERCESC-1576 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.6.0 Environment: Windows VC++ Reporter: Akihiko Tozawa This bug is similar to XERCESJ-128. When reading for example, xs:any processContents=lax namespace=a b c d/, this lax is ignored and treated as strict. -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1587) The default values for attributes in schema are not resolved using DOMBuilder
[ https://issues.apache.org/jira/browse/XERCESC-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1587. Resolution: Invalid Works for me. The default values for attributes in schema are not resolved using DOMBuilder - Key: XERCESC-1587 URL: https://issues.apache.org/jira/browse/XERCESC-1587 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.6.0 Reporter: Vit Ondruch I was used to use the XSD schema with default attribute values as: xs:attribute name=MaxSequenceLength type=xs:unsignedLong form=unqualified default=1 / A lot of my XML files does not contained the attributes with specified default value at all. When i used the XercesDOMParser, everything worked as expected and when i try to retrieve the value of such attribute, the default value was returned, but that does not apply for DOMBuilder unfortunatelly. The attribute is simply not found, which is wrong. -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1601) SAX2 Parser throws an uncaught xercesc_2_7::XMLValid::Codes exception when setValidationConstraintFatal is on with enclosing xml tags
[
https://issues.apache.org/jira/browse/XERCESC-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1601.
Resolution: Invalid
Does not appear to be a problem with Xerces-C++.
SAX2 Parser throws an uncaught xercesc_2_7::XMLValid::Codes exception when
setValidationConstraintFatal is on with enclosing xml tags
-
Key: XERCESC-1601
URL: https://issues.apache.org/jira/browse/XERCESC-1601
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 2.7.0
Environment: Xerces 2.7 recompiled locally
Win2K, WinXP, Win2k3
Microsoft Visual Sutudio 7.1 in either debug or release builds
Reporter: Michel Courtine
I implemented a xerces SAX2 parser by following IBM's recommandations in
Make the most of Xerces-C++ found at:
http://www-128.ibm.com/developerworks/xml/library/x-xercc/
This parser works fine with large and complex files and performs a very good
validation. No complains at all.
Untill we started to use DOM generated files by a Java app that outputs this
kind of xml data:
Directory xmlns=http://www.rd.bbc.co.uk/dtv/wp4/System42;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1
xsi:schemaLocation=http://www.rd.bbc.co.uk/dtv/wp4/System42
../schema/system42.xsd
ModuleEntry version=1 type=CODE name=LIBCORE
/ModuleEntry
ModuleEntry version=1 type=CODE name=LIBPATH
/ModuleEntry
ModuleEntry version=1 type=OPENTV_RESOURCE name=SYS_ENV
/ModuleEntry
ModuleEntry version=1 type=OPENTV_RESOURCE name=SERVICE
/ModuleEntry
ServiceInfo version=1 name=singleStreamVideo
/ServiceInfo
/Directory
When we send the following xml, with self-contained tags (one-liners)
instead of empty-enclosing tags, no exceptions are thrown and the validation
parsing are performed correctly.
Directory xmlns=http://www.rd.bbc.co.uk/dtv/wp4/System42;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1
xsi:schemaLocation=http://www.rd.bbc.co.uk/dtv/wp4/System42
../schema/system42.xsd
ModuleEntry version=1 type=CODE name=LIBCORE /
ModuleEntry version=1 type=CODE name=LIBPATH /
ModuleEntry version=1 type=OPENTV_RESOURCE name=SYS_ENV /
ModuleEntry version=1 type=OPENTV_RESOURCE name=SERVICE /
ServiceInfo version=1 name=singleStreamVideo /
/Directory
An other interesting point for you is that when we turn
setValidationConstraintFatal to false or the validation off, the parsing is
performed correctly too.
This definately means to me that the validation considers the xml file as
invalid although both forms are supposed to be valid from an xsd point of
view.
(XMLSpy validates both versions against our xsd).
On top of that, probably because because we set setValidationConstraintFatal
to true, the exception is caught internally and fails silently preventing us
from catching it.
Here is the xsd definition of a ModuleEntry:
xs:element name=ModuleEntry
xs:annotation
xs:documentationModule entry
declaration/xs:documentation
/xs:annotation
xs:complexType
xs:attribute name=name type=xs:string
use=required/
xs:attribute name=type use=required
xs:simpleType
xs:restriction base=xs:string
xs:enumeration
value=DIRECTORY/
xs:enumeration
value=ENVIRONMENT/
xs:enumeration
value=STREAMEVENTS/
xs:enumeration
value=OPENTV_RESOURCE/
xs:enumeration
value=SYS42_RESOURCE/
xs:enumeration
value=PROPRIETARY_RESOURCE/
xs:enumeration value=CODE/
xs:enumeration value=RAW/
xs:enumeration
value=VERSIONED_RAW/
/xs:restriction
/xs:simpleType
/xs:attribute
xs:attribute name=version type=xs:unsignedInt
use=required/
/xs:complexType
/xs:element
Here are the features we set in the compilers
bool CParseMgr::parse(const char* sFilename, const char *sXsdPath)
{
CXercesInitialiser InitXerces;
m_sFilename = sFilename;
SAX2XMLReader* parser = XMLReaderFactory::createXMLReader();
[jira] Updated: (XERCESC-1715) xereces-c allows a restricted type to have mixed content, where the content type of the base is not.
[ https://issues.apache.org/jira/browse/XERCESC-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1715: - Affects Version/s: (was: 2.7.0) 3.1.0 Still present in the 3.1.0 codebase. Xerces-J 2.9.1 appears to have the same problem. xereces-c allows a restricted type to have mixed content, where the content type of the base is not. - Key: XERCESC-1715 URL: https://issues.apache.org/jira/browse/XERCESC-1715 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 3.1.0 Reporter: Christian Will Hi there, xereces-c allows a restricted type to have mixed content, where the content type of the base is not. sample: ?xml version=1.0? xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:complexType name=A xsd:choice minOccurs=0 maxOccurs=4 xsd:group ref=x/ xsd:group ref=y/ /xsd:choice /xsd:complexType xsd:group name=x xsd:sequence xsd:element name=x1/ xsd:element name=x2/ /xsd:sequence /xsd:group xsd:group name=y xsd:choice xsd:element name=y1/ xsd:element name=y2/ /xsd:choice /xsd:group xsd:group name=G xsd:choice xsd:group ref=x/ xsd:group ref=y/ /xsd:choice /xsd:group xsd:element name=elem xsd:complexType mixed=true xsd:complexContent xsd:restriction base=A xsd:group ref=G minOccurs=0 maxOccurs=0/ /xsd:restriction /xsd:complexContent /xsd:complexType /xsd:element /xsd:schema Regards, Christian Will -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1721) Unexpected error info is reported for the group referrence(and Order indicators all is used in the group definition)
[ https://issues.apache.org/jira/browse/XERCESC-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1721. Resolution: Invalid The all compositor cannot be inside the sequence compositor. If you remove the sequence tags in the referencing type, the schema becomes valid. Unexpected error info is reported for the group referrence(and Order indicators all is used in the group definition) -- Key: XERCESC-1721 URL: https://issues.apache.org/jira/browse/XERCESC-1721 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0 Environment: Windows XP Reporter: Bill Yan When a group is defined with Order indicators all, and this group is refered in a complexType definition, the schema file looks like this: xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:element name=comment type=xsd:string/ xsd:group name=schemaTop3 xsd:all xsd:element ref=comment/ /xsd:all /xsd:group xsd:complexType name=PurchaseOrderType xsd:sequence xsd:group ref=schemaTop3 minOccurs=0 maxOccurs=0/ /xsd:sequence /xsd:complexType /xsd:schema when I use XercesDOMParser::loadGrammar() to check the validity of this schema file, the following error info is reported: A group whose content is 'all' must only appear as the content type of a complex type definition. - Line 11, Col 61. I tried to change xsd:all to xsd:sequence or xsd:choice, no error is reported. -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1713) external-schemaLocation property does not override the schema location attribute in the instance
[ https://issues.apache.org/jira/browse/XERCESC-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1713. Resolution: Fixed Fix Version/s: 3.1.0 The fix is in SVN. This can now be resolved by setting fgXercesLoadSchema property to false. external-schemaLocation property does not override the schema location attribute in the instance Key: XERCESC-1713 URL: https://issues.apache.org/jira/browse/XERCESC-1713 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (XML Schema) Affects Versions: 2.7.0 Environment: any Reporter: Boris Kolpackov Fix For: 3.1.0 The documentation for the external-schemaLocation and external-noNamespaceSchemaLocation properties state that if specified, the instance document's schemaLocation and noNamespaceSchemaLocation attributes will be effectively ignored. This appears not to be the case. If the schema specified with the external-* properies can not be opened, the parser proceeds to try paths from the schemaLocation and noNamespaceSchemaLocation attributes. I think this does not make much sense and is actually a potential security threat. Normally if one specifies the schema location with the external-* properties they don't want the values from the instance to have any effect. -- 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
