You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by ax...@ws.apache.org on 2004/10/18 17:14:51 UTC
[jira] Created: (AXISCPP-207) Problems with Attributes and Stubs
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-207
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-207
Summary: Problems with Attributes and Stubs
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Basic Architecture
Fix Fors:
1.4 Alpha
Versions:
1.3 Final
Assignee:
Reporter: Mark Whitlock
Created: Mon, 18 Oct 2004 8:14 AM
Updated: Mon, 18 Oct 2004 8:14 AM
Description:
Stub::setSOAPMethodAttribute(const AxisChar* pLocalName, const AxisChar* pPrefix, const AxisChar* pValue) looks to see if an attribute of that localName already exists, and if so, deletes it first before creating the new Attribute. But setSOAPMethodAttribute(const AxisChar* pLocalName, const AxisChar* pPrefix, const AxisChar* pUri, const AxisChar* pValue) doesn't look for duplicate localNames before it creates the new Attribute. This looks like a bug. I can fix it but I'm not familiar with this area of the code so I'm not sure whether it's deliberate. Anyone know? Otherwise I'll assume it's a bug and fix it.
Currently it is up to the client application to delete the Attributes that it created using Stub::setSOAPMethodAttribute, because the application may want to reuse these Attributes on another Stub. But there is no Stub::setSOAPMethodAttribute(IAttribute *pAttribute), so reusing an Attribute is impossible. Also deleting these Attributes is awkward since there is no method that deletes all the Attributes. So I propose deleting all Attributes in ~Stub.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXISCPP-207) Problems with Attributes and Stubs
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-207?page=history ]
Mark Whitlock closed AXISCPP-207:
---------------------------------
Resolution: Fixed
Fix Version: current (nightly)
(was: 1.4 Alpha)
Fixed as suggested. Now both setSOAPMethodAttribute calls check for duplicates and the Attributes are deleted in ~Stub.
> Problems with Attributes and Stubs
> ----------------------------------
>
> Key: AXISCPP-207
> URL: http://issues.apache.org/jira/browse/AXISCPP-207
> Project: Axis-C++
> Type: Bug
> Components: Client - Stub
> Versions: 1.3 Final
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
> Fix For: current (nightly)
>
> Stub::setSOAPMethodAttribute(const AxisChar* pLocalName, const AxisChar* pPrefix, const AxisChar* pValue) looks to see if an attribute of that localName already exists, and if so, deletes it first before creating the new Attribute. But setSOAPMethodAttribute(const AxisChar* pLocalName, const AxisChar* pPrefix, const AxisChar* pUri, const AxisChar* pValue) doesn't look for duplicate localNames before it creates the new Attribute. This looks like a bug. I can fix it but I'm not familiar with this area of the code so I'm not sure whether it's deliberate. Anyone know? Otherwise I'll assume it's a bug and fix it.
> Currently it is up to the client application to delete the Attributes that it created using Stub::setSOAPMethodAttribute, because the application may want to reuse these Attributes on another Stub. But there is no Stub::setSOAPMethodAttribute(IAttribute *pAttribute), so reusing an Attribute is impossible. Also deleting these Attributes is awkward since there is no method that deletes all the Attributes. So I propose deleting all Attributes in ~Stub.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-207) Problems with Attributes and Stubs
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-207?page=history ]
Samisa Abeysinghe updated AXISCPP-207:
--------------------------------------
Component: Client - Stub
(was: Basic Architecture)
> Problems with Attributes and Stubs
> ----------------------------------
>
> Key: AXISCPP-207
> URL: http://issues.apache.org/jira/browse/AXISCPP-207
> Project: Axis-C++
> Type: Bug
> Components: Client - Stub
> Versions: 1.3 Final
> Reporter: Mark Whitlock
> Assignee: Mark Whitlock
> Fix For: 1.4 Alpha
>
> Stub::setSOAPMethodAttribute(const AxisChar* pLocalName, const AxisChar* pPrefix, const AxisChar* pValue) looks to see if an attribute of that localName already exists, and if so, deletes it first before creating the new Attribute. But setSOAPMethodAttribute(const AxisChar* pLocalName, const AxisChar* pPrefix, const AxisChar* pUri, const AxisChar* pValue) doesn't look for duplicate localNames before it creates the new Attribute. This looks like a bug. I can fix it but I'm not familiar with this area of the code so I'm not sure whether it's deliberate. Anyone know? Otherwise I'll assume it's a bug and fix it.
> Currently it is up to the client application to delete the Attributes that it created using Stub::setSOAPMethodAttribute, because the application may want to reuse these Attributes on another Stub. But there is no Stub::setSOAPMethodAttribute(IAttribute *pAttribute), so reusing an Attribute is impossible. Also deleting these Attributes is awkward since there is no method that deletes all the Attributes. So I propose deleting all Attributes in ~Stub.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira