You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Jay Berkenbilt (JIRA)" <xe...@xml.apache.org> on 2009/12/27 23:12:29 UTC
[jira] Created: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API
change?
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API
change?
Posted by "Boris Kolpackov (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API
change?
Posted by "Alberto Massari (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API
change?
Posted by "Jay Berkenbilt (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Closed: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API
change?
Posted by "Alberto Massari (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alberto Massari closed XERCESC-1903.
------------------------------------
Resolution: Not A Problem
> 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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API
change?
Posted by "David Bertoni (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794890#action_12794890 ]
David Bertoni commented on XERCESC-1903:
----------------------------------------
By definition, anything in the "internal" directory is considered private, so it's not part of the public API.
I would defer to Alberto to comment on the change, since he made it, but it was part of revision 810580, and the log message indicates it was to improve performance. My guess would be the parser was never passing in MapModes::Mode_Attribute, so the parameter was effectively unused.
Looking at the XQilla code briefly, it looks like MapModes::Mode_Attribute is never used either.
> 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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org