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 damitha kumarage <da...@opensource.lk> on 2004/07/22 11:31:32 UTC
Re: Unexpected #includes within WSDL2Ws generated
AxisClientException.h
On Wed, 2004-07-21 at 16:22, John Hawkins wrote:
>
> Hi Nithya,
>
> Trying really hard to understand why this was designed like this :-(
>
> OK, here's the questions:
>
> 1) Why are there so many constructors for the AxisClientException and
> therefore so many processExceptions? When would each one be called?
I'll include the api documentation for each in exception header file.
> 2) Why is the documentation in the samples - this is a key part of the API
> and should be documented as such.
documentation is not in the samples. For testing the fault mapping a
test case is created in tests/server/exceptionTest and
tests/client/fault-mapping. For testing the exceptions in general a test
case generated in test/server/exceptionTest and
test/cleint/exceptionTest. In each of these folders README file it
describe how the fault mapping works and exception model works and how
to test it.
Yes we need to include the documentation of how the fault mapping works
and exception model works in the user documentation.
> 3) This design does not appear to work for anything other than a one-to-one
> relationship between stub and client using stub e.g:
>
> If I have a client that uses multiple stubs. I package each client in a
> seperate library, there is only one AxisClientException which has to handle
> all the logic for all the services I'm calling - yuck ! Bad Object model
> and bad model for maintenance too.
>
> Suggestions-
> 1) Put docs into the proper place !
> 2) Create multiple client exceptions using sensible naming scheme - i.e.
> AxisClient<ServiceName>ServiceException. This way I can put the service
> specific logic into one class.
Yes this is good thing. For the stub accessing the Foo service we can
name the client exception generated as AxisFooClientException.
This is just a matter of renaming the exception generated according to
the service it request.
>
> thoughts please - this is hitting us now so a prompt response would be very
> much appreciated - thankyou,
> John.
>
thanks
damitha
>
>
>
>
>
>
>
>
>
> nithya@opensource
> .lk
> To
> 21/07/2004 05:15 "Apache AXIS C Developers List"
> <ax...@ws.apache.org>
> cc
> Please respond to
> "Apache AXIS C Subject
> Developers List" Re: Unexpected #includes within
> WSDL2Ws generated
> AxisClientException.h
>
>
>
>
>
>
>
>
>
>
> Hi,
>
> is this documented somewhere?
>
> Inside the README file of fault_mapping folder, the documentation is
> available.
>
> Exact location is as follows:
>
> vi $AXISCPP_HOME/tests/client/fault_mapping/README
>
> rgds,
> Nithya.
>
> >
> >
> > Ohhh,
> >
> > is this documented somewhere?
> >
> >
> >
> >
> >
> > John Hawkins
> >
> >
> >
> >
> >
> > nithya@opensource
> > .lk
> >
> To
> > 16/07/2004 06:07 "Apache AXIS C Developers List"
> > <ax...@ws.apache.org>
> >
> cc
> > Please respond to
> > "Apache AXIS C
> Subject
> > Developers List" Re: Unexpected #includes within
> > WSDL2Ws generated
> > AxisClientException.h
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Adrian,
> >
> >> However, looking through the rest of the AxisClientException code, there
> >> are no further references to the fault types. Which, for me, raises
> >> the
> >> further question - Why are we including the fault types, if they're not
> >> actually being used?
> >
> > The fault types may be used by the user to extract the fault message in
> > the processException(ISoapFault* pFault).
> > For example in
> > $AXISCPP_HOME/tests/client/fault_mapping/gen_src/AxisClientException.cpp
> > -----------------------------------------------------------------
> > void AxisClientException::processException (ISoapFault* pFault)
> > {
> > /*User can do something like deserializing the struct into a
> > string*/
> > const char* pcCmplxFaultName;
> > const char* pcDetail;
> > if(pFault)
> > {
> > m_sMessage = "Fault Code:";
> > m_sMessage += pFault->getFaultcode();
> > m_sMessage += "\n";
> > m_sMessage += "Fault String:";
> > m_sMessage += pFault->getFaultstring();
> > m_sMessage += "\n";
> > m_sMessage += "Fault Actor:";
> > m_sMessage += pFault->getFaultactor();
> > m_sMessage += "\n";
> >
> > pcDetail = pFault->getSimpleFaultDetail().c_str();
> > if(NULL != pcDetail && 0 != strcmp("", pcDetail))
> > m_sMessage += pcDetail;
> > else
> > {
> > pcCmplxFaultName = pFault->getCmplxFaultObjectName().c_str();
> > //printf("pcCmplxFaultName:%s\n", pcCmplxFaultName);
> > }
> > if(0 == strcmp("OutOfBoundStruct", pcCmplxFaultName))
> > {
> > OutOfBoundStruct* pFaultDetail = NULL;
> > pFaultDetail = (OutOfBoundStruct*)pFault->
> > getCmplxFaultObject();
> > SpecialDetailStruct* pSpecialFaultDetail =
> > pFaultDetail->specialDetail;
> >
> > m_sMessage += pFaultDetail->varString;
> > m_sMessage += ":";
> > m_sMessage += pSpecialFaultDetail->varString;
> > }
> > else if(0 == strcmp("SpecialDetailStruct", pcCmplxFaultName))
> > {
> > SpecialDetailStruct* pFaultDetail = NULL;
> > pFaultDetail = (SpecialDetailStruct*)pFault->
> > getCmplxFaultObject();
> >
> > m_sMessage += pFaultDetail->varString;
> > }
> > else if(0 == strcmp("DivByZeroStruct", pcCmplxFaultName))
> > {
> > DivByZeroStruct* pFaultDetail = NULL;
> > pFaultDetail = (DivByZeroStruct*)pFault->
> > getCmplxFaultObject();
> > char* carrTempBuff =new char[4 * sizeof(char)];
> > sprintf(carrTempBuff, "%d", pFaultDetail->varInt);
> > m_sMessage += string(carrTempBuff);
> > m_sMessage += "\n";
> >
> > sprintf(carrTempBuff, "%f", pFaultDetail->varFloat);
> > m_sMessage += string(carrTempBuff);
> > m_sMessage += "\n";
> >
> > m_sMessage += pFaultDetail->varString;
> > }
> > }
> > }
> > ----------------------------------------------------------------
> > Since the user has the knowledge of those fault-types he can extract
> > the info from them as above.
> >
> > rgds,
> > Nithya
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
Re: Unexpected #includes within WSDL2Ws generated AxisClientException.h
Posted by John Hawkins <HA...@uk.ibm.com>.
Great, thanks for your very positive responses (I think I was a bit hard
yesterday - sorry!). Were you thinking of doing the new naming scheme for
the exception and if so when do you think this could be done by?
John Hawkins
damitha kumarage
<damitha@opensour
ce.lk> To
Apache AXIS C Developers List
22/07/2004 10:31 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Unexpected #includes within
Developers List" WSDL2Ws generated
AxisClientException.h
On Wed, 2004-07-21 at 16:22, John Hawkins wrote:
>
> Hi Nithya,
>
> Trying really hard to understand why this was designed like this :-(
>
> OK, here's the questions:
>
> 1) Why are there so many constructors for the AxisClientException and
> therefore so many processExceptions? When would each one be called?
I'll include the api documentation for each in exception header file.
> 2) Why is the documentation in the samples - this is a key part of the
API
> and should be documented as such.
documentation is not in the samples. For testing the fault mapping a
test case is created in tests/server/exceptionTest and
tests/client/fault-mapping. For testing the exceptions in general a test
case generated in test/server/exceptionTest and
test/cleint/exceptionTest. In each of these folders README file it
describe how the fault mapping works and exception model works and how
to test it.
Yes we need to include the documentation of how the fault mapping works
and exception model works in the user documentation.
> 3) This design does not appear to work for anything other than a
one-to-one
> relationship between stub and client using stub e.g:
>
> If I have a client that uses multiple stubs. I package each client in a
> seperate library, there is only one AxisClientException which has to
handle
> all the logic for all the services I'm calling - yuck ! Bad Object model
> and bad model for maintenance too.
>
> Suggestions-
> 1) Put docs into the proper place !
> 2) Create multiple client exceptions using sensible naming scheme - i.e.
> AxisClient<ServiceName>ServiceException. This way I can put the service
> specific logic into one class.
Yes this is good thing. For the stub accessing the Foo service we can
name the client exception generated as AxisFooClientException.
This is just a matter of renaming the exception generated according to
the service it request.
>
> thoughts please - this is hitting us now so a prompt response would be
very
> much appreciated - thankyou,
> John.
>
thanks
damitha
>
>
>
>
>
>
>
>
>
> nithya@opensource
> .lk
>
To
> 21/07/2004 05:15 "Apache AXIS C Developers List"
> <ax...@ws.apache.org>
>
cc
> Please respond to
> "Apache AXIS C
Subject
> Developers List" Re: Unexpected #includes within
> WSDL2Ws generated
> AxisClientException.h
>
>
>
>
>
>
>
>
>
>
> Hi,
>
> is this documented somewhere?
>
> Inside the README file of fault_mapping folder, the documentation is
> available.
>
> Exact location is as follows:
>
> vi $AXISCPP_HOME/tests/client/fault_mapping/README
>
> rgds,
> Nithya.
>
> >
> >
> > Ohhh,
> >
> > is this documented somewhere?
> >
> >
> >
> >
> >
> > John Hawkins
> >
> >
> >
> >
> >
> > nithya@opensource
> > .lk
> >
> To
> > 16/07/2004 06:07 "Apache AXIS C Developers List"
> > <ax...@ws.apache.org>
> >
> cc
> > Please respond to
> > "Apache AXIS C
> Subject
> > Developers List" Re: Unexpected #includes within
> > WSDL2Ws generated
> > AxisClientException.h
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Adrian,
> >
> >> However, looking through the rest of the AxisClientException code,
there
> >> are no further references to the fault types. Which, for me, raises
> >> the
> >> further question - Why are we including the fault types, if they're
not
> >> actually being used?
> >
> > The fault types may be used by the user to extract the fault message in
> > the processException(ISoapFault* pFault).
> > For example in
> >
$AXISCPP_HOME/tests/client/fault_mapping/gen_src/AxisClientException.cpp
> > -----------------------------------------------------------------
> > void AxisClientException::processException (ISoapFault* pFault)
> > {
> > /*User can do something like deserializing the struct into a
> > string*/
> > const char* pcCmplxFaultName;
> > const char* pcDetail;
> > if(pFault)
> > {
> > m_sMessage = "Fault Code:";
> > m_sMessage += pFault->getFaultcode();
> > m_sMessage += "\n";
> > m_sMessage += "Fault String:";
> > m_sMessage += pFault->getFaultstring();
> > m_sMessage += "\n";
> > m_sMessage += "Fault Actor:";
> > m_sMessage += pFault->getFaultactor();
> > m_sMessage += "\n";
> >
> > pcDetail = pFault->getSimpleFaultDetail().c_str();
> > if(NULL != pcDetail && 0 != strcmp("", pcDetail))
> > m_sMessage += pcDetail;
> > else
> > {
> > pcCmplxFaultName = pFault->getCmplxFaultObjectName().c_str();
> > //printf("pcCmplxFaultName:%s\n", pcCmplxFaultName);
> > }
> > if(0 == strcmp("OutOfBoundStruct", pcCmplxFaultName))
> > {
> > OutOfBoundStruct* pFaultDetail = NULL;
> > pFaultDetail = (OutOfBoundStruct*)pFault->
> > getCmplxFaultObject();
> > SpecialDetailStruct* pSpecialFaultDetail =
> > pFaultDetail->specialDetail;
> >
> > m_sMessage += pFaultDetail->varString;
> > m_sMessage += ":";
> > m_sMessage += pSpecialFaultDetail->varString;
> > }
> > else if(0 == strcmp("SpecialDetailStruct",
pcCmplxFaultName))
> > {
> > SpecialDetailStruct* pFaultDetail = NULL;
> > pFaultDetail = (SpecialDetailStruct*)pFault->
> > getCmplxFaultObject();
> >
> > m_sMessage += pFaultDetail->varString;
> > }
> > else if(0 == strcmp("DivByZeroStruct", pcCmplxFaultName))
> > {
> > DivByZeroStruct* pFaultDetail = NULL;
> > pFaultDetail = (DivByZeroStruct*)pFault->
> > getCmplxFaultObject();
> > char* carrTempBuff =new char[4 * sizeof(char)];
> > sprintf(carrTempBuff, "%d", pFaultDetail->varInt);
> > m_sMessage += string(carrTempBuff);
> > m_sMessage += "\n";
> >
> > sprintf(carrTempBuff, "%f", pFaultDetail->varFloat);
> > m_sMessage += string(carrTempBuff);
> > m_sMessage += "\n";
> >
> > m_sMessage += pFaultDetail->varString;
> > }
> > }
> > }
> > ----------------------------------------------------------------
> > Since the user has the knowledge of those fault-types he can extract
> > the info from them as above.
> >
> > rgds,
> > Nithya
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>