You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <tu...@ws.apache.org> on 2008/03/21 21:37:27 UTC
[jira] Created: (TUSCANY-2113) Problem with fault comparison in
DataTransformationInterceptor; maybe we should compare elem QNames, not
type QNames?
Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
---------------------------------------------------------------------------------------------------------------------
Key: TUSCANY-2113
URL: https://issues.apache.org/jira/browse/TUSCANY-2113
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-1.1
Reporter: Scott Kurz
Fix For: Java-SCA-Next
There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
For one, I could have two distinct fault elems of the same type.
In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-2113) Problem with fault comparison in
DataTransformationInterceptor; maybe we should compare elem QNames, not
type QNames?
Posted by "Scott Kurz (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz updated TUSCANY-2113:
--------------------------------
Description:
There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
For one, I could have two distinct fault elems of the same type.
In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
@XmlType(name = ""..)
so we will build up an XMLType with typeName equal to a namespace plus a null name. One problem with this is that there is no way to distinguish between two elems with anonymous types.
I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making.
was:
There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
For one, I could have two distinct fault elems of the same type.
In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
> Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2113
> URL: https://issues.apache.org/jira/browse/TUSCANY-2113
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-1.1
> Reporter: Scott Kurz
> Fix For: Java-SCA-Next
>
>
> There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
> I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
> return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
> For one, I could have two distinct fault elems of the same type.
> In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
> @XmlType(name = ""..)
> so we will build up an XMLType with typeName equal to a namespace plus a null name. One problem with this is that there is no way to distinguish between two elems with anonymous types.
> I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Assigned: (TUSCANY-2113) Problem with fault comparison in
DataTransformationInterceptor; maybe we should compare elem QNames, not
type QNames?
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raymond Feng reassigned TUSCANY-2113:
-------------------------------------
Assignee: Raymond Feng
> Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2113
> URL: https://issues.apache.org/jira/browse/TUSCANY-2113
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-1.1
> Reporter: Scott Kurz
> Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
> I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
> return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
> For one, I could have two distinct fault elems of the same type.
> In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
> @XmlType(name = ""..)
> so we will build up an XMLType with typeName equal to a namespace plus a null name. One problem with this is that there is no way to distinguish between two fault elems in the same NS, with anonymous types.
> I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-2113) Problem with fault comparison in
DataTransformationInterceptor; maybe we should compare elem QNames, not
type QNames?
Posted by "Scott Kurz (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz updated TUSCANY-2113:
--------------------------------
Description:
There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
For one, I could have two distinct fault elems of the same type.
In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
@XmlType(name = ""..)
so we will build up an XMLType with typeName equal to a namespace plus a null name. One problem with this is that there is no way to distinguish between two fault elems in the same NS, with anonymous types.
I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making.
was:
There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
For one, I could have two distinct fault elems of the same type.
In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
@XmlType(name = ""..)
so we will build up an XMLType with typeName equal to a namespace plus a null name. One problem with this is that there is no way to distinguish between two elems with anonymous types.
I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making.
> Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2113
> URL: https://issues.apache.org/jira/browse/TUSCANY-2113
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-1.1
> Reporter: Scott Kurz
> Fix For: Java-SCA-Next
>
>
> There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
> I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
> return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
> For one, I could have two distinct fault elems of the same type.
> In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
> @XmlType(name = ""..)
> so we will build up an XMLType with typeName equal to a namespace plus a null name. One problem with this is that there is no way to distinguish between two fault elems in the same NS, with anonymous types.
> I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-2113) Problem with fault comparison in
DataTransformationInterceptor; maybe we should compare elem QNames, not
type QNames?
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589664#action_12589664 ]
Raymond Feng commented on TUSCANY-2113:
---------------------------------------
Hi, Scott.
Do you have a test case handy for this issue?
Thanks,
Raymond
> Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2113
> URL: https://issues.apache.org/jira/browse/TUSCANY-2113
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-1.1
> Reporter: Scott Kurz
> Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
> I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
> return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
> For one, I could have two distinct fault elems of the same type.
> In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
> @XmlType(name = ""..)
> so we will build up an XMLType with typeName equal to a namespace plus a null name. One problem with this is that there is no way to distinguish between two fault elems in the same NS, with anonymous types.
> I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-2113) Problem with fault comparison in
DataTransformationInterceptor; maybe we should compare elem QNames, not
type QNames?
Posted by "Scott Kurz (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589777#action_12589777 ]
Scott Kurz commented on TUSCANY-2113:
-------------------------------------
I'm sorry I don't have a test case handy.
If I look at itests, I see you could take:
sca/itest/exceptions-cross-binding-ws/src/main/resources/wsdl/StockExceptionTest.wsdl
and add another int, integer, or anonymous-typed fault
and expand the test in that way.
> Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2113
> URL: https://issues.apache.org/jira/browse/TUSCANY-2113
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-1.1
> Reporter: Scott Kurz
> Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
> I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
> return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
> For one, I could have two distinct fault elems of the same type.
> In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
> @XmlType(name = ""..)
> so we will build up an XMLType with typeName equal to a namespace plus a null name. One problem with this is that there is no way to distinguish between two fault elems in the same NS, with anonymous types.
> I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-2113) Problem with fault comparison in
DataTransformationInterceptor; maybe we should compare elem QNames, not
type QNames?
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raymond Feng resolved TUSCANY-2113.
-----------------------------------
Resolution: Fixed
Fixed under r650561
> Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2113
> URL: https://issues.apache.org/jira/browse/TUSCANY-2113
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SCA-1.1
> Reporter: Scott Kurz
> Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method.
> I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match.
> return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName());
> For one, I could have two distinct fault elems of the same type.
> In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like:
> @XmlType(name = ""..)
> so we will build up an XMLType with typeName equal to a namespace plus a null name. One problem with this is that there is no way to distinguish between two fault elems in the same NS, with anonymous types.
> I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.