[jira] Commented: (XERCESC-1930) CRLF is replaced by space
[ https://issues.apache.org/jira/browse/XERCESC-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869570#action_12869570 ] Jesse Pelton commented on XERCESC-1930: --- If you attach a sample document, it's much easier to diagnose a problem. In the absence of such a document, I'm going to hazard a guess as to the nature of your question. I think you're saying that when you have text in element context, CRLF gets converted to space. For instance, if your serialization includes something like the following: your DOM has an element node for myElement that has a single attribute whose content is "text with line break". If this is indeed the question, this behavior is mandated by the XML specification. If you're unclear about this, please read the spec (particularly http://www.w3.org/TR/2006/REC-xml11-20060816/#AVNormalize) or an introductory XML text. Rather than opening a bug report, please post questions to the appropriate mailing list. I believe that's c-us...@xerces.apache.org. > CRLF is replaced by space > -- > > Key: XERCESC-1930 > URL: https://issues.apache.org/jira/browse/XERCESC-1930 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: Harpreet > > Hi, > Our code creates a xml where description tag contains text in the format > "abcdCRLFefgh" where CR stands for carriage return and LF stands for line > feed. Now when we pass the xml to xerces, the CRLF combo is converted to > space which is unexpected. > Is this issue already reported? I searched over the net and in JIRA as well > but could not find any such reported issues. > Is there any workaround available for this. > Thanks > Harpreet -- 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-1846) We should not let the ICU use a replacement character that we know will result in a document that's not well-formed.
[ https://issues.apache.org/jira/browse/XERCESC-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657377#action_12657377 ] Jesse Pelton commented on XERCESC-1846: --- If this is indeed a bug, it affects more than the ICU transcoder. The following Xerces transcoder classes hard-code the use of 0x1A as a replacement character: XML88591Transcoder XML88591Transcoder390 XMLASCIITranscoder XMLASCIITranscoder390 The following classes use Windows' WideCharToMultiByte function, specifying that the system default value should be used as a replacement character. I'm not sure whether there's any guarantee that this character is legal in an XML document. Win32Transcoder CygwinTranscoder I don't know enough to determine whether there's any danger that the following classes might cause an illegal character to be included in a serialized document: MacOSTranscoder MacOSLCPTranscoder > We should not let the ICU use a replacement character that we know will > result in a document that's not well-formed. > > > Key: XERCESC-1846 > URL: https://issues.apache.org/jira/browse/XERCESC-1846 > Project: Xerces-C++ > Issue Type: Bug > Components: Non-Validating Parser, Utilities > Environment: ICU 4.0, 3.8 > Xerces 3.0, 2.8. Probably will be common problem for earlier versions too. > HP-UX B.11.23 U 9000/800 > aCC compier, cc >Reporter: Jan Suchy > > Jan Suchý wrote: > > Hi Jesse, > > thank you for your answer and ideas. > > I have found one kind of solution to patch the transcoder wrap class: > > src\xercesc\util\Transcoders\ICU\ICUTransService.cpp > > > > adding there to constructor of ICUTranscoder::ICUTranscoder these lines: > > > > UErrorCode uerr = U_ZERO_ERROR; > > ucnv_setSubstChars(toAdopt, "?", 1, &uerr); > > ... > > > > Than, the "?" character is used as replacement char, when using icu. > > This is ICU specific solutions and is not clear, because there is necessary > > to rebuild xerces lib. I would like to see some possible switch around > > XMLFormatter class, but there is unknown UConverter form ICU which will be > > used next, because there is nothing to know which transcoder will be called > > later. > Please create a Jira issue because this is a bug. We should not let the > ICU use a replacement character that we know will result in a document > that's not well-formed. > Dave > HISTORY: > > Hi Jesse, > thank you for your answer and ideas. > I have found one kind of solution to patch the transcoder wrap class: > src\xercesc\util\Transcoders\ICU\ICUTransService.cpp > adding there to constructor of ICUTranscoder::ICUTranscoder these lines: > UErrorCode uerr = U_ZERO_ERROR; > ucnv_setSubstChars(toAdopt, "?", 1, &uerr); > ... > Than, the "?" character is used as replacement char, when using icu. > This is ICU specific solutions and is not clear, because there is necessary > to rebuild xerces lib. I would like to see some possible switch around > XMLFormatter class, but there is unknown UConverter form ICU which will be > used next, because there is nothing to know which transcoder will be called > later. > Not optimal, but works. > thank you, > jan > > Původní zpráva > > Od: Jesse Pelton > > Předmět: RE: xerces/ICU unicode alias for weak encoding when > > serializing/converting to CP > > Datum: 16.12.2008 15:31:01 > > > > I'm not an expert on this area, but the transcoders included with Xerces do > > not > > provide any way to specify the replacement character, and ICU may be the > > same. > > Even if ICU gives you a way to do so, I'm not sure how you'd get access to a > > transcoder instance to alter. > > > > Note, though, that 0x1A is not a legal character in an XML document. > > (Oracle's > > parser is correct in rejecting it.) I think it's safe to assume in your > > scenario > > that any such characters in a serialized document are replacements for > > unrepresentable characters. You should therefore be able to post-process the > > serialization output and replace 0x1A with one or more characters of your > > choosing. If you don't want to post-process the whole document, you could > > derive > > an XMLFormatTarget that replaces the replacement character in each chunk of > > data > > handed to it. Neither option is exactly elegant, but I'd probably do the > > latter; > > it'll work regardless of your format target, where the former approach > > requires > > serializing to memory. > > > > > > -Original Message- > > From: Jan Suchý [mailto:zu...@post.cz] > > Sent: Tuesday, December 16, 2008 5:37 AM
[jira] Closed: (XERCESC-1843) Memory fault in DOMImplementationRegistry::getDOMImplementation
[
https://issues.apache.org/jira/browse/XERCESC-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pelton closed XERCESC-1843.
-
Resolution: Invalid
Please post technical support questions on the "users" mailing list. See
http://xerces.apache.org/xerces-c/mailing-lists.html.
> Memory fault in DOMImplementationRegistry::getDOMImplementation
> ---
>
> Key: XERCESC-1843
> URL: https://issues.apache.org/jira/browse/XERCESC-1843
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 2.6.0
> Environment: HP-UX
>Reporter: Ravi Binwade
>Priority: Blocker
>
> Hi,
> I am stuck with memory fault problem in
> DOMImplementationRegistry::getDOMImplementation for last 2 weeks :(
> First , I parse xml buffer string using SAXParser and then create a DOMTree.
> I need to return DOMDocument node from my parse function.
> Following is my code :
> DOMDocument* BaseRecord::Pars(const char* buffer, int length, bool& success)
> {
> DOMDocument* Doc=NULL;
> XMLPlatformUtils::Initialize();
> SAXParser* parser = new SAXParser();
> MemBufInputSource* inputSource = new MemBufInputSource((const
> XMLByte*)buffer,strle(buffer),"test", false);
> parser->parse(*inputSource);
> success=(parser->getErrorCount()==0);
> XMLCh tempStr[100];
> XMLString::transcode("LS", tempStr, 99);
> Wrapper4InputSource domISWrapper(inputSource,false);
> DOMImplementation *impl =
> DOMImplementationRegistry::getDOMImplementation(tempStr); // Segment fault
> here
> DOMBuilder* domparser =
> ((DOMImplementationLS*)impl)->createDOMBuilder(DOMImplementationLS::MODE_SYNCHRONOUS,
> 0);
> Doc = domparser->parse(domISWrapper);
> domparser->release();
> XMLPlatformUtils::Terminate();
> delete parser;
> delete docHandler;
> delete inputSource;
> return Doc;
> }
> Following is data in buffer :
>
>
> event
>
>
> 5
>
>
> I tried using XercesDomParser but found a memory leak in its implementation.
> So , I am left with only option of using SAXParser.
> Can you please help ?
> Many thanks.
> ~ Ravi Binwade
--
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-tabpanel&focusedCommentId=12613303#action_12613303 ] Jesse Pelton commented on XERCESC-1652: --- One reason for using this technique is that it uses standard interfaces. > 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: 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-tabpanel&focusedCommentId=12603876#action_12603876 ] Jesse Pelton commented on XERCESC-1652: --- I'm not tracking 3.0, but I suspect so. I see that you've changed how statics are initialized and cleaned up, but the problem I encountered was with method calls on the static document, not initialization. Among the calls made using the global object: DOMDocumentImpl::cloneString() DOMDocumentImpl::getPooledString() new (DOMDocument *) DOMNamedNodeMapImpl(this) new (DOMDocument *, DOMMemoryManager::DOCUMENT_TYPE_OBJECT) DOMDocumentTypeImpl() I haven't looked at how these are implemented lately. I don't know for sure that they all use member data, but it seems safest to assume that they do. If they don't now, they could at some future time. > 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-1652) DOMDocumentTypeImpl is not thread safe
[ https://issues.apache.org/jira/browse/XERCESC-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pelton updated XERCESC-1652: -- Affects Version/s: 2.8.0 > 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] Commented: (XERCESC-1652) DOMDocumentTypeImpl is not thread safe
[ https://issues.apache.org/jira/browse/XERCESC-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603638#action_12603638 ] Jesse Pelton commented on XERCESC-1652: --- The bug remains in version 2.8. > 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 > 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] Commented: (XERCESC-1738) Please support forward slashes for UNC file names
[ https://issues.apache.org/jira/browse/XERCESC-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520601 ] Jesse Pelton commented on XERCESC-1738: --- I'm not sure why leading backslashes are supported; they're not legal in URIs (see http://www.faqs.org/rfcs/rfc3986.html). If I had to guess, it's a convenience feature. Personally, I think such features are misguided, as they contribute to confusion. UNC paths are not URIs, and programs that hide the difference encourage people to think that they're equivalent. > Please support forward slashes for UNC file names > - > > Key: XERCESC-1738 > URL: https://issues.apache.org/jira/browse/XERCESC-1738 > Project: Xerces-C++ > Issue Type: Wish > Components: Utilities >Affects Versions: 2.7.0 > Environment: WinXP, Vista >Reporter: Soren Soe > > XercesDOMParser cannot parse/open XML documents specified in UNC path if the > path uses forward slashes. > For example //server/directory/file.xml causes a SAXParseExecption to be > thrown. > I am not clear on the exact requirements of the UNC format (are forward > slashes even allowed), but nevertheless, most windows tools today support > both forward and backwards slashes. > I debugged through the code. UNC file paths with forward slashes could be > supported easily with an extra test for two forward slashes added to > XMLPlatformUtils::isRelative() in win32platformutils.cpp. > bool XMLPlatformUtils::isRelative(const XMLCh* const toCheck > , MemoryManager* const /*manager*/) > ... > // > // If it starts with a double slash, then it cannot be relative since > // it's a remote file. > // > if (isBackSlash(toCheck[0]) && isBackSlash(toCheck[1])) > return false; > ... > It appears all that is needed is to check for two forward slashes also. > Thank you. > Soren Soe -- 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-1738) Please support forward slashes for UNC file names
[ https://issues.apache.org/jira/browse/XERCESC-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520529 ] Jesse Pelton commented on XERCESC-1738: --- UNC paths are file paths, so a UNC URL must use the file: protocol. The protocol in a URL is always followed by two slashes, so your URL has to begin with "file://". There's a fair amount of disgreement about what follows, but one convention seems to have it that you then indicate the root of the directory file system with another slash, then the UNC path with backslashes replaced by forward slashes. (Note that backslashes are not allowed in URLs.) So, many consumers of network resources retrieved by URL would understand file:/server/directory/file.xml. Others allow two less slashes: file:///server/directory/file.xml. I'm pretty sure Xerces understands the former. > Please support forward slashes for UNC file names > - > > Key: XERCESC-1738 > URL: https://issues.apache.org/jira/browse/XERCESC-1738 > Project: Xerces-C++ > Issue Type: Wish > Components: Utilities >Affects Versions: 2.7.0 > Environment: WinXP, Vista >Reporter: Soren Soe > > XercesDOMParser cannot parse/open XML documents specified in UNC path if the > path uses forward slashes. > For example //server/directory/file.xml causes a SAXParseExecption to be > thrown. > I am not clear on the exact requirements of the UNC format (are forward > slashes even allowed), but nevertheless, most windows tools today support > both forward and backwards slashes. > I debugged through the code. UNC file paths with forward slashes could be > supported easily with an extra test for two forward slashes added to > XMLPlatformUtils::isRelative() in win32platformutils.cpp. > bool XMLPlatformUtils::isRelative(const XMLCh* const toCheck > , MemoryManager* const /*manager*/) > ... > // > // If it starts with a double slash, then it cannot be relative since > // it's a remote file. > // > if (isBackSlash(toCheck[0]) && isBackSlash(toCheck[1])) > return false; > ... > It appears all that is needed is to check for two forward slashes also. > Thank you. > Soren Soe -- 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-1736) xml document validation againsta schema
[ https://issues.apache.org/jira/browse/XERCESC-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520212 ] Jesse Pelton commented on XERCESC-1736: --- Denis, Xerces being open source, anyone can offer improvements, and I wanted to make sure you knew that changes are more likely to occur when someone offers the code. I initially suggested that you create a patch before I knew David had updated the documentation, and it's still an option. However, for your patch to be applied, you would need to make a compelling case for changing the behavior and updating the documentation again. Your case would have to be strong because while anyone can offer a patch, a relatively small number of people are authorized to commit changes, and they'd have to be convinced that the change is a good idea. Personally, I would not offer such a patch. I think the current behavior is intentional and well-designed, and I suspect most or all of the committers would agree. > xml document validation againsta schema > --- > > Key: XERCESC-1736 > URL: https://issues.apache.org/jira/browse/XERCESC-1736 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD), Validating Parser (Schema) > (Xerces 1.5 or up only) >Affects Versions: 2.7.0 > Environment: Windows XP professional > Visual Studio 2005 >Reporter: Denis Tkachov > > Instances of both XercesDOMParser and SAX2XMLReader threat all the > documents as valid even if a document does not match schema provided. > In order if document does not match schema provided the library does not > throw exception and getErrorCount method of the parser returns zero. > So it seems to be a bug in the library. > As example you can try this code: > http://xml.apache.org/xerces-c/program-dom.html#ConstructXercesDOMParser > Below are provided scheme and document (error marked with "does not match > schema" comment) that reproduces error: > datasetSchema.xsd: > > http://www.w3.org/2001/XMLSchema";> > > > > > > >type="xs:int"/> >type="xs:string"/> >name="surname" type="xs:string"/> > > > > > > >type="xs:int"/> >type="xs:string"/> >type="xs:string"/> > > > > > > > > output.xml: > > http://creopod.com/DataObject.xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"; > xs:noNamespaceSchemaLocation="datasetSchema.xsd"> > > 1 > Vasya > Pupkin > > > 2 > Petro > Kukurudza > > > 1 > 23 > famous guy > > > 2 > 29 > > > -- 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-1736) xml document validation againsta schema
[
https://issues.apache.org/jira/browse/XERCESC-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519938
]
Jesse Pelton commented on XERCESC-1736:
---
Denis,
When I asked whether you could create a patch, what I meant was whether you
could create a patch file ("unified diff" is the preferred format, I think)
that could be applied to the most recent version of the code to produce the
behavior you think is correct. In short, I was suggesting that you submit code
that fixes the problem as you see it.
Since David has already updated the documentation to agree with the code's
behavior, the behavior is unlikely to change unless someone a) makes a strong
case for changing the behavior and b) offers code that implements the new
behavior.
Personally, I think the current behavior is preferable. I don't want Xerces (or
any other tool) to perform time-consuming operations like fetching schemas and
validating documents unless I explicitly ask it to.
> xml document validation againsta schema
> ---
>
> Key: XERCESC-1736
> URL: https://issues.apache.org/jira/browse/XERCESC-1736
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (DTD), Validating Parser (Schema)
> (Xerces 1.5 or up only)
>Affects Versions: 2.7.0
> Environment: Windows XP professional
> Visual Studio 2005
>Reporter: Denis Tkachov
>
> Instances of both XercesDOMParser and SAX2XMLReader threat all the
> documents as valid even if a document does not match schema provided.
> In order if document does not match schema provided the library does not
> throw exception and getErrorCount method of the parser returns zero.
> So it seems to be a bug in the library.
> As example you can try this code:
> http://xml.apache.org/xerces-c/program-dom.html#ConstructXercesDOMParser
> Below are provided scheme and document (error marked with "does not match
> schema" comment) that reproduces error:
> datasetSchema.xsd:
>
> http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>type="xs:int"/>
>type="xs:string"/>
>name="surname" type="xs:string"/>
>
>
>
>
>
>
>type="xs:int"/>
>type="xs:string"/>
>type="xs:string"/>
>
>
>
>
>
>
>
> output.xml:
>
> http://creopod.com/DataObject.xsd";
> xmlns:xs="http://www.w3.org/2001/XMLSchema-instance";
> xs:noNamespaceSchemaLocation="datasetSchema.xsd">
>
> 1
> Vasya
> Pupkin
>
>
> 2
> Petro
> Kukurudza
>
>
> 1
> 23
> famous guy
>
>
> 2
> 29
>
>
>
--
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-1736) xml document validation againsta schema
[ https://issues.apache.org/jira/browse/XERCESC-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519729 ] Jesse Pelton commented on XERCESC-1736: --- David, Denis cited incomplete instructions on schema.html. It looks to me like schema.xml remains to be updated. > xml document validation againsta schema > --- > > Key: XERCESC-1736 > URL: https://issues.apache.org/jira/browse/XERCESC-1736 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD), Validating Parser (Schema) > (Xerces 1.5 or up only) >Affects Versions: 2.7.0 > Environment: Windows XP professional > Visual Studio 2005 >Reporter: Denis Tkachov > > Instances of both XercesDOMParser and SAX2XMLReader threat all the > documents as valid even if a document does not match schema provided. > In order if document does not match schema provided the library does not > throw exception and getErrorCount method of the parser returns zero. > So it seems to be a bug in the library. > As example you can try this code: > http://xml.apache.org/xerces-c/program-dom.html#ConstructXercesDOMParser > Below are provided scheme and document (error marked with "does not match > schema" comment) that reproduces error: > datasetSchema.xsd: > > http://www.w3.org/2001/XMLSchema";> > > > > > > >type="xs:int"/> >type="xs:string"/> >name="surname" type="xs:string"/> > > > > > > >type="xs:int"/> >type="xs:string"/> >type="xs:string"/> > > > > > > > > output.xml: > > http://creopod.com/DataObject.xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"; > xs:noNamespaceSchemaLocation="datasetSchema.xsd"> > > 1 > Vasya > Pupkin > > > 2 > Petro > Kukurudza > > > 1 > 23 > famous guy > > > 2 > 29 > > > -- 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-1736) xml document validation againsta schema
[ https://issues.apache.org/jira/browse/XERCESC-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519666 ] Jesse Pelton commented on XERCESC-1736: --- Can you create a patch? If so, it might make it into the recently proposed 2.8.0 release. > xml document validation againsta schema > --- > > Key: XERCESC-1736 > URL: https://issues.apache.org/jira/browse/XERCESC-1736 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD), Validating Parser (Schema) > (Xerces 1.5 or up only) >Affects Versions: 2.7.0 > Environment: Windows XP professional > Visual Studio 2005 >Reporter: Denis Tkachov > > Instances of both XercesDOMParser and SAX2XMLReader threat all the > documents as valid even if a document does not match schema provided. > In order if document does not match schema provided the library does not > throw exception and getErrorCount method of the parser returns zero. > So it seems to be a bug in the library. > As example you can try this code: > http://xml.apache.org/xerces-c/program-dom.html#ConstructXercesDOMParser > Below are provided scheme and document (error marked with "does not match > schema" comment) that reproduces error: > datasetSchema.xsd: > > http://www.w3.org/2001/XMLSchema";> > > > > > > >type="xs:int"/> >type="xs:string"/> >name="surname" type="xs:string"/> > > > > > > >type="xs:int"/> >type="xs:string"/> >type="xs:string"/> > > > > > > > > output.xml: > > http://creopod.com/DataObject.xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"; > xs:noNamespaceSchemaLocation="datasetSchema.xsd"> > > 1 > Vasya > Pupkin > > > 2 > Petro > Kukurudza > > > 1 > 23 > famous guy > > > 2 > 29 > > > -- 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-1736) xml document validation againsta schema
[ https://issues.apache.org/jira/browse/XERCESC-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519461 ] Jesse Pelton commented on XERCESC-1736: --- I just noticed the difference between what you did and what I did: I removed the default namespace from the instance document, not the schema. > xml document validation againsta schema > --- > > Key: XERCESC-1736 > URL: https://issues.apache.org/jira/browse/XERCESC-1736 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD), Validating Parser (Schema) > (Xerces 1.5 or up only) >Affects Versions: 2.7.0 > Environment: Windows XP professional > Visual Studio 2005 >Reporter: Denis Tkachov > > Instances of both XercesDOMParser and SAX2XMLReader threat all the > documents as valid even if a document does not match schema provided. > In order if document does not match schema provided the library does not > throw exception and getErrorCount method of the parser returns zero. > So it seems to be a bug in the library. > As example you can try this code: > http://xml.apache.org/xerces-c/program-dom.html#ConstructXercesDOMParser > Below are provided scheme and document (error marked with "does not match > schema" comment) that reproduces error: > datasetSchema.xsd: > > http://www.w3.org/2001/XMLSchema";> > > > > > > >type="xs:int"/> >type="xs:string"/> >name="surname" type="xs:string"/> > > > > > > >type="xs:int"/> >type="xs:string"/> >type="xs:string"/> > > > > > > > > output.xml: > > http://creopod.com/DataObject.xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"; > xs:noNamespaceSchemaLocation="datasetSchema.xsd"> > > 1 > Vasya > Pupkin > > > 2 > Petro > Kukurudza > > > 1 > 23 > famous guy > > > 2 > 29 > > > -- 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-1736) xml document validation againsta schema
[ https://issues.apache.org/jira/browse/XERCESC-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519458 ] Jesse Pelton commented on XERCESC-1736: --- I used the DOMPrint sample app with the following command line: DOMPrint -n -s -f -v=always output.xml When I ran it against the original output.xml, I got the following output: Error at file "D:\test/output.xml", line 2, column 157 Message: Unknown element 'DataObject' I then removed the default namespace, so the second line of the document became as follows: http://www.w3.org/2001/XMLSchema-instance"; xs:noNamespaceSchemaLocation="datasetSchema.xsd"> DOMPrint then produce the following, which looks correct to me: Error at file "D:\test/output.xml", line 14, column 11 Message: Unknown element 'key1' Error at file "D:\test/output.xml", line 17, column 20 Message: Element 'key1' is not valid for content model: '((key,age),info)' Error at file "D:\test/output.xml", line 19, column 11 Message: Unknown element 'key1' Error at file "D:\test/output.xml", line 22, column 20 Message: Element 'key1' is not valid for content model: '((key,age),info)' I got the same results with both v2.5 and v2.7 of the software. I was apparently wrong about the need to change the schema URI on my machine. > xml document validation againsta schema > --- > > Key: XERCESC-1736 > URL: https://issues.apache.org/jira/browse/XERCESC-1736 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD), Validating Parser (Schema) > (Xerces 1.5 or up only) >Affects Versions: 2.7.0 > Environment: Windows XP professional > Visual Studio 2005 >Reporter: Denis Tkachov > > Instances of both XercesDOMParser and SAX2XMLReader threat all the > documents as valid even if a document does not match schema provided. > In order if document does not match schema provided the library does not > throw exception and getErrorCount method of the parser returns zero. > So it seems to be a bug in the library. > As example you can try this code: > http://xml.apache.org/xerces-c/program-dom.html#ConstructXercesDOMParser > Below are provided scheme and document (error marked with "does not match > schema" comment) that reproduces error: > datasetSchema.xsd: > > http://www.w3.org/2001/XMLSchema";> > > > > > > >type="xs:int"/> >type="xs:string"/> >name="surname" type="xs:string"/> > > > > > > >type="xs:int"/> >type="xs:string"/> >type="xs:string"/> > > > > > > > > output.xml: > > http://creopod.com/DataObject.xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"; > xs:noNamespaceSchemaLocation="datasetSchema.xsd"> > > 1 > Vasya > Pupkin > > > 2 > Petro > Kukurudza > > > 1 > 23 > famous guy > > > 2 > 29 > > > -- 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-1736) xml document validation againsta schema
[ https://issues.apache.org/jira/browse/XERCESC-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pelton resolved XERCESC-1736. --- Resolution: Invalid I see two problems with your test case, one of which masks the other, at least on my machine. First, the DataObject in the instance document is in the namespace "http://creopod.com/DataObject.xsd";, but there is no namespace associated with the schema. The DataObject in the schema therefore has no relationship to the DataObject in the instance document. Likewise for other elements. Second, the URL for the schema may not resolve as you expect (it didn't on my machine). If it doesn't, the schema won't load, and no validation can occur. I used the DOMPrint sample (admittedly the 2.5 version, but I have no reason to think core functionality broke between 2.5 and 2.7) to test. Once I revised the instance document to use a known good URL for the schema location and removed the default namespace declaration, DOMPrint reported the errors one would expect. > xml document validation againsta schema > --- > > Key: XERCESC-1736 > URL: https://issues.apache.org/jira/browse/XERCESC-1736 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD), Validating Parser (Schema) > (Xerces 1.5 or up only) >Affects Versions: 2.7.0 > Environment: Windows XP professional > Visual Studio 2005 >Reporter: Denis Tkachov > > Instances of both XercesDOMParser and SAX2XMLReader threat all the > documents as valid even if a document does not match schema provided. > In order if document does not match schema provided the library does not > throw exception and getErrorCount method of the parser returns zero. > So it seems to be a bug in the library. > As example you can try this code: > http://xml.apache.org/xerces-c/program-dom.html#ConstructXercesDOMParser > Below are provided scheme and document (error marked with "does not match > schema" comment) that reproduces error: > datasetSchema.xsd: > > http://www.w3.org/2001/XMLSchema";> > > > > > > >type="xs:int"/> >type="xs:string"/> >name="surname" type="xs:string"/> > > > > > > >type="xs:int"/> >type="xs:string"/> >type="xs:string"/> > > > > > > > > output.xml: > > http://creopod.com/DataObject.xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"; > xs:noNamespaceSchemaLocation="datasetSchema.xsd"> > > 1 > Vasya > Pupkin > > > 2 > Petro > Kukurudza > > > 1 > 23 > famous guy > > > 2 > 29 > > > -- 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-1385) UTF8 parse failure when there's a bom in the utf8 header
[
https://issues.apache.org/jira/browse/XERCESC-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518516
]
Jesse Pelton commented on XERCESC-1385:
---
That's a question for one of the mailing lists.
> UTF8 parse failure when there's a bom in the utf8 header
>
>
> Key: XERCESC-1385
> URL: https://issues.apache.org/jira/browse/XERCESC-1385
> Project: Xerces-C++
> Issue Type: Bug
> Components: SAX/SAX2
>Affects Versions: 2.6.0
> Environment: OSX, CodeWarrior 9.4
>Reporter: Miklos Fazekas
> Attachments: test.cpp
>
>
> This issue probably related to 1284. (Or a duplicate of it)
> The attached sample code failes with Xerces2.6.
> The problem seems to be that there's double checing for the utf8 bom. Bellow
> is a patch to XMLParser.cpp that resolves this issue. [ The bug is that we've
> already detected utf8 bom and modified fRawBufIndex, but the seconds check
> doesn't takes it into accout. ]
> src/xercesc/internal/XMLReader.cpp
> @@ -544,7 +544,7 @@
> }
> // If there's a utf-8 BOM (0xEF 0xBB 0xBF), skip past it.
> else {
> -const char* asChars = (const char*)fRawByteBuf;
> +const char* asChars = (const char*)(fRawByteBuf +
> fRawBufIndex);
> if ((fRawBytesAvail > XMLRecognizer::fgUTF8BOMLen )&&
> (XMLString::compareNString( asChars
> , XMLRecognizer::fgUTF8BOM
> It's also possible that we should check if we detected an utf8 bom already as
> the following code would probably allow a double utf8 bom.
--
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-1284) Set "UTF-16" encoding for UTF16-BE entity with BOM results in parse failure
[ https://issues.apache.org/jira/browse/XERCESC-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518487 ] Jesse Pelton commented on XERCESC-1284: --- This was fixed after 2.7 was released. The relevant commit appears to be 378729. See http://svn.apache.org/viewvc?view=rev&revision=378729 > Set "UTF-16" encoding for UTF16-BE entity with BOM results in parse failure > --- > > Key: XERCESC-1284 > URL: https://issues.apache.org/jira/browse/XERCESC-1284 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 2.7.0 > Environment: Fedora Core 1, x86 PC, gcc. Also seen similar failures > in a Solaris 9 environment with the forte compiler. >Reporter: Daniel McLean > Attachments: MemParseEncoding.tar.gz, utf8BOMTest.tar.gz > > > Setting the encoding as "UTF-16" using the InputSource.setEncoding() method > seems to create problems during parsing. > If I have a UTF-16BE document with a BOM, this parses successfully when no > encoding set is explicitly set or when the encoding is set to "UTF-16BE". > When set to "UTF-16", a fatal error occurs with: >Fatal Error at (file test, line 1, char 1): Invalid document structure > Some investigation: Having looked through the Xerces source and done some > testing, it appears that when "UTF-16BE" is set, the "UTF-16 (BE)" transcoder > is used when a match is detected against the known encoding string. When > "UTF-16" is set, no known encoding is detected and the document is probed for > an encoding, resulting in the XMLUTF16Transcoder being used. In the latter > case, when XMLScanner::scanProlog() is called, it ends up reading the BOM and > choking because it doesn't look like a piece of prologue. I'm guessing that > either the trancoder should have removed the BOM, the BOM should be detected > and ignored, or the BOM should have been trimmed off beforehand. > I've attached a test case which is derived from the MemParse sample, which > parses four different UTF-16 document (BE with BOM, BE without BOM, LE with > BOM, LE without BOM (I realise UTF-16 XML entities should have a BOM, but in > my case I want to know what happens if a client of my software feeds in a > UTF-16 document without a BOM) using four different encoding approaches (no > encoding set, "UTF-16", "UTF-16BE", "UTF-16LE"). > A summary of parsing success and failure on linux: > FILE: UTF-16BE with BOM > ENCODING: : Succeeded. > ENCODING: UTF-16: Fatal error. > ENCODING: UTF-16BE: Succeeded. > ENCODING: UTF-16LE: Fatal error. > > FILE: UTF-16BE without BOM > ENCODING: Fatal error. (due to guess of UTF-8) > ENCODING: UTF-16: Succeeded. > ENCODING: UTF-16BE: Succeeded. > ENCODING: UTF-16LE: Fatal error. > > FILE: UTF-16LE with BOM > ENCODING: : Succeeded. > ENCODING: UTF-16: Fatal error. > ENCODING: UTF-16BE: Fatal error. > ENCODING: UTF-16LE: Succeeded. > > FILE: UTF-16LE with BOM > ENCODING: : Fatal error. (due to guess of UTF-8) > ENCODING: UTF-16: Succeeded. > ENCODING: UTF-16BE: Fatal error. > ENCODING: UTF-16LE: Succeeded. > > Maybe there is a good reason for Xerces current behaviour, but it > escapes me. I note that the lack of BOM helps parser success > when setting an encoding of "UTF-16", supporting my assertion above. -- 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-1385) UTF8 parse failure when there's a bom in the utf8 header
[
https://issues.apache.org/jira/browse/XERCESC-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518485
]
Jesse Pelton commented on XERCESC-1385:
---
This was fixed after 2.7 was released.
The relevant commit appears to be 381685; see
http://svn.apache.org/viewvc?view=rev&revision=381685
> UTF8 parse failure when there's a bom in the utf8 header
>
>
> Key: XERCESC-1385
> URL: https://issues.apache.org/jira/browse/XERCESC-1385
> Project: Xerces-C++
> Issue Type: Bug
> Components: SAX/SAX2
>Affects Versions: 2.6.0
> Environment: OSX, CodeWarrior 9.4
>Reporter: Miklos Fazekas
> Attachments: test.cpp
>
>
> This issue probably related to 1284. (Or a duplicate of it)
> The attached sample code failes with Xerces2.6.
> The problem seems to be that there's double checing for the utf8 bom. Bellow
> is a patch to XMLParser.cpp that resolves this issue. [ The bug is that we've
> already detected utf8 bom and modified fRawBufIndex, but the seconds check
> doesn't takes it into accout. ]
> src/xercesc/internal/XMLReader.cpp
> @@ -544,7 +544,7 @@
> }
> // If there's a utf-8 BOM (0xEF 0xBB 0xBF), skip past it.
> else {
> -const char* asChars = (const char*)fRawByteBuf;
> +const char* asChars = (const char*)(fRawByteBuf +
> fRawBufIndex);
> if ((fRawBytesAvail > XMLRecognizer::fgUTF8BOMLen )&&
> (XMLString::compareNString( asChars
> , XMLRecognizer::fgUTF8BOM
> It's also possible that we should check if we detected an utf8 bom already as
> the following code would probably allow a double utf8 bom.
--
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-1691) Sometimes DOMBuilder::parseURI() function returns null.
[ https://issues.apache.org/jira/browse/XERCESC-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486009 ] Jesse Pelton commented on XERCESC-1691: --- Note also that there's a helpful mailing list. You're more likely to get assistance with this sort of problem there, and perhaps you will discover that the bug is in fact in your code. Alberto's comments regarding the information you should provide is valid in any case. > Sometimes DOMBuilder::parseURI() function returns null. > > > Key: XERCESC-1691 > URL: https://issues.apache.org/jira/browse/XERCESC-1691 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 2.7.0 > Environment: Microsoft Windows xp professional/version 20002/ SP2, > Visual studio 2005 SP1, Pantium 4 processor, 504MB RAM >Reporter: bhaskar bhagawati > Fix For: 2.7.0 > > > I read to and write from an xml file repeatedly from different threads. For > reading and writing I use DOMBuilder::parseURI function, > DOMWriter::writeNode function and LocalFileFormatTarget class object. I have > used ACE_Thread_Mutex in my program, so that if one thread is reading or > writing to the xml file, no other thread can read or write to the file. > Sometimes parseURI function returns null. And also sometimes my program > crashes while creating LocalFileFormatTarget class object. -- 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-1687) Problem with euro symbol in DOM
[ https://issues.apache.org/jira/browse/XERCESC-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pelton resolved XERCESC-1687. --- Resolution: Invalid Please do not use the bug database to ask questions. There is a mailing list for that purpose. > Problem with euro symbol in DOM > --- > > Key: XERCESC-1687 > URL: https://issues.apache.org/jira/browse/XERCESC-1687 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 2.7.0 > Environment: linux debian 3.1 x86 >Reporter: jose > Fix For: 2.7.0 > > > How can I create a DOMDocument where a DOMWriter process results as follows: > > >€ > > I have tried using the createEntityReference() function but the resulting xml > does not validate with the corresponding xsd. The euro_symbol element is a > simple string. > Thanks -- 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-1687) Problem with euro symbol in DOM
[ https://issues.apache.org/jira/browse/XERCESC-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pelton closed XERCESC-1687. - > Problem with euro symbol in DOM > --- > > Key: XERCESC-1687 > URL: https://issues.apache.org/jira/browse/XERCESC-1687 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 2.7.0 > Environment: linux debian 3.1 x86 >Reporter: jose > Fix For: 2.7.0 > > > How can I create a DOMDocument where a DOMWriter process results as follows: > > >€ > > I have tried using the createEntityReference() function but the resulting xml > does not validate with the corresponding xsd. The euro_symbol element is a > simple string. > Thanks -- 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
[ http://issues.apache.org/jira/browse/XERCESC-1652?page=all ] Jesse Pelton updated XERCESC-1652: -- Attachment: DOMDocumentTypeImpl.diff > DOMDocumentTypeImpl is not thread safe > -- > > Key: XERCESC-1652 > URL: http://issues.apache.org/jira/browse/XERCESC-1652 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 2.7.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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1652) DOMDocumentTypeImpl is not thread safe
DOMDocumentTypeImpl is not thread safe -- Key: XERCESC-1652 URL: http://issues.apache.org/jira/browse/XERCESC-1652 Project: Xerces-C++ Issue Type: Bug Components: DOM Affects Versions: 2.7.0 Environment: Multithreaded programs Reporter: Jesse Pelton 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1642) My application crashed on Solaris Sparc (64bit) using compiler CC(Sun C++ 5.5 Patch 113817-14 2005/07/19 ) and OS 5.8
[ http://issues.apache.org/jira/browse/XERCESC-1642?page=comments#action_12451665 ] Jesse Pelton commented on XERCESC-1642: --- Including the text of your schema and/or instance documents in the bug report is not useful; it's possible that the bits are not the same as those in the actual documents. That's why Alberto asked that you attach them (using the "Attach file" operation) to the report. I'd suggest trying to parse your document with one or more of the sample apps, like SAXPrint. If that fails, something is probably wrong with the library; otherwise, it's probably in your code. If you want useful diagnostic assistance, attaching code for a small but complete program that demonstrates the problem is the best way to get it. I do wonder why you're specifying UTF-16 in your code for a document that specifies UTF-8, though. > My application crashed on Solaris Sparc (64bit) using compiler CC(Sun C++ 5.5 > Patch 113817-14 2005/07/19 ) and OS 5.8 > - > > Key: XERCESC-1642 > URL: http://issues.apache.org/jira/browse/XERCESC-1642 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 2.7.0 > Environment: OS : SunOS 5.8 Generic_108528-24 sun4u sparc > SUNW,Sun-Fire-V440 Solaris > Compiler : CC: Sun C++ 5.5 Patch 113817-14 2005/07/19 > Xercers: xercesc_2_7 >Reporter: Riaj Mohammed >Priority: Critical > > I have build the xerces library successfully on solaris 64 bit, but at the > run time, I get a SIGBUS > > The stack trace is > > signal BUS (invalid address alignment) in realfree at 0x77d4a2ec > 0x77d4a2ec: realfree+0x0078:ldx [%i0 + 16], %o1 > Current function is xercesc_2_7::MemoryManagerImpl::deallocate >47 ::operator delete(p); > > > [1] realfree(0x107eb2524, 0x77ec1780, 0x107eb1990, > 0x77eb4f60, 0x107eb1980, 0xba7) > [2] _free_unlocked(0x77ec1668, 0x77eb4f60, 0x1080098b0, > 0x785069c4, 0x1080 > [3] free(0x1080098b0, 0x0, 0x106c5c460, 0x785069c4, > 0x7ef013c0, 0x0), at 0xfff > [4] operator delete(0x1080098b0, 0x106c5c4b0, 0xe, 0x785069c4, > 0x7f72c930, 0x0), a > =>[5] xercesc_2_7::MemoryManagerImpl::deallocate(this = 0x106c06b30, p = > 0x1080098b0), line 47 in "M > [6] xercesc_2_7::XMLBuffer::~XMLBuffer(this = 0x108009838), line 76 in > "XMLBuffer.hpp" > [7] xercesc_2_7::SchemaValidator::~SchemaValidator(this = 0x1080097d8), > line 340 in "SchemaValidat > [8] __SLIP.DELETER__L(0x1080097d8, 0x1, 0x7dc000e8, > 0x785069c4, 0x765f0024, 0x0), > [9] xercesc_2_7::IGXMLScanner::cleanUp(this = 0x1080043a8), line 559 in > "IGXMLScanner.cpp" > [10] xercesc_2_7::IGXMLScanner::~IGXMLScanner(this = 0x1080043a8), line 158 > in "IGXMLScanner.cpp" > [11] __SLIP.DELETER__P(0x1080043a8, 0x1, 0x7f72c930, > 0x7ef013c0, 0x7ef013c > [12] xercesc_2_7::AbstractDOMParser::cleanUp(this = 0x7ffedfb0), > line 160 in "AbstractDOMP > [13] xercesc_2_7::AbstractDOMParser::~AbstractDOMParser(this = > 0x7ffedfb0), line 128 in "A > [14] xercesc_2_7::XercesDOMParser::~XercesDOMParser(this = > 0x7ffedfb0), line 65 in "Xerces > [15] xercesc_2_7::XSDDOMParser::~XSDDOMParser(this = 0x7ffedfb0), > line 64 in "XSDDOMParser > [16] xercesc_2_7::IGXMLScanner::resolveSchemaGrammar(this = 0x107fcefb8, > loc = 0x107fd5fa0, uri = > [17] xercesc_2_7::IGXMLScanner::scanRawAttrListforNameSpaces(this = > 0x107fcefb8, attCount = 2), li > [18] xercesc_2_7::IGXMLScanner::scanStartTagNS(this = 0x107fcefb8, gotData > = true), line 2211 in " > [19] xercesc_2_7::IGXMLScanner::scanContent(this = 0x107fcefb8), line 889 > in "IGXMLScanner.cpp" > [20] xercesc_2_7::IGXMLScanner::scanDocument(this = 0x107fcefb8, src = > CLASS), line 213 in "IGXMLS > [21] xercesc_2_7::SAXParser::parse(this = 0x107fcdd08, source = CLASS), > line 544 in "SAXParser.cpp > > If you know regarding this problem please send me the details > Thanks in advance > -Riaj > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1606) Failing in parsing Unicode XML file
[ http://issues.apache.org/jira/browse/XERCESC-1606?page=all ]
Jesse Pelton closed XERCESC-1606:
-
Resolution: Invalid
Please use the mailing lists for questions about using Xerces. See
http://xml.apache.org/mail.html#xerces-c-user.
> Failing in parsing Unicode XML file
> ---
>
> Key: XERCESC-1606
> URL: http://issues.apache.org/jira/browse/XERCESC-1606
> Project: Xerces-C++
> Type: Bug
> Components: SAX/SAX2
> Versions: 1.7.0
> Environment: Operating System: Linux, Kernel Version:2.4 Software: xerces
> 1.7.0
> Reporter: Shailendra Verma
> Attachments: VXIlog.txt, test1012.1.vxml
>
> Hello all,
> I am using xerces 1.7.0 and want to parse the following page in Unicode
> format.
>
>
>
>
>
>
> ???
>
>
>
>
>
> while parsing it is failing in parse->parse ( ) and caught by catch (const
> SAXParseException & exception) .
> Can anyone give me idea about which version of xerces-c can be used to parse
> Unicode file?
> Waiting for responses from you.
> Thanx & Rgds,
> Shailendra
>
> try {
> if (isDefaults && lastParse != DocumentParser::DEFAULTS) {
> parser->parse(MemBufInputSource(DUMMY_VXML_DEFAULTS_DOC,
> DUMMY_VXML_DEFAULTS_DOC_SIZE,
> "vxml 1.0 defaults"), false);
> lastParse = DocumentParser::DEFAULTS;
> }
> else if (!isDefaults && lastParse != DocumentParser::DOCUMENT) {
> parser->parse(MemBufInputSource(DUMMY_VXML_DOC, DUMMY_VXML_DOC_SIZE,
> "vxml 1.0 dtd"), false);
> lastParse = DocumentParser::DOCUMENT;
> }
> }
> catch (const SAXParseException & exception) {
> log.StartDiagnostic(0) << L"DocumentParser::FetchDocument - Parse error "
><< L"in file \""
><< XMLChToVXIchar(exception.getSystemId())
><< L"\", line " << exception.getLineNumber()
><< L", column " << exception.getColumnNumber()
><< L" - " <<
> XMLChToVXIchar(exception.getMessage());
> log.EndDiagnostic();
> log.LogError(999, SimpleLogger::MESSAGE, L"unable to load VXML DTD");
> return 4;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1601) SAX2 Parser throws an uncaught xercesc_2_7::XMLValid::Codes exception when setValidationConstraintFatal is on with enclosing xml tags
[
http://issues.apache.org/jira/browse/XERCESC-1601?page=comments#action_12414976
]
Jesse Pelton commented on XERCESC-1601:
---
I'll respond on the mailing list. It's not clear that this is a bug.
> SAX2 Parser throws an uncaught xercesc_2_7::XMLValid::Codes exception when
> setValidationConstraintFatal is on with enclosing xml tags
> -
>
> Key: XERCESC-1601
> URL: http://issues.apache.org/jira/browse/XERCESC-1601
> Project: Xerces-C++
> Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> 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:
> 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">
>
>
>
>
>
>
>
>
>
>
>
> 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.
> 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">
>
>
>
>
>
>
> 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:
>
>
> Module entry
> declaration
>
>
>use="required"/>
>
>
>
>value="DIRECTORY"/>
>value="ENVIRONMENT"/>
>value="STREAMEVENTS"/>
>value="OPENTV_RESOURCE"/>
>value="SYS42_RESOURCE"/>
>value="PROPRIETARY_RESOURCE"/>
>
>
>value="VERSIONED_RAW"/>
>
>
>
>use="required"/>
>
>
> 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();
> parser->setFeature(XMLUni::fgSAX2CoreValidation, true);
> parser->setFeature(XMLUni::fgSAX2CoreNameSpaces, true);
> parser->setFeature(XMLUni::fgXercesSchema, true);
> parser->setFeature(XMLUni::fgXercesSchemaFullChecking, true);
> parser->setValidationConstraintFatal(true);
> string schemaLocation = "http://www.rd.bbc.co.uk/dtv/wp4/System42 ";
> char *unixPath = strdup(sXsdPath);
> for (size_t i = 0; i < strlen(unixPath) - 1; i++)
> if (unixPath[i] == '\\')
> unixPath[i] = '/';
> schemaLocation += unixPath;
> free(unixPath);
> parser->setProperty(XMLUni::fgXercesSchemaExternalSchemaLocation,
> XMLString::transcode(schemaLocation.c_str()));
> parser->setContentHandler(this);
> parser->setErrorHandler(this);
> try
> {
> parser->parse(sFilename);
> }
> catch (const XMLException& e) {
> std::string message = m_sFilename + ":XML exception:" +
> XMLtoString(e.getMessage());
> Logger::StoreError( message.c_str() );
> return false;
> }
> catch (const SAXParseException& e) {
> std::string messa
[jira] Commented: (XERCESC-1601) SAX2 Parser throws an uncaught xercesc_2_7::XMLValid::Codes exception when setValidationConstraintFatal is on with enclosing xml tags
[
http://issues.apache.org/jira/browse/XERCESC-1601?page=comments#action_12414957
]
Jesse Pelton commented on XERCESC-1601:
---
It looks to me like the Java app is creating documents that are schema-invalid.
The schema doesn't appear to allow ModuleEntry to have character content, and
the offending documents have white space content between the opening and
closing tags. If you hack up one of these documents to remove the whitespace
(so you have lines like ""), I imagine they'll parse successfully.
If I'm right, you can a) fix the app to generate schema-valid documents, b)
update the schema to allow character content, or c) skip validating when
parsing. There may be a way to get the parser to detect ignorable whitespace
and ignore it (which may be what XMLSpy is doing), but I couldn't find it in a
quick search.
In short, it looks to me like there's no bug here, but I'll leave it open in
case someone with more knowledge thinks otherwise.
> SAX2 Parser throws an uncaught xercesc_2_7::XMLValid::Codes exception when
> setValidationConstraintFatal is on with enclosing xml tags
> -
>
> Key: XERCESC-1601
> URL: http://issues.apache.org/jira/browse/XERCESC-1601
> Project: Xerces-C++
> Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> 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:
> 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">
>
>
>
>
>
>
>
>
>
>
>
> 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.
> 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">
>
>
>
>
>
>
> 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:
>
>
> Module entry
> declaration
>
>
>use="required"/>
>
>
>
>value="DIRECTORY"/>
>value="ENVIRONMENT"/>
>value="STREAMEVENTS"/>
>value="OPENTV_RESOURCE"/>
>value="SYS42_RESOURCE"/>
>value="PROPRIETARY_RESOURCE"/>
>
>
>value="VERSIONED_RAW"/>
>
>
>
>use="required"/>
>
>
> 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();
> parser->setFeature(XMLUni::fgSAX2CoreValidation, true);
> parser->setFeature(XMLUni::fgSAX2CoreNameSpaces, true);
> parser->setFeature(XMLUni::fgXercesSchema, true);
> parser->setFeature(XMLUni::fgXercesSchemaFullChecking, true);
> parser->setValidationConstraintFatal(true);
> string schemaLocation =
[jira] Commented: (XERCESC-1593) critical Warning on compiling XercesC 2.7.0
[ http://issues.apache.org/jira/browse/XERCESC-1593?page=comments#action_12379088 ] Jesse Pelton commented on XERCESC-1593: --- While I agree that ideal code compiles without warnings, there are many compilers in the world, each with its own criteria for generating warnings. Today's "clean" code may cause a future compiler to spew endless warnings. Furthermore, some compilers aren't especially smart about the warnings they generate. In the code I looked at, a more sophisticated compiler would have determined that the code was safe and skipped the warnings. I'm skeptical of the notion of altering code purely to silence a compiler that generates needless warnings. For instance, in the cases I looked at, it's not clear what appropriate initial values would be; choosing some arbitrary value could make the code harder to really understand, which is a step backward. Remember that I pointed out that the code I looked at is hard to understand. If it's restructured to make it easier for humans to understand, I think there's a good chance that compilers will be able to analyze it more successfully. Warnings should be viewed as a hint that you might want to rethink your code, not as a mandate to revise it. In any case, if you believe you have a solution, I imagine that a patch would be welcome. If you make a patch against the current code in SVN, it will be easier to review and apply. > critical Warning on compiling XercesC 2.7.0 > --- > > Key: XERCESC-1593 > URL: http://issues.apache.org/jira/browse/XERCESC-1593 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.7.0 > Environment: MSVC 2003 (7.1) > Set Warning Level to 4 > Reporter: Lukas Grützmacher > > I've compiled XercesC 2.7.0 from sources with MSVC2003. > I've changed the project settings to use always warning level 4. > Thereby I found a lot of warnings. IMHO some of them are critical: > xerces-c-src_2_7_0\src\xercesc\validators\schema\traverseschema.cpp(6490) : > warning C4701: local variable 'defAttType' may be used without having been > initialized > xerces-c-src_2_7_0\src\xercesc\util\regx\token.cpp(259) : warning C4701: > local variable 'ret2' may be used without having been initialized > xerces-c-src_2_7_0\src\xercesc\util\regx\RegularExpression.cpp(184) : warning > C4244: 'argument' : conversion from 'XMLInt32' to 'const XMLCh', possible > loss of data > xerces-c-src_2_7_0\src\xercesc\util\platforms\win32\win32platformutils.cpp(795) > : warning C4701: local variable 'retVal' may be used without having been > initialized > xerces-c-src_2_7_0\tests\xserializertest\xserializertest.cpp(537) : warning > C4701: local variable 'duration' may be used without having been initialized > Many others are not critical but sould be fixed, too. Here are some examples: > DFAContentModel.cpp > ..\..\..\..\..\src\xercesc\validators\common\CMNode.hpp(129) : warning C4245: > 'initializing' : conversion from 'int' to 'unsigned int', signed/unsigned > mismatch > xerces-c-src_2_7_0\src\xercesc\internal\XSAXMLScanner.cpp(310) : warning > C4245: 'argument' : conversion from '' to 'unsigned int', signed/unsigned > mismatch > xerces-c-src_2_7_0\src\xercesc\framework\psvi\XSValue.cpp(1721) : warning > C4189: 'strLen' : local variable is initialized but not referenced > xerces-c-src_2_7_0\src\xercesc\dom\deprecated\DOM_RangeException.cpp(36) : > warning C4244: 'argument' : conversion from > 'xercesc_2_7::DOM_RangeException::RangeExceptionCode' to 'short', possible > loss of data -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1593) critical Warning on compiling XercesC 2.7.0
[ http://issues.apache.org/jira/browse/XERCESC-1593?page=comments#action_12379077 ] Jesse Pelton commented on XERCESC-1593: --- These may or may not actually be problems. I took a look at the code that causes the first warning to be generated (in TraverseSchem.cpp) and concluded that it's safe. That said, I had to look at it pretty closely to reach this conclusion because the logic is a bit obscure. (It's clear that the offending statement can't be reached unless completeWildCard is set, but it's not obvious that if completeWildCard is set, defAttType will also be set.) Likewise for Token.cpp: it's safe, but a bit obscure. Bottom line: while these warnings correlate to code that is somewhat hard to read, careful analysis of each instance is required to determine whether there's actually anything wrong and whether there's an alternative that's easier for humans and compilers to analyze, correct, and efficient. A patch, anyone? > critical Warning on compiling XercesC 2.7.0 > --- > > Key: XERCESC-1593 > URL: http://issues.apache.org/jira/browse/XERCESC-1593 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.7.0 > Environment: MSVC 2003 (7.1) > Set Warning Level to 4 > Reporter: Lukas Grützmacher > > I've compiled XercesC 2.7.0 from sources with MSVC2003. > I've changed the project settings to use always warning level 4. > Thereby I found a lot of warnings. IMHO some of them are critical: > xerces-c-src_2_7_0\src\xercesc\validators\schema\traverseschema.cpp(6490) : > warning C4701: local variable 'defAttType' may be used without having been > initialized > xerces-c-src_2_7_0\src\xercesc\util\regx\token.cpp(259) : warning C4701: > local variable 'ret2' may be used without having been initialized > xerces-c-src_2_7_0\src\xercesc\util\regx\RegularExpression.cpp(184) : warning > C4244: 'argument' : conversion from 'XMLInt32' to 'const XMLCh', possible > loss of data > xerces-c-src_2_7_0\src\xercesc\util\platforms\win32\win32platformutils.cpp(795) > : warning C4701: local variable 'retVal' may be used without having been > initialized > xerces-c-src_2_7_0\tests\xserializertest\xserializertest.cpp(537) : warning > C4701: local variable 'duration' may be used without having been initialized > Many others are not critical but sould be fixed, too. Here are some examples: > DFAContentModel.cpp > ..\..\..\..\..\src\xercesc\validators\common\CMNode.hpp(129) : warning C4245: > 'initializing' : conversion from 'int' to 'unsigned int', signed/unsigned > mismatch > xerces-c-src_2_7_0\src\xercesc\internal\XSAXMLScanner.cpp(310) : warning > C4245: 'argument' : conversion from '' to 'unsigned int', signed/unsigned > mismatch > xerces-c-src_2_7_0\src\xercesc\framework\psvi\XSValue.cpp(1721) : warning > C4189: 'strLen' : local variable is initialized but not referenced > xerces-c-src_2_7_0\src\xercesc\dom\deprecated\DOM_RangeException.cpp(36) : > warning C4244: 'argument' : conversion from > 'xercesc_2_7::DOM_RangeException::RangeExceptionCode' to 'short', possible > loss of data -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1580) Backward compatibility
[ http://issues.apache.org/jira/browse/XERCESC-1580?page=all ] Jesse Pelton closed XERCESC-1580: - > Backward compatibility > -- > > Key: XERCESC-1580 > URL: http://issues.apache.org/jira/browse/XERCESC-1580 > Project: Xerces-C++ > Type: Task > Versions: 2.7.0 > Reporter: Ganesh Kumar > Priority: Trivial > > Can any one tell me if Xerces-c 2.7 is backward compatible with Xerces-2.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1580) Backward compatibility
[ http://issues.apache.org/jira/browse/XERCESC-1580?page=all ] Jesse Pelton resolved XERCESC-1580: --- Resolution: Invalid Please use the mailing list for questions. > Backward compatibility > -- > > Key: XERCESC-1580 > URL: http://issues.apache.org/jira/browse/XERCESC-1580 > Project: Xerces-C++ > Type: Task > Versions: 2.7.0 > Reporter: Ganesh Kumar > Priority: Trivial > > Can any one tell me if Xerces-c 2.7 is backward compatible with Xerces-2.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1511) SAX2 parse method starts parsing XML document and hangs
[
http://issues.apache.org/jira/browse/XERCESC-1511?page=comments#action_12331790
]
Jesse Pelton commented on XERCESC-1511:
---
If SAX2Print can process your document, the problem is probably not in Xerces.
Are you certain that the blocked mutex is not related?
If you parse the memory buffer directly rather than writing it to a file, does
the same problem occur?
In any case, it's probably time to break out the debugger. Set a breakpoint in
your startDocument() function, then step through the program from there. Your
trace indicates that you exit startDocument(), so presumably the problem is
elsewhere. With luck, you'll have an "Aha!" moment shortly.
> SAX2 parse method starts parsing XML document and hangs
> ---
>
> Key: XERCESC-1511
> URL: http://issues.apache.org/jira/browse/XERCESC-1511
> Project: Xerces-C++
> Type: Bug
> Components: SAX/SAX2
> Versions: 2.5.0
> Environment: Xerces-C++ version number :- xerces-c_2_5_0-hpux_11-acc_a03
> Platform :- HP-UX 11
> Operating system and version number :- HP-UX Unix Version 11.0
> Compiler and version number :- aCC compiler - HP aC++ Version A.03.37
> Reporter: Sunil Ramchandra
> Priority: Blocker
>
> Xerces-C++ version number xerces-c_2_5_0-hpux_11-acc_a03
> Platform HP-UX 11
> Operating system and version number HP-UX Unix Version 11.0
> Compiler and version number aCC compiler - HP aC++ Version A.03.37
> The schema document has no issues and the the XML string also has no issues,
> because both work well when i used ALTOVA tool for parsing.
> The XML document (or excerpt) that failed
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation="/opt/lnpsite/nimnm00/flat/schema/NMXMLInterface.xsd"> RequestHandle="1319"> STARTTN="1501502001" ENDTN="1501502001"> SVID="43774"> LRN="400400"> BlockHolderReturnFlag=""> SPID="SP00"> ClassGTA="1" ClassTT="111" CnamDPC="2" CnamSSN="222" CnamTT="111"
> CnamGTA="1" IsvmDPC="2" IsvmSSN="222" IsvmTT="111" IsvmGTA="1"
> LidbDPC="2" LidbSSN="222" LidbTT="111" LidbGTA="1" WsmscDPC=""
> WsmscSSN="" WsmscTT="" WsmscGTA=""> Location=""> LocationType=""> BillingId=""> ActivationDate="2005-10-05"> ActivationTime="15:43:46"> NPACRegionId="1"> LNPTypeIndicator="0"> UpdateIndicator="1"> CreateDeleteReason="0"> ContaminateStatus="0"> Indicator="0">
> The C++ application code that failed
> parser = (SAX2XMLReader*) XMLReaderFactory::createXMLReader();
> parser->setContentHandler(this);
> parser->setErrorHandler(this);
> parser->setFeature(XMLUni::fgXercesSchema, true);
>
> ofstream outfile;
> RWCString msgFileName;
> RWCString uniqName(tempnam("/tmp","XML_"));
> msgFileName.append(uniqName);
>
> msgFileName.append(LTime::now().asString("_%Y""%m""%d",RWZone::utc()));
> msgFileName.append(LTime::now().asString("%H""%M""%S",RWZone::utc()));
> msgFileName.append(".xml");
> outfile.open (msgFileName, ofstream::out); > I am creating a
> temporary xml file here
> outfile< This string buffer has the XML string
> mentioned above
> outfile.close();
> cout<<"I am here: abt to errorReset"< this->resetErrors();
> cout<<"I am here: abt to parse"< parser->parse(msgFileName); --> Sending the file to the parser
> (After this i am able to see the start document method call in my logs, but
> after that nothing)
> cout<<"I am here: Done with parse - going to remove
> file"< remove(msgFileName); --> i am removing the file
> Whether you built the Xerces-C++ library yourself or used the binary
> distribution - NO I sued the 2_5_7 libraries.
>
> What happened
> I am using the SAX2 parser to parse my XML files.
> I dont use any threads here, its a single flow of events from parser creation
> till the parsing of the xml file.
> I observe that in my logs, once the XML string is created and sent to the
> piece of code mentioned above. The parser hangs in the parse method.
> As per its behaviour, it is supposed to call the "start document" "statrt
> element" functions whihc are overloaded in my classes.
> The last log statement that i see is the " start document " after that i
> dont get anything. My application proceeds with other threads where i do
> socket operations totally un-related to the XML logic or piece of code.
> Here are the logs
> TRACELOG_MSG : 10/05/05 09:56:51.236 : - XML string is being validated:[ version="1.0" encoding="UTF-8"?>
> http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation="/opt/lnpsite/nimnm00/flat/schema/NMXMLInterface.xsd"> RequestHandle="1319"> ENDTN="1501502001"> LRN="400400"> BlockHolderReturnFlag=""> SPID="SP00"> ClassGTA="1" ClassTT="111" CnamDPC="2" CnamSSN="222" CnamTT="111"
> CnamGTA="
[jira] Commented: (XERCESC-1511) SAX2 parse method starts parsing XML document and hangs
[
http://issues.apache.org/jira/browse/XERCESC-1511?page=comments#action_12331491
]
Jesse Pelton commented on XERCESC-1511:
---
Can you reproduce this issue with the SAX2Print sample application?
> SAX2 parse method starts parsing XML document and hangs
> ---
>
> Key: XERCESC-1511
> URL: http://issues.apache.org/jira/browse/XERCESC-1511
> Project: Xerces-C++
> Type: Bug
> Components: SAX/SAX2
> Versions: 2.5.0
> Environment: Xerces-C++ version number :- xerces-c_2_5_0-hpux_11-acc_a03
> Platform :- HP-UX 11
> Operating system and version number :- HP-UX Unix Version 11.0
> Compiler and version number :- aCC compiler - HP aC++ Version A.03.37
> Reporter: Sunil Ramchandra
> Priority: Blocker
>
> Xerces-C++ version number xerces-c_2_5_0-hpux_11-acc_a03
> Platform HP-UX 11
> Operating system and version number HP-UX Unix Version 11.0
> Compiler and version number aCC compiler - HP aC++ Version A.03.37
> The schema document has no issues and the the XML string also has no issues,
> because both work well when i used ALTOVA tool for parsing.
> The XML document (or excerpt) that failed
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation="/opt/lnpsite/nimnm00/flat/schema/NMXMLInterface.xsd"> RequestHandle="1319"> STARTTN="1501502001" ENDTN="1501502001"> SVID="43774"> LRN="400400"> BlockHolderReturnFlag=""> SPID="SP00"> ClassGTA="1" ClassTT="111" CnamDPC="2" CnamSSN="222" CnamTT="111"
> CnamGTA="1" IsvmDPC="2" IsvmSSN="222" IsvmTT="111" IsvmGTA="1"
> LidbDPC="2" LidbSSN="222" LidbTT="111" LidbGTA="1" WsmscDPC=""
> WsmscSSN="" WsmscTT="" WsmscGTA=""> Location=""> LocationType=""> BillingId=""> ActivationDate="2005-10-05"> ActivationTime="15:43:46"> NPACRegionId="1"> LNPTypeIndicator="0"> UpdateIndicator="1"> CreateDeleteReason="0"> ContaminateStatus="0"> Indicator="0">
> The C++ application code that failed
> parser = (SAX2XMLReader*) XMLReaderFactory::createXMLReader();
> parser->setContentHandler(this);
> parser->setErrorHandler(this);
> parser->setFeature(XMLUni::fgXercesSchema, true);
>
> ofstream outfile;
> RWCString msgFileName;
> RWCString uniqName(tempnam("/tmp","XML_"));
> msgFileName.append(uniqName);
>
> msgFileName.append(LTime::now().asString("_%Y""%m""%d",RWZone::utc()));
> msgFileName.append(LTime::now().asString("%H""%M""%S",RWZone::utc()));
> msgFileName.append(".xml");
> outfile.open (msgFileName, ofstream::out); > I am creating a
> temporary xml file here
> outfile< This string buffer has the XML string
> mentioned above
> outfile.close();
> cout<<"I am here: abt to errorReset"< this->resetErrors();
> cout<<"I am here: abt to parse"< parser->parse(msgFileName); --> Sending the file to the parser
> (After this i am able to see the start document method call in my logs, but
> after that nothing)
> cout<<"I am here: Done with parse - going to remove
> file"< remove(msgFileName); --> i am removing the file
> Whether you built the Xerces-C++ library yourself or used the binary
> distribution - NO I sued the 2_5_7 libraries.
>
> What happened
> I am using the SAX2 parser to parse my XML files.
> I dont use any threads here, its a single flow of events from parser creation
> till the parsing of the xml file.
> I observe that in my logs, once the XML string is created and sent to the
> piece of code mentioned above. The parser hangs in the parse method.
> As per its behaviour, it is supposed to call the "start document" "statrt
> element" functions whihc are overloaded in my classes.
> The last log statement that i see is the " start document " after that i
> dont get anything. My application proceeds with other threads where i do
> socket operations totally un-related to the XML logic or piece of code.
> Here are the logs
> TRACELOG_MSG : 10/05/05 09:56:51.236 : - XML string is being validated:[ version="1.0" encoding="UTF-8"?>
> http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation="/opt/lnpsite/nimnm00/flat/schema/NMXMLInterface.xsd"> RequestHandle="1319"> ENDTN="1501502001"> LRN="400400"> BlockHolderReturnFlag=""> SPID="SP00"> ClassGTA="1" ClassTT="111" CnamDPC="2" CnamSSN="222" CnamTT="111"
> CnamGTA="1" IsvmDPC="2" IsvmSSN="222" IsvmTT="111" IsvmGTA="1"
> LidbDPC="2" LidbSSN="222" LidbTT="111" LidbGTA="1" WsmscDPC=""
> WsmscSSN="" WsmscTT="" WsmscGTA=""> Location=""> BillingId=""> ActivationDate="2005-10-05"> ActivationTime="15:43:46"> NPACRegionId="1"> LNPTypeIndicator="0"> UpdateIndicator="1"> CreateDeleteReason="0"> ContaminateStatus="0"> Indicator="0">]
> (XMLConverter.C, 131)
> TRACELOG_MSG : 10/05/05 09:56:51.237 : - Xml schema file
[jira] Commented: (XERCESC-1501) Build failure on Cygwin
[ http://issues.apache.org/jira/browse/XERCESC-1501?page=comments#action_12329427 ] Jesse Pelton commented on XERCESC-1501: --- It looks like the build is broken for large parts of the deprecated DOM. Do you need that? If not, try building without it. I don't use Cygwin and I'm not particularly familiar with current *nix build tools, but it looks to me like removing "deprecated" from the list of dependents for the "all" target in the DOM makefile should do the trick (or at least set you on your way). If you can build without the deprecated DOM, it's probably a sign of neglect of that code. It gets little if any attention precisely because it's deprecated, and it will not be included in the next version of Xerces (3.0). Nonetheless, if there is a problem with the code, it may be worth chasing it down and offering a patch. It might find its way into a 2.7 maintenance release, and even if it doesn't, working code would be available in SVN for others in your situation. > Build failure on Cygwin > --- > > Key: XERCESC-1501 > URL: http://issues.apache.org/jira/browse/XERCESC-1501 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.7.0 > Environment: (1) CYGWIN_NT-5.0 pc-03420 1.5.12(0.116/4/2) 2004-11-10 08:34 > i686 unknown unknown Cygwin > Win2000, gcc version 3.3.3 (cygwin special) > (2) CYGWIN_NT-5.1 lp-06351 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown > unknown Cygwin > Win XP Pro SP1, gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd > 0.125) > Reporter: Oliver Gehrke > > I've been trying to build 2.7.0 on two Cygwin machines, but keep getting tons > of linkage errors. Builds on Linux and Solaris > work fine, and I can successfully build <=2.6.0 on the two Cygwin boxes, so I > doubt there's too much wrong with the environment. > Here's an excerpt of what it throws at me: > -- > [...] > Building /cygdrive/d/tmp/xerces-c-src_2_7_0/lib/cygxerces-c27.dll > make -s -C /cygdrive/d/tmp/xerces-c-src_2_7_0/obj -k > Building /cygdrive/d/tmp/xerces-c-src_2_7_0/lib/cygxerces-c27.dll > Creating library file: > /cygdrive/d/tmp/xerces-c-src_2_7_0/lib/libxerces-c27.dll.a > symlink /cygdrive/d/tmp/xerces-c-src_2_7_0/lib/libxerces-c2_7_0.dll.a > symlink /cygdrive/d/tmp/xerces-c-src_2_7_0/lib/libxerces-c.dll.a > Building /cygdrive/d/tmp/xerces-c-src_2_7_0/lib/cygxerces-depdom27.dll > Creating library file: > /cygdrive/d/tmp/xerces-c-src_2_7_0/lib/libxerces-depdom27.dll.a > CYGWIN/depdom/AttrImpl.o(.text+0x4bb):AttrImpl.cpp: undefined reference to > `xercesc_2_7::XMemory::operator delete(void*)' > CYGWIN/depdom/AttrImpl.o(.text+0x50d):AttrImpl.cpp: undefined reference to > `xercesc_2_7::XMemory::operator new(unsigned, xercesc_2_7::MemoryManager*)' > CYGWIN/depdom/AttrImpl.o(.text+0x563):AttrImpl.cpp: undefined reference to > `xercesc_2_7::XMemory::operator delete(void*, xercesc_2_7::MemoryManager*)' > CYGWIN/depdom/AttrImpl.o(.text$_ZN11xercesc_2_715BaseRefVectorOfINS_9RangeImplEE9elementAtEj[xercesc_2_7::BaseRefVectorOf::elementAt(unsigned)]+0x87):AttrImpl.cpp: > undefined reference to > `xercesc_2_7::XMLException::XMLException[not-in-charge](char const*, > unsigned, xercesc_2_7::MemoryManager*)' > CYGWIN/depdom/AttrImpl.o(.text$_ZN11xercesc_2_715BaseRefVectorOfINS_9RangeImplEE9elementAtEj[xercesc_2_7::BaseRefVectorOf::elementAt(unsigned)]+0xa7):AttrImpl.cpp: > undefined reference to > `xercesc_2_7::XMLException::loadExceptText(xercesc_2_7::XMLExcepts::Codes)' > CYGWIN/depdom/AttrImpl.o(.text$_ZN11xercesc_2_715BaseRefVectorOfINS_9RangeImplEE9elementAtEj[xercesc_2_7::BaseRefVectorOf::elementAt(unsigned)]+0xca):AttrImpl.cpp: > undefined reference to `xercesc_2_7::XMLException::~XMLException > [not-in-charge]()' > CYGWIN/depdom/AttrImpl.o(.text$_ZNK11xercesc_2_730ArrayIndexOutOfBoundsException9duplicateEv[xercesc_2_7::ArrayIndexOutOfBoundsException::duplicate() > const]+0x70):AttrImpl.cpp: undefined reference to > `xercesc_2_7::XMLException::XMLException[not-in-charge](xercesc_2_7::XMLException > const&)' > CYGWIN/depdom/AttrImpl.o(.text$_ZNK11xercesc_2_730ArrayIndexOutOfBoundsException7getTypeEv[xercesc_2_7::ArrayIndexOutOfBoundsException::getType() > const]+0x4):AttrImpl.cpp: undefined reference to > `xercesc_2_7::XMLUni::fgArrayIndexOutOfBoundsException_Name' > CYGWIN/depdom/CDATASectionImpl.o(.text+0x2b7):CDATASectionImpl.cpp: undefined > reference to > `xercesc_2_7::XMLRegisterCleanup::XMLRegisterCleanup[in-charge]()' > CYGWIN/depdom/DOMParser.o(.text+0x8e3):DOMParser.cpp: undefined reference to > `xercesc_2_7::GrammarResolver::GrammarResolver[in-charge](xercesc_2_7::XMLGrammarPool*, > xercesc_2_7::MemoryManager*)' > CYGWIN/depdom/DOMParser.o(.text+0x948):DOMParser.cpp: undefined reference to
[jira] Commented: (XERCESC-1499) Unable to execute problem compiled with 32 bit Xerces-C 2.7.0 library on HP 11.i(64 bit os)
[ http://issues.apache.org/jira/browse/XERCESC-1499?page=comments#action_12329424 ] Jesse Pelton commented on XERCESC-1499: --- I should also point out that a better place to raise issues like this is the Xerces-C mailing list. Please subscribe to [EMAIL PROTECTED] If people on the list agree that there is a bug, that is the time to file a bug report. (If you can point to a particular piece of code, explain why it is in error (with reference to any relevant standards), and ideally provide a patch, it's certainly appropriate to file a bug report without consulting the list.) In no case is it helpful to yourself or anyone else to file multiple bug reports on the same issue. This just generates bugspam, which as you might gather from the name, is not a form of communication that people look forward to. > Unable to execute problem compiled with 32 bit Xerces-C 2.7.0 library on HP > 11.i(64 bit os) > --- > > Key: XERCESC-1499 > URL: http://issues.apache.org/jira/browse/XERCESC-1499 > Project: Xerces-C++ > Type: Bug > Versions: 2.7.0 > Environment: HP 11.i 64 bit OS, aCC > Reporter: Venkatesh > Priority: Blocker > > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. > I'm getting the following error while executing the probram compiled with > Xerces 2.7.0 32 bit libary for HP 11.i. > > /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data) from > /appl/load/dsnp/dev/tuxadm/xerces/xerces-c-hpux_1 > 1i-acc_a03/lib/libxerces-c.sl.27 > Abort(coredump) > > I'd like to add that the 64 bit Xerces C library (2.6.0) is not giving any > issues when used with the same program. But out applications are 32 bit only. > To have a work around, we tried to download the 32 bit library belonging to > older xerces versions (2.6.0, 2.5.0). Unfortunately all these downloads are > corrupted. > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1493) Unable to download the xerces-c_2_6_0-hpux_11i-acc_a03.tar.gz file for relaease 2.6.0 (32 bit)
[ http://issues.apache.org/jira/browse/XERCESC-1493?page=all ] Jesse Pelton closed XERCESC-1493: - > Unable to download the xerces-c_2_6_0-hpux_11i-acc_a03.tar.gz file for > relaease 2.6.0 (32 bit) > -- > > Key: XERCESC-1493 > URL: http://issues.apache.org/jira/browse/XERCESC-1493 > Project: Xerces-C++ > Type: Bug > Versions: 2.6.0 > Environment: HP 11.i 64 bit OS > aCC compiler > Reporter: Venkatesh > Priority: Blocker > > Hi, > Any download, starting in the decending order from 2.6.0 release,(2.5.0, > 2.4.0) from the archive download site > (http://archive.apache.org/dist/xml/xerces-c/) seems to be corrupt. > I'm very interested in trying out the 2.6.0 version of the Xerces-C parser. > The 2.7.0 is not suitable as it is giving a run time error: > > /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data) from > /appl/load/dsnp/dev/tuxadm/xerces/xerces-c-hpux_1 > 1i-acc_a03/lib/libxerces-c.sl.27 > Abort(coredump) > > Please help! > Regards, > Venkatesh -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1493) Unable to download the xerces-c_2_6_0-hpux_11i-acc_a03.tar.gz file for relaease 2.6.0 (32 bit)
[ http://issues.apache.org/jira/browse/XERCESC-1493?page=all ] Jesse Pelton resolved XERCESC-1493: --- Resolution: Duplicate Duplicate of XERCESC-1499. > Unable to download the xerces-c_2_6_0-hpux_11i-acc_a03.tar.gz file for > relaease 2.6.0 (32 bit) > -- > > Key: XERCESC-1493 > URL: http://issues.apache.org/jira/browse/XERCESC-1493 > Project: Xerces-C++ > Type: Bug > Versions: 2.6.0 > Environment: HP 11.i 64 bit OS > aCC compiler > Reporter: Venkatesh > Priority: Blocker > > Hi, > Any download, starting in the decending order from 2.6.0 release,(2.5.0, > 2.4.0) from the archive download site > (http://archive.apache.org/dist/xml/xerces-c/) seems to be corrupt. > I'm very interested in trying out the 2.6.0 version of the Xerces-C parser. > The 2.7.0 is not suitable as it is giving a run time error: > > /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data) from > /appl/load/dsnp/dev/tuxadm/xerces/xerces-c-hpux_1 > 1i-acc_a03/lib/libxerces-c.sl.27 > Abort(coredump) > > Please help! > Regards, > Venkatesh -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1499) Unable to execute problem compiled with 32 bit Xerces-C 2.7.0 library on HP 11.i(64 bit os)
[ http://issues.apache.org/jira/browse/XERCESC-1499?page=comments#action_12329421 ] Jesse Pelton commented on XERCESC-1499: --- Why do you believe the archive has errors? I was able to download and open it with WinZip on Windows XP and on Linux using KDE's Ark archiver. Did you compare the MD5 checksum of the archive after you downloaded it to the value on the download site? Have you tried downloading from a different mirror? > Unable to execute problem compiled with 32 bit Xerces-C 2.7.0 library on HP > 11.i(64 bit os) > --- > > Key: XERCESC-1499 > URL: http://issues.apache.org/jira/browse/XERCESC-1499 > Project: Xerces-C++ > Type: Bug > Versions: 2.7.0 > Environment: HP 11.i 64 bit OS, aCC > Reporter: Venkatesh > Priority: Blocker > > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. > I'm getting the following error while executing the probram compiled with > Xerces 2.7.0 32 bit libary for HP 11.i. > > /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data) from > /appl/load/dsnp/dev/tuxadm/xerces/xerces-c-hpux_1 > 1i-acc_a03/lib/libxerces-c.sl.27 > Abort(coredump) > > I'd like to add that the 64 bit Xerces C library (2.6.0) is not giving any > issues when used with the same program. But out applications are 32 bit only. > To have a work around, we tried to download the 32 bit library belonging to > older xerces versions (2.6.0, 2.5.0). Unfortunately all these downloads are > corrupted. > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1498) Unable to execute problem compiled with 32 bit Xerces-C 2.7.0 library on HP 11.i(64 bit os)
[ http://issues.apache.org/jira/browse/XERCESC-1498?page=all ] Jesse Pelton resolved XERCESC-1498: --- Resolution: Duplicate Duplicate of XERCESC-1499. > Unable to execute problem compiled with 32 bit Xerces-C 2.7.0 library on HP > 11.i(64 bit os) > --- > > Key: XERCESC-1498 > URL: http://issues.apache.org/jira/browse/XERCESC-1498 > Project: Xerces-C++ > Type: Bug > Versions: 2.7.0 > Reporter: Venkatesh > Priority: Blocker > > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. > I'm getting the following error while executing the probram compiled with > Xerces 2.7.0 32 bit libary for HP 11.i. > > /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data) from > /appl/load/dsnp/dev/tuxadm/xerces/xerces-c-hpux_1 > 1i-acc_a03/lib/libxerces-c.sl.27 > Abort(coredump) > > I'd like to add that the 64 bit Xerces C library (2.6.0) is not giving any > issues when used with the same program. But out applications are 32 bit only. > To have a work around, we tried to download the 32 bit library belonging to > older xerces versions (2.6.0, 2.5.0). Unfortunately all these downloads are > corrupted. > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1498) Unable to execute problem compiled with 32 bit Xerces-C 2.7.0 library on HP 11.i(64 bit os)
[ http://issues.apache.org/jira/browse/XERCESC-1498?page=all ] Jesse Pelton closed XERCESC-1498: - > Unable to execute problem compiled with 32 bit Xerces-C 2.7.0 library on HP > 11.i(64 bit os) > --- > > Key: XERCESC-1498 > URL: http://issues.apache.org/jira/browse/XERCESC-1498 > Project: Xerces-C++ > Type: Bug > Versions: 2.7.0 > Reporter: Venkatesh > Priority: Blocker > > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. > I'm getting the following error while executing the probram compiled with > Xerces 2.7.0 32 bit libary for HP 11.i. > > /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data) from > /appl/load/dsnp/dev/tuxadm/xerces/xerces-c-hpux_1 > 1i-acc_a03/lib/libxerces-c.sl.27 > Abort(coredump) > > I'd like to add that the 64 bit Xerces C library (2.6.0) is not giving any > issues when used with the same program. But out applications are 32 bit only. > To have a work around, we tried to download the 32 bit library belonging to > older xerces versions (2.6.0, 2.5.0). Unfortunately all these downloads are > corrupted. > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1500) Unable to download the xerces-c_2_6_0-hpux_11i-acc_a03.tar.gz file for relaease 2.6.0 (32 bit)
[ http://issues.apache.org/jira/browse/XERCESC-1500?page=all ] Jesse Pelton closed XERCESC-1500: - > Unable to download the xerces-c_2_6_0-hpux_11i-acc_a03.tar.gz file for > relaease 2.6.0 (32 bit) > -- > > Key: XERCESC-1500 > URL: http://issues.apache.org/jira/browse/XERCESC-1500 > Project: Xerces-C++ > Type: Bug > Components: Validating Parser (Schema) (Xerces 1.5 or up only) > Versions: 2.6.0 > Environment: HP 11.i 64 bit OS > Reporter: Venkatesh > Priority: Blocker > > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. > I'm getting the following error while executing the probram compiled with > Xerces 2.7.0 32 bit libary for HP 11.i. > > /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data) from > /appl/load/dsnp/dev/tuxadm/xerces/xerces-c-hpux_1 > 1i-acc_a03/lib/libxerces-c.sl.27 > Abort(coredump) > > I'd like to add that the 64 bit Xerces C library (2.6.0) is not giving any > issues when used with the same program. But out applications are 32 bit only. > To have a work around, we tried to download the 32 bit library belonging to > older xerces versions (2.6.0, 2.5.0). Unfortunately all these downloads are > corrupted. > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1500) Unable to download the xerces-c_2_6_0-hpux_11i-acc_a03.tar.gz file for relaease 2.6.0 (32 bit)
[ http://issues.apache.org/jira/browse/XERCESC-1500?page=all ] Jesse Pelton resolved XERCESC-1500: --- Resolution: Duplicate Duplicate of XERCESC-1499. > Unable to download the xerces-c_2_6_0-hpux_11i-acc_a03.tar.gz file for > relaease 2.6.0 (32 bit) > -- > > Key: XERCESC-1500 > URL: http://issues.apache.org/jira/browse/XERCESC-1500 > Project: Xerces-C++ > Type: Bug > Components: Validating Parser (Schema) (Xerces 1.5 or up only) > Versions: 2.6.0 > Environment: HP 11.i 64 bit OS > Reporter: Venkatesh > Priority: Blocker > > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. > I'm getting the following error while executing the probram compiled with > Xerces 2.7.0 32 bit libary for HP 11.i. > > /usr/lib/dld.sl: Unresolved symbol: typeid__XT9exception_ (data) from > /appl/load/dsnp/dev/tuxadm/xerces/xerces-c-hpux_1 > 1i-acc_a03/lib/libxerces-c.sl.27 > Abort(coredump) > > I'd like to add that the 64 bit Xerces C library (2.6.0) is not giving any > issues when used with the same program. But out applications are 32 bit only. > To have a work around, we tried to download the 32 bit library belonging to > older xerces versions (2.6.0, 2.5.0). Unfortunately all these downloads are > corrupted. > Please upload proper CRC error free Xerces 2.6.0 downloads on your website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XERCESC-1453) Fix for build problem on Mac OS X Tiger, MacOSUnicodeConverter.cpp:78: error
[ http://issues.apache.org/jira/browse/XERCESC-1453?page=all ] Jesse Pelton closed XERCESC-1453: - > Fix for build problem on Mac OS X Tiger, MacOSUnicodeConverter.cpp:78: error > > > Key: XERCESC-1453 > URL: http://issues.apache.org/jira/browse/XERCESC-1453 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: MAC OSX 10.4 Tiger, build from command shell, bash > Reporter: Johannes Gutleber > Attachments: MacOSUnicodeConverter.cpp.diff > > The released 2.6.0 of Xerces for C++ fails to build on MAC OS X 10.4 Tiger > with the error: > % ./runConfigure -p macosx -n native > % make > MacOSUnicodeConverter.cpp:78: error: 'static' may not be used when defining > (as opposed to declaring) a static data member > MacOSUnicodeConverter.cpp:84: error: 'static' may not be used when defining > (as opposed to declaring) a static data member > make[2]: *** [MacOSUnicodeConverter.o] Error 1 > The problem is due to the keyword "static" that shall not be repeated in the > implementation file. Removing the two "static" keywords from the two lines > solves the problem and the software builds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (XERCESC-1453) Fix for build problem on Mac OS X Tiger, MacOSUnicodeConverter.cpp:78: error
[ http://issues.apache.org/jira/browse/XERCESC-1453?page=all ] Jesse Pelton resolved XERCESC-1453: --- Resolution: Fixed A fix for this was checked in in December. Please confirm. > Fix for build problem on Mac OS X Tiger, MacOSUnicodeConverter.cpp:78: error > > > Key: XERCESC-1453 > URL: http://issues.apache.org/jira/browse/XERCESC-1453 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: MAC OSX 10.4 Tiger, build from command shell, bash > Reporter: Johannes Gutleber > Attachments: MacOSUnicodeConverter.cpp.diff > > The released 2.6.0 of Xerces for C++ fails to build on MAC OS X 10.4 Tiger > with the error: > % ./runConfigure -p macosx -n native > % make > MacOSUnicodeConverter.cpp:78: error: 'static' may not be used when defining > (as opposed to declaring) a static data member > MacOSUnicodeConverter.cpp:84: error: 'static' may not be used when defining > (as opposed to declaring) a static data member > make[2]: *** [MacOSUnicodeConverter.o] Error 1 > The problem is due to the keyword "static" that shall not be repeated in the > implementation file. Removing the two "static" keywords from the two lines > solves the problem and the software builds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1446) namespaces not handled correctly
[ http://issues.apache.org/jira/browse/XERCESC-1446?page=comments#action_12314049 ] Jesse Pelton commented on XERCESC-1446: --- Note also that the xmlns attributes are removed from the element in the output. > namespaces not handled correctly > > > Key: XERCESC-1446 > URL: http://issues.apache.org/jira/browse/XERCESC-1446 > Project: Xerces-C++ > Type: Bug > Components: SAX/SAX2 > Versions: 2.6.0 > Environment: WinXP - MSVC 6.0 > Linux RedHat 8.0 - GCC 3.2 > Reporter: Fabio Angelini > > If I run SAX2Print sample with the following XML: > > href="/SysConfig/Rules/Eidos/SoleOnLine3/articolo-lead.css"?> > http://www.w3.org"; > xmlns:html="http://www.w3.org/Profiles/XHTML-transitional";> > > > >width="768" height="83"/> > > > > > The output is: > > href="/SysConfig/Rules/Eidos/SoleOnLine3/artico > lo-lead.css"?> > > > > width= > "768" height="83"> > > > > > is closed as > is closed as > Version 2.5.0 doens't aver this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1442) XSD validaton error from SCMPrint sample
[ http://issues.apache.org/jira/browse/XERCESC-1442?page=comments#action_12313607 ] Jesse Pelton commented on XERCESC-1442: --- Xerces is doing the right thing. According to the schema spec, the value of a source attribute must be a URI. (See http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-documentation.) This is clearly not the case (or even the intent) in the affected schema. This bug is invalid. > XSD validaton error from SCMPrint sample > > > Key: XERCESC-1442 > URL: http://issues.apache.org/jira/browse/XERCESC-1442 > Project: Xerces-C++ > Type: Bug > Components: Samples/Tests, Validating Parser (Schema) (Xerces 1.5 or up > only) > Versions: 2.6.0 > Environment: OS: Windows XP; SP : MSVC++ 6.0 > Reporter: Anu Joseph > > When I tried to validate the XSD available at > http://eudravigilance.emea.eu.int/schema/XEVMPD.xsd using Xerces2.60 SCMPrint > Sample I'm getting paring errors like > Error at file C:\XEVMPD.xsd, line 409, char 91 > Message: Value 'The type of the operation for this entity.' is NOT a valid > URI > Error at file C:\XEVMPD.xsd, line 410, char 83 > Message: Value ' 1 = Insert 2 = Update 4 = Nullify' is NOT a valid URI > Error at file C:\XEVMPD.xsd, line 450, char 91 > Message: Value 'The type of the operation for this entity.' is NOT a valid > URI > .. > But the same file is validating finely in XML Spy. I'm not getting any clue > why this parser is happening from the specifed XSD. All error reported is in > 'xs:documentation source'; Seems to be a limitation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1435) like XML Tags
[ http://issues.apache.org/jira/browse/XERCESC-1435?page=comments#action_12313481 ] Jesse Pelton commented on XERCESC-1435: --- Please use the mailing list for questions. If it turns out that a feature you want is not supported by Xerces, then it would be appropriate to file an enhancement request. In this case, you can verify that Xerces supports short-form tags by running the DOMPrint sample program. It parses short-form tags (as a spec-conformant browser must) and serializes them as well. > like XML Tags > > > Key: XERCESC-1435 > URL: http://issues.apache.org/jira/browse/XERCESC-1435 > Project: Xerces-C++ > Type: Wish > Components: DOM > Versions: 2.6.0 > Environment: HP-UX 11i > Reporter: Biju George > > Does the xerces parser allows like tags instead of ( The > data is empty). ? > I am new to the area and hence just finding out whether I can support this in > my application through xerces 2.6.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1429) Error building Xerces with VC 7.1
[ http://issues.apache.org/jira/browse/XERCESC-1429?page=comments#action_12313181 ] Jesse Pelton commented on XERCESC-1429: --- I don't think there is a Win32\VC7.1 directory in the 2.6 source distribution. At least, I've never seen one, and I just checked to be sure. > Error building Xerces with VC 7.1 > - > > Key: XERCESC-1429 > URL: http://issues.apache.org/jira/browse/XERCESC-1429 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: Windows XP, Visual Studio C++ .NET (VC 7.1.3088) > Reporter: Daniel Gröndal > > First when opening the project I had to convert the project. When trying to > build XercesLib there were several compile errors related to .hpp-files > (object file asumed). This was resolved by changing the properties of the > project (using /TP). I also had to modify the project so that XercesDefs.hpp > is included. After these modifications the project compiles (with a few > warnings). > The problem is that I encouter several linkproblems: > \temp\xerces-c-current\xerces-c-src_2_6_0\Build\Win32\VC7\Release\obj\DOMImplementationimpl.obj > : warning LNK4042: object specified more than once; extras ignored > \temp\xerces-c-current\xerces-c-src_2_6_0\Build\Win32\VC7\Release\obj\DOMImplementationimpl.obj > : warning LNK4042: object specified more than once; extras ignored >Creating library ..\..\..\..\..\Build\Win32\VC7\Release/xerces-c_2.lib and > object ..\..\..\..\..\Build\Win32\VC7\Release/xerces-c_2.exp > TraverseSchema.obj : error LNK2001: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,unsigned short const * const,class > xercesc_2_6::MemoryManager * const)" ([EMAIL PROTECTED]@@[EMAIL > PROTECTED]@1@@Z) > DGXMLScanner.obj : error LNK2019: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,unsigned short const * const,class > xercesc_2_6::MemoryManager * const)" ([EMAIL PROTECTED]@@[EMAIL > PROTECTED]@1@@Z) referenced in function "private: virtual class > xercesc_2_6::InputSource * __thiscall > xercesc_2_6::DGXMLScanner::resolveSystemId(unsigned short const * const)" > ([EMAIL PROTECTED]@xercesc_2_6@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) > IGXMLScanner2.obj : error LNK2001: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,unsigned short const * const,class > xercesc_2_6::MemoryManager * const)" ([EMAIL PROTECTED]@@[EMAIL > PROTECTED]@1@@Z) > ReaderMgr.obj : error LNK2001: unresolved external symbol "public: __thiscall > xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned short const > * const,unsigned short const * const,class xercesc_2_6::MemoryManager * > const)" ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@1@@Z) > SGXMLScanner.obj : error LNK2001: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,unsigned short const * const,class > xercesc_2_6::MemoryManager * const)" ([EMAIL PROTECTED]@@[EMAIL > PROTECTED]@1@@Z) > XMLScanner.obj : error LNK2019: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,class xercesc_2_6::MemoryManager * const)" ([EMAIL > PROTECTED]@@[EMAIL PROTECTED]@1@@Z) referenced in function "public: void > __thiscall xercesc_2_6::XMLScanner::scanDocument(unsigned short const * > const)" ([EMAIL PROTECTED]@xercesc_2_6@@[EMAIL PROTECTED]) > AbstractDOMParser.obj : error LNK2019: unresolved external symbol "public: > static class xercesc_2_6::DOMImplementation * __cdecl > xercesc_2_6::DOMImplementationRegistry::getDOMImplementation(unsigned short > const *)" ([EMAIL PROTECTED]@xercesc_2_6@@[EMAIL PROTECTED]@[EMAIL > PROTECTED]) referenced in function "public: virtual void __thiscall > xercesc_2_6::AbstractDOMParser::startDocument(void)" ([EMAIL > PROTECTED]@xercesc_2_6@@UAEXXZ) > DOMDocumentTypeImpl.obj : error LNK2001: unresolved external symbol "public: > static class xercesc_2_6::DOMImplementation * __cdecl > xercesc_2_6::DOMImplementationRegistry::getDOMImplementation(unsigned short > const *)" ([EMAIL PROTECTED]@xercesc_2_6@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) > ..\..\..\..\..\Build\Win32\VC7\Release\xerces-c_2_6.dll : fatal error > LNK1120: 3 unresolved externals -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED]
[jira] Created: (XERCESC-1434) Web site needs to be updated to point to SVN instead of CVS
Web site needs to be updated to point to SVN instead of CVS
---
Key: XERCESC-1434
URL: http://issues.apache.org/jira/browse/XERCESC-1434
Project: Xerces-C++
Type: Task
Components: Documentation
Reporter: Jesse Pelton
Priority: Minor
The sidebar on http://xml.apache.org/xerces-c/ pages includes a "CVS
Repository" item. This needs to be updated to reflect the move from CVS to SVN.
I think three changes are needed:
- The image should be updated to read "SVN Repository" or perhaps something
more generic ("Project Repository"?).
- The alt text on the img element should be updated to match.
- The enclosing anchor's href should be changed from
"http://xml.apache.org/websrc/cvsweb.cgi/xml-xerces/c/"; to
"http://svn.apache.org/viewcvs.cgi/xerces/c/";.
The affected image is named "side-ext-100" in the HTML as of today.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1433) Memory leak with WriteToString
[
http://issues.apache.org/jira/browse/XERCESC-1433?page=comments#action_12312869
]
Jesse Pelton commented on XERCESC-1433:
---
DOMWriter::writeToString() allocates the string that it returns to the caller.
If there's a bug here, it's in the documentation, which does not mention that
it's the caller's responsibility to release the string, or how to do so, unlike
the documentation for (e.g.) some versions of XMLString::replicate(). (There's
some variation in the documentation for the different versions of this method,
which should perhaps be another bug.)
As for the problem at hand, calling XMLString::release(&xXml) should do the
trick. Is that what "did not work out?" If so, what happened?
Please continue this discussion on the mailing list, which is the appropriate
place for it. It's not clear yet that there's a bug in the library.
> Memory leak with WriteToString
> --
>
> Key: XERCESC-1433
> URL: http://issues.apache.org/jira/browse/XERCESC-1433
> Project: Xerces-C++
> Type: Bug
> Components: DOM
> Versions: 2.6.0
> Environment: HP-UX 11i and compiler HP ANSI C++ B3910B A.03.52
> Reporter: Biju George
>
> Using a simple serializeDOM function and in long run shows memory leak
> XERCES_CPP_NAMESPACE_USE
> int serializeDOM(DOMImplementation *impl, DOMNode* node, char * strError,
> char * outString) {
> DOMWriter* theSerializer =
> ((DOMImplementationLS*)impl)->createDOMWriter();
> try
> {
> XMLCh *xXml = theSerializer->writeToString(*node);
> char *pChar = XMLString::transcode(xXml);
> strcpy(outString,pChar);
> }
> catch (const XMLException& toCatch) {
> char* message = XMLString::transcode(toCatch.getMessage());
> strError = message;
> XMLString::release(&message);
> return FAILURE;
> }
> catch (const DOMException& toCatch) {
> char* message = XMLString::transcode(toCatch.msg);
> strError = message;
> XMLString::release(&message);
> return FAILURE;
> }
> catch (...) {
> strcpy(strError, "Unexpected Exception\n");
> return FAILURE;
> }
> theSerializer->release();
> return 0;
> }
> Commenting out the line XMLCh *xXml =
> theSerializer->writeToString(*node); will show that there is no memory leak.
> So I think the writeString method has the leak. Let me know whether I am
> doing something wrong or a fix for the same is available. I am using
> XERCESC++ version 2.6.0. Deleting xXml also did not work out for me.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1430) Broken projects in archive download site?
[ http://issues.apache.org/jira/browse/XERCESC-1430?page=comments#action_12312766 ] Jesse Pelton commented on XERCESC-1430: --- While I couldn't build 2.3.0 with Visual Studio .NET 2003, I didn't have any problem with 2.5.0. But that doesn't really matter. I believe this bug is invalid, because Xerces-C project policy is to maintain only the current version. This means that bugs in old versions are fixed only if the also occur in the current version. Neither of the listed problems occurs in the most recent release (2.6.0). > Broken projects in archive download site? > - > > Key: XERCESC-1430 > URL: http://issues.apache.org/jira/browse/XERCESC-1430 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.3.0, 2.5.0 > Environment: Windows XP, Visual Studio C++ .NET > Reporter: Daniel Gröndal > > Downloaded Xerces 2.3.0 and 2.5.0 from the archive download > site(http://archive.apache.org/dist/xml/xerces-c/) and tried to build these > using VC 7.1. > Compilation (of the VC7 project) was unsuccessful for both versions of Xerces > because of: > 1. Missing headerfile: > xerces-c-src_2_3_0\xerces-c-src_2_3_0\src\xercesc\dom\deprecated\NameNodeFilter.hpp(75) > : fatal error C1083: Cannot open include file: 'NodeFilterImpl.hpp': No such > file or directory > I have searched the source, but could not find this file. > 2. Difference in classname and name of the constructor (classname is > DomMemDebug and constructor is named DOMMemDebug): > xerces-c-src_2_3_0\xerces-c-src_2_3_0\src\xercesc\dom\deprecated\MemDebug.hpp(82) > : warning C4183: 'DOMMemDebug': missing return type; assumed to be a member > function returning 'int' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1366) Send CVS Migration request email to infrastructure@apache
[ http://issues.apache.org/jira/browse/XERCESC-1366?page=comments#action_12312771 ] Jesse Pelton commented on XERCESC-1366: --- Can this be closed? > Send CVS Migration request email to [EMAIL PROTECTED] > - > > Key: XERCESC-1366 > URL: http://issues.apache.org/jira/browse/XERCESC-1366 > Project: Xerces-C++ > Type: Task > Reporter: Jason E. Stewart > Priority: Blocker > > The apache infrastructure team is responsible for doing all the migration > work, they will not start until we send them a formal request. > The current proposal needs to be voted on, and then sent to [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1429) Error building Xerces with VC 7.1
[ http://issues.apache.org/jira/browse/XERCESC-1429?page=comments#action_12312761 ] Jesse Pelton commented on XERCESC-1429: --- Works for me with Visual Studio .NET 2003 (7.1.3088) using the following steps. - Download the current source from the Apache site (http://www.apache.org/dist/xml/xerces-c/xerces-c-current.zip). This includes the 2.6.0 code. - Unzip the archive with WinZip. - Open [install-directory]\xerces-c-src_2_6_0\Projects\Win32\VC7\xerces-all\xerces-all.sln. - Select "Build > Build Solution" from the menu. - Run a few sample applications to confirm the build succeeded. This also works if I build just the XercesLib project, though of course there are no samples to run. I don't have to make any modifications to the project files. Is your process different somehow? > Error building Xerces with VC 7.1 > - > > Key: XERCESC-1429 > URL: http://issues.apache.org/jira/browse/XERCESC-1429 > Project: Xerces-C++ > Type: Bug > Components: Build > Versions: 2.6.0 > Environment: Windows XP, Visual Studio C++ .NET (VC 7.1.3088) > Reporter: Daniel Gröndal > > First when opening the project I had to convert the project. When trying to > build XercesLib there were several compile errors related to .hpp-files > (object file asumed). This was resolved by changing the properties of the > project (using /TP). I also had to modify the project so that XercesDefs.hpp > is included. After these modifications the project compiles (with a few > warnings). > The problem is that I encouter several linkproblems: > \temp\xerces-c-current\xerces-c-src_2_6_0\Build\Win32\VC7\Release\obj\DOMImplementationimpl.obj > : warning LNK4042: object specified more than once; extras ignored > \temp\xerces-c-current\xerces-c-src_2_6_0\Build\Win32\VC7\Release\obj\DOMImplementationimpl.obj > : warning LNK4042: object specified more than once; extras ignored >Creating library ..\..\..\..\..\Build\Win32\VC7\Release/xerces-c_2.lib and > object ..\..\..\..\..\Build\Win32\VC7\Release/xerces-c_2.exp > TraverseSchema.obj : error LNK2001: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,unsigned short const * const,class > xercesc_2_6::MemoryManager * const)" ([EMAIL PROTECTED]@@[EMAIL > PROTECTED]@1@@Z) > DGXMLScanner.obj : error LNK2019: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,unsigned short const * const,class > xercesc_2_6::MemoryManager * const)" ([EMAIL PROTECTED]@@[EMAIL > PROTECTED]@1@@Z) referenced in function "private: virtual class > xercesc_2_6::InputSource * __thiscall > xercesc_2_6::DGXMLScanner::resolveSystemId(unsigned short const * const)" > ([EMAIL PROTECTED]@xercesc_2_6@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) > IGXMLScanner2.obj : error LNK2001: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,unsigned short const * const,class > xercesc_2_6::MemoryManager * const)" ([EMAIL PROTECTED]@@[EMAIL > PROTECTED]@1@@Z) > ReaderMgr.obj : error LNK2001: unresolved external symbol "public: __thiscall > xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned short const > * const,unsigned short const * const,class xercesc_2_6::MemoryManager * > const)" ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@1@@Z) > SGXMLScanner.obj : error LNK2001: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,unsigned short const * const,class > xercesc_2_6::MemoryManager * const)" ([EMAIL PROTECTED]@@[EMAIL > PROTECTED]@1@@Z) > XMLScanner.obj : error LNK2019: unresolved external symbol "public: > __thiscall xercesc_2_6::LocalFileInputSource::LocalFileInputSource(unsigned > short const * const,class xercesc_2_6::MemoryManager * const)" ([EMAIL > PROTECTED]@@[EMAIL PROTECTED]@1@@Z) referenced in function "public: void > __thiscall xercesc_2_6::XMLScanner::scanDocument(unsigned short const * > const)" ([EMAIL PROTECTED]@xercesc_2_6@@[EMAIL PROTECTED]) > AbstractDOMParser.obj : error LNK2019: unresolved external symbol "public: > static class xercesc_2_6::DOMImplementation * __cdecl > xercesc_2_6::DOMImplementationRegistry::getDOMImplementation(unsigned short > const *)" ([EMAIL PROTECTED]@xercesc_2_6@@[EMAIL PROTECTED]@[EMAIL > PROTECTED]) referenced in function "public: virtual void __thiscall > xercesc_2_6::AbstractDOMParser::startDocument(void)" ([EMAIL > PROTECTED]@xercesc_2_6@@UAEXXZ) > DOMDocumentTypeImpl.obj : error LNK2001: unresolved external symbol "public: > static class xercesc_2_6::DOMImplementation * __cdecl > xercesc_2_6::DOMImplementationRegistry::getDOMImplementation(unsigned short > const *)" ([EMAIL PROTECTED]@xercesc_2_6
