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 Nadir Amra <am...@us.ibm.com> on 2006/04/05 01:14:35 UTC
C-support and array implementation
Getting close to have Doc-Literal support for the C-bindings working but I
have a question: I want to confirm my assumption that the sole reason for
the get() method in the Axis_Array class is in support of the C-bindings?
The reason I ask is that I want to change the implementation so that it
returns a new array that is malloc'ed instead of new'ed. Currently it
simply returns the actual array in the C++ object, but I do not think that
will work for the C bindings since the object will not be around, etc.
Otherwise, I will have to just create a new method that does what I want.
Please let me know the answer as soon as possible.
Nadir K. Amra
Re: Change prototypes for AXIS_OBJECT_CREATE_FUNCT
Posted by Nadir Amra <am...@us.ibm.com>.
I also forgot to mention that there will also be a semantic change to the
function body that is generated for
typedef void* (* AXIS_OBJECT_DELETE_FUNCT)(void**, bool bArray, int nSize)
Basically, the function should be able to delete an array of objects, but
should not delete the array itself since the creation of the array is done
elsewhere. In the case of the C++ generated code the array objects do not
even call this function to delete arrays, instead goes through a loop one
at a time to delete - probably could simplify to call function to delete
elements in array, but will leave for later). Similarily, the C bindings
create the array itself and expects to delete the array.
I will go through this and run the test bucket to ensure both changes do
not break anything.
Nadir K. Amra
Adrian Dick <ad...@uk.ibm.com> wrote on 04/19/2006 03:25:22 AM:
> Hi, Nadir,
>
> I've just taken a look at the various places the engine uses this, and
> agree these parameters are now redundant. Also, as you point out,
removing
> these will greatly simplify the generated code, and in turn the WSDL2Ws
> code.
>
> +1 from me.
>
> Regards,
> Adrian
> _______________________________________
> Adrian Dick (adrian.dick@uk.ibm.com)
>
>
> Nadir Amra <am...@us.ibm.com> wrote on 19/04/2006 05:33:40:
>
> > As I have been implementing the C bindings (getting close, AxisBench,
> > CalculatorDoc, and SimpleTypeArray works like a charm), I think we
should
>
> > be able to change the typedef for
> >
> > typedef void* (* AXIS_OBJECT_CREATE_FUNCT)(void**, bool bArray, int
> > nSize);
> >
> > and the corresponding code.
> >
> > With the new array inplementation and knowing that the C bindings do
not
> > need it I believe the prototype can change so that it is:
> >
> > typedef void* (* AXIS_OBJECT_CREATE_FUNCT)();
> >
> > It would simplify code (not only in generated code but in the java
> > generator).
> >
> > Any objections?
> >
> > Nadir K. Amra
> >
>
Re: Change prototypes for AXIS_OBJECT_CREATE_FUNCT
Posted by Adrian Dick <ad...@uk.ibm.com>.
Hi, Nadir,
I've just taken a look at the various places the engine uses this, and
agree these parameters are now redundant. Also, as you point out, removing
these will greatly simplify the generated code, and in turn the WSDL2Ws
code.
+1 from me.
Regards,
Adrian
_______________________________________
Adrian Dick (adrian.dick@uk.ibm.com)
Nadir Amra <am...@us.ibm.com> wrote on 19/04/2006 05:33:40:
> As I have been implementing the C bindings (getting close, AxisBench,
> CalculatorDoc, and SimpleTypeArray works like a charm), I think we should
> be able to change the typedef for
>
> typedef void* (* AXIS_OBJECT_CREATE_FUNCT)(void**, bool bArray, int
> nSize);
>
> and the corresponding code.
>
> With the new array inplementation and knowing that the C bindings do not
> need it I believe the prototype can change so that it is:
>
> typedef void* (* AXIS_OBJECT_CREATE_FUNCT)();
>
> It would simplify code (not only in generated code but in the java
> generator).
>
> Any objections?
>
> Nadir K. Amra
>
Change prototypes for AXIS_OBJECT_CREATE_FUNCT
Posted by Nadir Amra <am...@us.ibm.com>.
As I have been implementing the C bindings (getting close, AxisBench,
CalculatorDoc, and SimpleTypeArray works like a charm), I think we should
be able to change the typedef for
typedef void* (* AXIS_OBJECT_CREATE_FUNCT)(void**, bool bArray, int
nSize);
and the corresponding code.
With the new array inplementation and knowing that the C bindings do not
need it I believe the prototype can change so that it is:
typedef void* (* AXIS_OBJECT_CREATE_FUNCT)();
It would simplify code (not only in generated code but in the java
generator).
Any objections?
Nadir K. Amra
Re: Soap Fault handling bug?
Posted by Nadir Amra <am...@us.ibm.com>.
oops, never mind...must be working too hard. I read the code wrong. No
bug.
Nadir K. Amra
Nadir Amra/Rochester/IBM@IBMUS wrote on 05/22/2006 08:18:34 PM:
> I am looking at how fault handling is done, and I see that we generate
> code like the following (using FaultMappingDoc test case) when the
> CmplxFaultName does not match:
>
> else
> {
> const char *detail =
> pSoapFault->getSimpleFaultDetail();
> bool deleteDetail=false;
>
> if (NULL==detail || 0==strlen(detail))
> {
> detail=m_pCall->getFaultAsXMLString();
>
> if (NULL==detail)
> detail="";
> else
> deleteDetail=true;
> }
>
> OtherFaultException
> ofe(pSoapFault->getFaultcode(),
> pSoapFault->getFaultstring(),
> pSoapFault->getFaultactor(),
> detail, iExceptionCode);
>
> if (deleteDetail && NULL!=detail)
> Axis::AxisDelete( (void *)
> const_cast<char*>(detail), XSD_STRING);
>
> m_pCall->unInitialize();
> delete pSoapFault;
> throw ofe;
> }
>
> My question is whether the call to AxisDelete is a bug, since from what
I
> can tell getSimpleFaultDetail() does not return a new pointer.
>
> Nadir K. Amra
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Soap Fault handling bug?
Posted by Nadir Amra <am...@us.ibm.com>.
I am looking at how fault handling is done, and I see that we generate
code like the following (using FaultMappingDoc test case) when the
CmplxFaultName does not match:
else
{
const char *detail =
pSoapFault->getSimpleFaultDetail();
bool deleteDetail=false;
if (NULL==detail || 0==strlen(detail))
{
detail=m_pCall->getFaultAsXMLString();
if (NULL==detail)
detail="";
else
deleteDetail=true;
}
OtherFaultException
ofe(pSoapFault->getFaultcode(),
pSoapFault->getFaultstring(),
pSoapFault->getFaultactor(),
detail, iExceptionCode);
if (deleteDetail && NULL!=detail)
Axis::AxisDelete( (void *)
const_cast<char*>(detail), XSD_STRING);
m_pCall->unInitialize();
delete pSoapFault;
throw ofe;
}
My question is whether the call to AxisDelete is a bug, since from what I
can tell getSimpleFaultDetail() does not return a new pointer.
Nadir K. Amra
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
SoapDeSerializer::getFaultAsXMLString()
Posted by Nadir Amra <am...@us.ibm.com>.
Just want to confirm that this is a bug....
The return value is given as const xsd__string in
SoapDeSerializer::getFaultAsXMLString(), but in fact the storage is
dynamically allocated and thus needs to be deleted. I want to remote the
const from the return value. Any problems with this?
Nadir K. Amra
e-Business Technologies - IBM eServer i5/OS
IBM Rochester, MN, (Tel. 507-253-0645, t/l 553-0645)
Internet: amra@us.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: problems accessing SVN
Posted by Nabeel <na...@wso2.com>.
Nabeel wrote:
> Nadir Amra wrote:
>
>> I am having problems access SVN in order to do commits, compares,
>> etc. for the past couple of days. I get
>> could not connect to server (https://svn.apache.org)
>>
>> Anyone have the same problem? Has something changed?
>>
>> Nadir K. Amra
>>
>>
>>
>>
> There are some problems with the svn server. It has been down since
> yesterday. They are working on getting it up. Now only the right
> access to svn is given.
oops.. "Now only the right access..." should be "Now only the read
access..." :)
>
> -Nabeel
>
>
Re: problems accessing SVN
Posted by Nabeel <na...@wso2.com>.
Nadir Amra wrote:
>I am having problems access SVN in order to do commits, compares, etc. for
>the past couple of days. I get
>
>could not connect to server (https://svn.apache.org)
>
>Anyone have the same problem? Has something changed?
>
>Nadir K. Amra
>
>
>
>
There are some problems with the svn server. It has been down since
yesterday. They are working on getting it up. Now only the right access
to svn is given.
-Nabeel
problems accessing SVN
Posted by Nadir Amra <am...@us.ibm.com>.
I am having problems access SVN in order to do commits, compares, etc. for
the past couple of days. I get
could not connect to server (https://svn.apache.org)
Anyone have the same problem? Has something changed?
Nadir K. Amra
Re: Stub::SetSecure() question
Posted by Fred Preston <PR...@uk.ibm.com>.
Hi Nadir,
This is a bit of code that remained when I was looking at
configuring SSL. The code could be updated to the following...
m_sArguments[6] = "false";
if( (pszArg = pszArguments) != NULL)
{
do
{
if( pszArg == (char *) 1)
m_sArguments[iArgIndex] = "true";
else
m_sArguments[iArgIndex] = pszArg;
iArgIndex++;
}
while( (pszArg = va_arg( args, char *)) != NULL && iArgIndex < 8);
}
But there is no real reason for having this code and it could be
shortened to;-
if( (pszArg = pszArguments) != NULL)
{
do
{
m_sArguments[iArgIndex] = pszArg;
iArgIndex++;
}
while( (pszArg = va_arg( args, char *)) != NULL && iArgIndex < 8);
}
Regards,
Fred Preston.
Nadir Amra <am...@us.ibm.com>
28/04/2006 06:19
Please respond to
"Apache AXIS C Developers List" <ax...@ws.apache.org>
To
"Apache AXIS C Developers List" <ax...@ws.apache.org>
cc
Subject
Stub::SetSecure() question
There is a line of code that I do not quite understand in Stub::SetSecure.
Here is the routine:
va_list args;
char * pszArg = NULL;
va_start( args, pszArguments);
if( (pszArg = pszArguments) != NULL)
{
do
{
if( pszArg == (char *) 1)
m_sArguments[iArgIndex] = "true";
else
m_sArguments[iArgIndex] = pszArg;
iArgIndex++;
}
while( (pszArg = va_arg( args, char *)) != NULL && iArgIndex < 8);
if( iArgIndex == 6)
m_sArguments[iArgIndex] = "false";
}
va_end( args);
The line I do not understand is
if( pszArg == (char *) 1)
Can someone please explain how this works?
Nadir K. Amra
Stub::SetSecure() question
Posted by Nadir Amra <am...@us.ibm.com>.
There is a line of code that I do not quite understand in Stub::SetSecure.
Here is the routine:
va_list args;
char * pszArg = NULL;
va_start( args, pszArguments);
if( (pszArg = pszArguments) != NULL)
{
do
{
if( pszArg == (char *) 1)
m_sArguments[iArgIndex] = "true";
else
m_sArguments[iArgIndex] = pszArg;
iArgIndex++;
}
while( (pszArg = va_arg( args, char *)) != NULL && iArgIndex < 8);
if( iArgIndex == 6)
m_sArguments[iArgIndex] = "false";
}
va_end( args);
The line I do not understand is
if( pszArg == (char *) 1)
Can someone please explain how this works?
Nadir K. Amra
Re: C-support and array implementation
Posted by Adrian Dick <ad...@uk.ibm.com>.
Hi,
The get() method was not specifically provided to support C-bindings,
though it may coincidentally do this.
This was added as the data member m_Array, which is the C-style data array,
was made hidden from the user, so they need now need to make use of the set
and get methods to work with this.
As you say, it simply returns the actual array (m_Array), so a copy will
need to be taken if the Axis_Array object is likely to be deleted before
you're finished working with the C-style array.
I had considered implementing the get() method to return a deep copy of the
array, which would remove this problem, I had also intended to return the
data as const. But I found some users were already taking advantage of the
current design to modify the data. I guess what we really need is to add
in some of the common array operators (eg: []).
Alternatively, we could modify the get() method to have an additional and
optional parameter to indicate a deep copy is wanted, with the current
behaviour being the default.
I hope this is of help.
Regards,
Adrian
_______________________________________
Adrian Dick (adrian.dick@uk.ibm.com)
Nadir Amra <am...@us.ibm.com> wrote on 05/04/2006 00:14:35:
> Getting close to have Doc-Literal support for the C-bindings working but
I
> have a question: I want to confirm my assumption that the sole reason for
> the get() method in the Axis_Array class is in support of the C-bindings?
> The reason I ask is that I want to change the implementation so that it
> returns a new array that is malloc'ed instead of new'ed. Currently it
> simply returns the actual array in the C++ object, but I do not think
that
> will work for the C bindings since the object will not be around, etc.
> Otherwise, I will have to just create a new method that does what I want.
> Please let me know the answer as soon as possible.
>
>
> Nadir K. Amra
>