[jira] Commented: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API change?
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795030#action_12795030 ] Alberto Massari commented on XERCESC-1903: -- In that commit I have rewritten the way prefixes are resolved, making the resolveQName non-virtual and implemented in the base class XMLScanner. At that point the check done in the ElemStack was unnecessary, as it was already done earlier. For XQilla, it is now unnecessary to define SchemaValidatorFilter::resolveQName altogether and should be put inside an #ifdef As David said, both XMLScanner and ElemStack are internal classes, and we don't try to keep them unchanged between minor revisions. Alberto xerces-c-3.1.0-rc1: possible API change? Key: XERCESC-1903 URL: https://issues.apache.org/jira/browse/XERCESC-1903 Project: Xerces-C++ Issue Type: Bug Affects Versions: 3.1.0 Environment: debian Reporter: Jay Berkenbilt A debian user reports trouble compiling xqilla 2.2.2 (http://xqilla.sourceforge.net) with xerces-c 3.1.0 rc1 but says that it does compile with 3.0.1. We exchanged a few messages, but neither one of us is sure whether the code in question is using an internal interface that is not supposed to be part of the public API or whether this is an unintentional API incompatibility. I'm including the text of our latest email exchange here so you can make a judgment call on this before the final 3.1.0 is released. == I was compiling XQilla library version 2.2.2 from http://xqilla.sourceforge.net against Xerces-C in Debian, when I noticed that the xqilla library cannot be compiled against libxerces-c-dev 3.1.0~rc1, but it can compiled against version 3.0.1 still in testing. So it seems that version 3.1 breaks API compatibility. Are you and/or upstream developers aware of this? Is this actually a bug that I should report against libxerces-c-dev or not? I'm not aware of any expected API changes between 3.0.1 and 3.1.0, but I haven't checked with upstream. I believe the intention is not to introduce API compatibilities though. Please go ahead and file a bug against the debian package. Obviously any specific details you can provide would be helpful. I will then forward it to upstream. Thanks for bringing this to my attention! Hi, I looked now the error messages a bit more to see what was changed, and noticed that those API breaks are in a class definition in the subdir internal. Thus I now wonder if it counts as API break that would in the interest of the developers. Here is the compiler error I got: src/schema/SchemaValidatorFilter.cpp: In member function 'virtual unsigned int SchemaValidatorFilter::resolveQName(const XMLCh*, xercesc_3_1::XMLBuffer, short int, int)': src/schema/SchemaValidatorFilter.cpp:713: error: no matching function for call to 'xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh [], xercesc_3_1::ElemStack::MapModes, bool)' /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are: unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool) const src/schema/SchemaValidatorFilter.cpp:729: error: no matching function for call to 'xercesc_3_1::ElemStack::mapPrefixToURI(XMLCh*, xercesc_3_1::ElemStack::MapModes, bool)' /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are: unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool) const -- Tommi Vainikainen -- 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-1903) xerces-c-3.1.0-rc1: possible API change?
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795107#action_12795107 ] Jay Berkenbilt commented on XERCESC-1903: - All sounds great. Feel free to close this issue. I'll pass the information along. xerces-c-3.1.0-rc1: possible API change? Key: XERCESC-1903 URL: https://issues.apache.org/jira/browse/XERCESC-1903 Project: Xerces-C++ Issue Type: Bug Affects Versions: 3.1.0 Environment: debian Reporter: Jay Berkenbilt A debian user reports trouble compiling xqilla 2.2.2 (http://xqilla.sourceforge.net) with xerces-c 3.1.0 rc1 but says that it does compile with 3.0.1. We exchanged a few messages, but neither one of us is sure whether the code in question is using an internal interface that is not supposed to be part of the public API or whether this is an unintentional API incompatibility. I'm including the text of our latest email exchange here so you can make a judgment call on this before the final 3.1.0 is released. == I was compiling XQilla library version 2.2.2 from http://xqilla.sourceforge.net against Xerces-C in Debian, when I noticed that the xqilla library cannot be compiled against libxerces-c-dev 3.1.0~rc1, but it can compiled against version 3.0.1 still in testing. So it seems that version 3.1 breaks API compatibility. Are you and/or upstream developers aware of this? Is this actually a bug that I should report against libxerces-c-dev or not? I'm not aware of any expected API changes between 3.0.1 and 3.1.0, but I haven't checked with upstream. I believe the intention is not to introduce API compatibilities though. Please go ahead and file a bug against the debian package. Obviously any specific details you can provide would be helpful. I will then forward it to upstream. Thanks for bringing this to my attention! Hi, I looked now the error messages a bit more to see what was changed, and noticed that those API breaks are in a class definition in the subdir internal. Thus I now wonder if it counts as API break that would in the interest of the developers. Here is the compiler error I got: src/schema/SchemaValidatorFilter.cpp: In member function 'virtual unsigned int SchemaValidatorFilter::resolveQName(const XMLCh*, xercesc_3_1::XMLBuffer, short int, int)': src/schema/SchemaValidatorFilter.cpp:713: error: no matching function for call to 'xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh [], xercesc_3_1::ElemStack::MapModes, bool)' /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are: unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool) const src/schema/SchemaValidatorFilter.cpp:729: error: no matching function for call to 'xercesc_3_1::ElemStack::mapPrefixToURI(XMLCh*, xercesc_3_1::ElemStack::MapModes, bool)' /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are: unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool) const -- Tommi Vainikainen -- 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-1903) xerces-c-3.1.0-rc1: possible API change?
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795119#action_12795119 ] Boris Kolpackov commented on XERCESC-1903: -- We can also ask the XQilla folks to release 2.2.3 or some such to resolve this once 3.1.0 is out. xerces-c-3.1.0-rc1: possible API change? Key: XERCESC-1903 URL: https://issues.apache.org/jira/browse/XERCESC-1903 Project: Xerces-C++ Issue Type: Bug Affects Versions: 3.1.0 Environment: debian Reporter: Jay Berkenbilt A debian user reports trouble compiling xqilla 2.2.2 (http://xqilla.sourceforge.net) with xerces-c 3.1.0 rc1 but says that it does compile with 3.0.1. We exchanged a few messages, but neither one of us is sure whether the code in question is using an internal interface that is not supposed to be part of the public API or whether this is an unintentional API incompatibility. I'm including the text of our latest email exchange here so you can make a judgment call on this before the final 3.1.0 is released. == I was compiling XQilla library version 2.2.2 from http://xqilla.sourceforge.net against Xerces-C in Debian, when I noticed that the xqilla library cannot be compiled against libxerces-c-dev 3.1.0~rc1, but it can compiled against version 3.0.1 still in testing. So it seems that version 3.1 breaks API compatibility. Are you and/or upstream developers aware of this? Is this actually a bug that I should report against libxerces-c-dev or not? I'm not aware of any expected API changes between 3.0.1 and 3.1.0, but I haven't checked with upstream. I believe the intention is not to introduce API compatibilities though. Please go ahead and file a bug against the debian package. Obviously any specific details you can provide would be helpful. I will then forward it to upstream. Thanks for bringing this to my attention! Hi, I looked now the error messages a bit more to see what was changed, and noticed that those API breaks are in a class definition in the subdir internal. Thus I now wonder if it counts as API break that would in the interest of the developers. Here is the compiler error I got: src/schema/SchemaValidatorFilter.cpp: In member function 'virtual unsigned int SchemaValidatorFilter::resolveQName(const XMLCh*, xercesc_3_1::XMLBuffer, short int, int)': src/schema/SchemaValidatorFilter.cpp:713: error: no matching function for call to 'xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh [], xercesc_3_1::ElemStack::MapModes, bool)' /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are: unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool) const src/schema/SchemaValidatorFilter.cpp:729: error: no matching function for call to 'xercesc_3_1::ElemStack::mapPrefixToURI(XMLCh*, xercesc_3_1::ElemStack::MapModes, bool)' /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are: unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool) const -- Tommi Vainikainen -- 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
