You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by John Hawkins <HA...@uk.ibm.com> on 2004/10/01 14:41:50 UTC
Fw: Re:failure notice
>From Fred preston ->
Hi Adrian.
I've started looking at the fault object model and it is in a bit of
a mess. Currently, faults come back as exceptions from the stub as a
<ServiceName>_AxisClientException. The actual exception is wrapped inside
the exception object. You then have to unwrap the exception to find what
the real exception was. i.e.
catch( ServiceName_AxisClientException e)
{
ISoapFault * pFault = (ISoapFault *) e.getFault(); // NB: You will
probably need
// to download latest
axis code
// to get this method.
string faultDetail = pFault->getSimpleFaultDetail();
string faultClassName = "<none>";
int iExceptionCode = e.getExceptionCode();
string sExceptionString = e.getMessage( iExceptionCode);
if( faultDetail.length() == 0)
{
if( !pFault->getCmplxFaultObjectName().compare( "ExceptionName"))
{
faultClassName = pFault->getCmplxFaultObjectName();
ExceptionNameType* pENT = (ExceptionNameType*)
pFault->getCmplxFaultObject();
if( pENT)
{
faultDetail = pENT->....;
}
else
{
faultDetail = "Unknown type:" + faultClassName;
}
}
}
}
What I'm proposing is that we have the following model
+---------------------+
| AxisClientException |
+---------------------+
| |
+-----------------------+ +----------------+
| ServiceName_Exception | | FaultException |
+-----------------------+ +----------------+
Where you can catch either a Fault or Service exception directly or catch
the generic AxisClientException and then unwrap. This removes the need for
catching the generic exception (and then unwrapping) if you know what
faults to expect. A fault exception is identical to the fault reply in the
WSDL and a ServiceName_Exeception is only ever used for a system fault (for
example, if there is a connection problem). An example of a fault
exception is shown below:-
If you have the following WSDL...
Service Binding Port Type Message Name
Type
------------------+-----------------+---------------+-------------+----------+-------------------------------
myTestServ ------> myTestBind myTestPT
mTest mTest
i: -------------> i: ---------> myTestIn mIn
xsd:string
o: -------------> o: ---------> myTestOut mOut
xsd:int
f: -------------> f: ---------> myTestFault mFault
{Info xsd:string, Code xsd:int}
Then the client will be coded as follows:-
try
{
myTestServ * myService = new myTestServ( "someUri");
string text = "Hello";
int iRetValue = myService->mTest( text);
cout << text << " has " << iRetValue << " e's" << endl;
}
catch( myTestFaultType f)
{
cout << "Error info " << f.Info << endl;
cout << "Error code " << f.Code << endl;
}
Thus the client now catches the exception type as described in the WSDL.
If the client application uses more than one service or method within a
service then the calls may have to be separated by individual try catch
blocks (depending on the uniqueness of the expected exceptions) to ensure
that the code knows where or when an exception occurred.
Does anyone have any comments on this proposed update?
Regards,
Fred Preston.
<adrian.p.smith@b
t.com>
To
30/09/2004 13:48 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C RE: failure notice
User List"
Better SOAP:Fault handling - i.e. be able to access the fields within the
SOAP:Fault from a client.
-----Original Message-----
From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
Sent: 30 September 2004 13:34
To: axis-c-user@ws.apache.org
Subject: Re: failure notice
Hi Folks,
Big note coming up !
I would like to propose some features that we should put into 1.4. I would
like to know what everyone is thinking is useful to have in the 1.4 release
and this small list should act as a starter.
C support -
firstly define feasibility of making a 100% C++ engine and design,
then (if feasible) implement.
We will temporarily remove C support in 1.4 to be replaced in 1.5
with new wrapper.
Apache Builds -
This item is all about getting a daily build. We must also create all
the relevant web pages so it's usable.
We will build the client first then the server.
Refactor WSDL2WS -
As it says ! This is a pretty much open-ended item so we do as much
as we can. Remember - at this point we have no C support so anything we can
do here to make that easier to reimplement C in 1.5 is good !
Test documentation -
document the handler mechanism and other test related stuff we have.
AND - A Quick overview of 1.5 work
1.5
C support -
put back into WSDL2 WS C wrappers for the new 100% C++ engine
Purify and fix -
As it says - run Rational purify and tackle issues that come out of
it.
Improve HTTP Support.
Fix outstanding issues with HTTP support in the new transport layer.
There is a lot we can do here and we haven't really defined what it highest
priority.
Documentation
User documentation and CVS based documentation. including sample can
be improved
With the resource that we have here - we can contain all the above 1.4
items within a 24th November Time-schedule. I would like to propose that we
try to maintain this shorter time-line for releases. That way we keep new
function to a minimum and therefore maintain stability within builds.
I would also like to propose that we move away from our current waterfall
model of code then test. When we have daily builds we can see immediately
what has broken and this will help us tremedously. The more we automate our
testing the better. The one issue with this is that the daily builds will
only cover certain compilation options (as discussed in previous mails).
The test-cycle now appears to consist of running the same tests on
different configurations - is this true? In which case I would ask that
someone find the time to automate those configurations and run them daily
as well?
Please can you feedback your thoughts and ideas on what we should put into
1.4 and what you would like to see in 1.4 We can then make a judgement as
to what the final goal is to be.
many thanks,
John.
IGNORE Previous SOAP question
Posted by John Hawkins <HA...@uk.ibm.com>.
Please Ignore that I've just found the documentation !
John Hawkins
John
Hawkins/UK/IBM@IB
MGB To
axis-c-dev@ws.apache.org
07/10/2004 11:52 cc
Subject
Please respond to Re: Fw: Re:failure notice
"Apache AXIS C
Developers List"
I've been looking into faultcodes in quite some detail due to these notes
and I need to know what SOAP level we are supporting before I comment on
the note from Damitha,
So, do we support both 1.1 and 1.2?
John Hawkins
damitha kumarage
<damitha@opensour
ce.lk> To
Apache AXIS C User List
05/10/2004 10:52 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Fw: Re:failure notice
User List"
Hi,
Since now we are going to make axis engine more of c++ I suggest
following fault handling.
Derive all complex faults defined in wsdl from a base type. Say
AxisFault.
This base type has methods to serialize, deserialize.
When engine identify that the message in the wire is soap fault
1) If that fault is not a service generated one(generated by
the axis engine itself) then it throw a FaultException which
has accessors for fault code, fault string, fault actor and
fault detail which is a simple string in this case.
2) If that fault is service generated one it throw a
FaultException which has accessors for fault code, fault string,
fault actor but fault detail empty. Since the knowledge to
deserializing
the complex fault detail is with the wsdl generated types which is
with the client, when we receive the FaultException the
fault detail is null. Client need to get the fault detail name
and then create the corresponding fault detail.
Following snippets will explain further.
In the deserializer
...
FaultException* pFaultExceptin = new FaultException(this);//Pass
this deserializer into constructor
pFaultException->setFaultCode(faultcode);
pFaultException->setFaultString(faultcode);
pFaultException->setFaultActor(faultcode);
pcDetail = getElementAsString("detail", 0);
if(pcDetail)
pFaultException->setFaultDetail(pcDetail);
throw pFaultException;
...
Now In client code
...
catch(FaultException& e)
{
String sFaultCode = e.getFaultCode();
String sFaultString = e.getFaultString();
String sFaultActor = e.getFaultActor();
String sFaultDetail = e.getFaultDetail();
if(0 == sFaultDetail.length())//The fault is a service thrown one
{
if(e.getDetailName().compare("DivByZeroType"))
{
DivByZeroType* pDivByZero = new DivByZeroType();
sFaultDetail = e.getFaultDetail(pDivByZero);
}
}
}
...
So in FaultException we have a method
...
String getFaultDetail(BaseFaultType* faultType)
{
return pDZ->getFaultDetail(faultType);
}
...
So in SoapDeserializer we have
...
String getFaultDetail(BaseFaultType* faultType)
{
return faultType->deserialize();
}
...
I think this approach is simple. What do you think?
On Fri, 2004-10-01 at 18:41, John Hawkins wrote:
thanks
damitha
>
>
> >From Fred preston ->
>
>
>
>
>
> Hi Adrian.
> I've started looking at the fault object model and it is in a bit
of
> a mess. Currently, faults come back as exceptions from the stub as a
> <ServiceName>_AxisClientException. The actual exception is wrapped
inside
> the exception object. You then have to unwrap the exception to find what
> the real exception was. i.e.
>
> catch( ServiceName_AxisClientException e)
> {
> ISoapFault * pFault = (ISoapFault *) e.getFault(); // NB: You will
> probably need
> // to download
latest
> axis code
> // to get this
method.
> string faultDetail = pFault->getSimpleFaultDetail();
> string faultClassName = "<none>";
> int iExceptionCode = e.getExceptionCode();
> string sExceptionString = e.getMessage( iExceptionCode);
>
> if( faultDetail.length() == 0)
> {
> if( !pFault->getCmplxFaultObjectName().compare( "ExceptionName"))
> {
> faultClassName = pFault->getCmplxFaultObjectName();
>
> ExceptionNameType* pENT = (ExceptionNameType*)
> pFault->getCmplxFaultObject();
>
> if( pENT)
> {
> faultDetail = pENT->....;
> }
> else
> {
> faultDetail = "Unknown type:" + faultClassName;
> }
> }
> }
> }
>
> What I'm proposing is that we have the following model
>
> +---------------------+
> | AxisClientException |
> +---------------------+
> | |
> +-----------------------+ +----------------+
> | ServiceName_Exception | | FaultException |
> +-----------------------+ +----------------+
>
> Where you can catch either a Fault or Service exception directly or catch
> the generic AxisClientException and then unwrap. This removes the need
for
> catching the generic exception (and then unwrapping) if you know what
> faults to expect. A fault exception is identical to the fault reply in
the
> WSDL and a ServiceName_Exeception is only ever used for a system fault
(for
> example, if there is a connection problem). An example of a fault
> exception is shown below:-
>
> If you have the following WSDL...
>
> Service Binding Port Type Message Name
> Type
>
------------------+-----------------+---------------+-------------+----------+-------------------------------
>
> myTestServ ------> myTestBind myTestPT
> mTest mTest
> i: -------------> i: ---------> myTestIn mIn
> xsd:string
> o: -------------> o: ---------> myTestOut mOut
> xsd:int
> f: -------------> f: ---------> myTestFault mFault
> {Info xsd:string, Code xsd:int}
>
> Then the client will be coded as follows:-
>
> try
> {
> myTestServ * myService = new myTestServ( "someUri");
>
> string text = "Hello";
>
> int iRetValue = myService->mTest( text);
>
> cout << text << " has " << iRetValue << " e's" << endl;
> }
> catch( myTestFaultType f)
> {
> cout << "Error info " << f.Info << endl;
> cout << "Error code " << f.Code << endl;
> }
>
> Thus the client now catches the exception type as described in the WSDL.
>
> If the client application uses more than one service or method within a
> service then the calls may have to be separated by individual try catch
> blocks (depending on the uniqueness of the expected exceptions) to ensure
> that the code knows where or when an exception occurred.
>
> Does anyone have any comments on this proposed update?
>
> Regards,
>
> Fred Preston.
>
>
> <adrian.p.smith@b
> t.com>
>
To
> 30/09/2004 13:48 <ax...@ws.apache.org>
>
cc
>
> Please respond to
Subject
> "Apache AXIS C RE: failure notice
> User List"
>
>
>
>
>
>
>
>
>
> Better SOAP:Fault handling - i.e. be able to access the fields within the
> SOAP:Fault from a client.
>
>
>
> -----Original Message-----
> From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
> Sent: 30 September 2004 13:34
> To: axis-c-user@ws.apache.org
> Subject: Re: failure notice
>
>
>
>
>
>
> Hi Folks,
>
> Big note coming up !
>
> I would like to propose some features that we should put into 1.4. I
would
> like to know what everyone is thinking is useful to have in the 1.4
release
> and this small list should act as a starter.
>
>
>
> C support -
> firstly define feasibility of making a 100% C++ engine and design,
> then (if feasible) implement.
> We will temporarily remove C support in 1.4 to be replaced in 1.5
> with new wrapper.
>
> Apache Builds -
> This item is all about getting a daily build. We must also create
all
> the relevant web pages so it's usable.
> We will build the client first then the server.
>
> Refactor WSDL2WS -
> As it says ! This is a pretty much open-ended item so we do as much
> as we can. Remember - at this point we have no C support so anything we
can
> do here to make that easier to reimplement C in 1.5 is good !
>
> Test documentation -
> document the handler mechanism and other test related stuff we
have.
>
>
> AND - A Quick overview of 1.5 work
> 1.5
> C support -
> put back into WSDL2 WS C wrappers for the new 100% C++ engine
>
> Purify and fix -
> As it says - run Rational purify and tackle issues that come out of
> it.
>
> Improve HTTP Support.
> Fix outstanding issues with HTTP support in the new transport
layer.
> There is a lot we can do here and we haven't really defined what it
highest
> priority.
>
> Documentation
> User documentation and CVS based documentation. including sample
can
> be improved
>
>
>
> With the resource that we have here - we can contain all the above 1.4
> items within a 24th November Time-schedule. I would like to propose that
we
> try to maintain this shorter time-line for releases. That way we keep new
> function to a minimum and therefore maintain stability within builds.
>
> I would also like to propose that we move away from our current waterfall
> model of code then test. When we have daily builds we can see immediately
> what has broken and this will help us tremedously. The more we automate
our
> testing the better. The one issue with this is that the daily builds will
> only cover certain compilation options (as discussed in previous mails).
> The test-cycle now appears to consist of running the same tests on
> different configurations - is this true? In which case I would ask that
> someone find the time to automate those configurations and run them daily
> as well?
>
> Please can you feedback your thoughts and ideas on what we should put
into
> 1.4 and what you would like to see in 1.4 We can then make a judgement as
> to what the final goal is to be.
>
>
> many thanks,
> John.
>
>
>
Re: Fw: Re:failure notice
Posted by John Hawkins <HA...@uk.ibm.com>.
I've been looking into faultcodes in quite some detail due to these notes
and I need to know what SOAP level we are supporting before I comment on
the note from Damitha,
So, do we support both 1.1 and 1.2?
John Hawkins
damitha kumarage
<damitha@opensour
ce.lk> To
Apache AXIS C User List
05/10/2004 10:52 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Fw: Re:failure notice
User List"
Hi,
Since now we are going to make axis engine more of c++ I suggest
following fault handling.
Derive all complex faults defined in wsdl from a base type. Say
AxisFault.
This base type has methods to serialize, deserialize.
When engine identify that the message in the wire is soap fault
1) If that fault is not a service generated one(generated by
the axis engine itself) then it throw a FaultException which
has accessors for fault code, fault string, fault actor and
fault detail which is a simple string in this case.
2) If that fault is service generated one it throw a
FaultException which has accessors for fault code, fault string,
fault actor but fault detail empty. Since the knowledge to
deserializing
the complex fault detail is with the wsdl generated types which is
with the client, when we receive the FaultException the
fault detail is null. Client need to get the fault detail name
and then create the corresponding fault detail.
Following snippets will explain further.
In the deserializer
...
FaultException* pFaultExceptin = new FaultException(this);//Pass
this deserializer into constructor
pFaultException->setFaultCode(faultcode);
pFaultException->setFaultString(faultcode);
pFaultException->setFaultActor(faultcode);
pcDetail = getElementAsString("detail", 0);
if(pcDetail)
pFaultException->setFaultDetail(pcDetail);
throw pFaultException;
...
Now In client code
...
catch(FaultException& e)
{
String sFaultCode = e.getFaultCode();
String sFaultString = e.getFaultString();
String sFaultActor = e.getFaultActor();
String sFaultDetail = e.getFaultDetail();
if(0 == sFaultDetail.length())//The fault is a service thrown one
{
if(e.getDetailName().compare("DivByZeroType"))
{
DivByZeroType* pDivByZero = new DivByZeroType();
sFaultDetail = e.getFaultDetail(pDivByZero);
}
}
}
...
So in FaultException we have a method
...
String getFaultDetail(BaseFaultType* faultType)
{
return pDZ->getFaultDetail(faultType);
}
...
So in SoapDeserializer we have
...
String getFaultDetail(BaseFaultType* faultType)
{
return faultType->deserialize();
}
...
I think this approach is simple. What do you think?
On Fri, 2004-10-01 at 18:41, John Hawkins wrote:
thanks
damitha
>
>
> >From Fred preston ->
>
>
>
>
>
> Hi Adrian.
> I've started looking at the fault object model and it is in a bit
of
> a mess. Currently, faults come back as exceptions from the stub as a
> <ServiceName>_AxisClientException. The actual exception is wrapped
inside
> the exception object. You then have to unwrap the exception to find what
> the real exception was. i.e.
>
> catch( ServiceName_AxisClientException e)
> {
> ISoapFault * pFault = (ISoapFault *) e.getFault(); // NB: You will
> probably need
> // to download
latest
> axis code
> // to get this
method.
> string faultDetail = pFault->getSimpleFaultDetail();
> string faultClassName = "<none>";
> int iExceptionCode = e.getExceptionCode();
> string sExceptionString = e.getMessage( iExceptionCode);
>
> if( faultDetail.length() == 0)
> {
> if( !pFault->getCmplxFaultObjectName().compare( "ExceptionName"))
> {
> faultClassName = pFault->getCmplxFaultObjectName();
>
> ExceptionNameType* pENT = (ExceptionNameType*)
> pFault->getCmplxFaultObject();
>
> if( pENT)
> {
> faultDetail = pENT->....;
> }
> else
> {
> faultDetail = "Unknown type:" + faultClassName;
> }
> }
> }
> }
>
> What I'm proposing is that we have the following model
>
> +---------------------+
> | AxisClientException |
> +---------------------+
> | |
> +-----------------------+ +----------------+
> | ServiceName_Exception | | FaultException |
> +-----------------------+ +----------------+
>
> Where you can catch either a Fault or Service exception directly or catch
> the generic AxisClientException and then unwrap. This removes the need
for
> catching the generic exception (and then unwrapping) if you know what
> faults to expect. A fault exception is identical to the fault reply in
the
> WSDL and a ServiceName_Exeception is only ever used for a system fault
(for
> example, if there is a connection problem). An example of a fault
> exception is shown below:-
>
> If you have the following WSDL...
>
> Service Binding Port Type Message Name
> Type
>
------------------+-----------------+---------------+-------------+----------+-------------------------------
>
> myTestServ ------> myTestBind myTestPT
> mTest mTest
> i: -------------> i: ---------> myTestIn mIn
> xsd:string
> o: -------------> o: ---------> myTestOut mOut
> xsd:int
> f: -------------> f: ---------> myTestFault mFault
> {Info xsd:string, Code xsd:int}
>
> Then the client will be coded as follows:-
>
> try
> {
> myTestServ * myService = new myTestServ( "someUri");
>
> string text = "Hello";
>
> int iRetValue = myService->mTest( text);
>
> cout << text << " has " << iRetValue << " e's" << endl;
> }
> catch( myTestFaultType f)
> {
> cout << "Error info " << f.Info << endl;
> cout << "Error code " << f.Code << endl;
> }
>
> Thus the client now catches the exception type as described in the WSDL.
>
> If the client application uses more than one service or method within a
> service then the calls may have to be separated by individual try catch
> blocks (depending on the uniqueness of the expected exceptions) to ensure
> that the code knows where or when an exception occurred.
>
> Does anyone have any comments on this proposed update?
>
> Regards,
>
> Fred Preston.
>
>
> <adrian.p.smith@b
> t.com>
>
To
> 30/09/2004 13:48 <ax...@ws.apache.org>
>
cc
>
> Please respond to
Subject
> "Apache AXIS C RE: failure notice
> User List"
>
>
>
>
>
>
>
>
>
> Better SOAP:Fault handling - i.e. be able to access the fields within the
> SOAP:Fault from a client.
>
>
>
> -----Original Message-----
> From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
> Sent: 30 September 2004 13:34
> To: axis-c-user@ws.apache.org
> Subject: Re: failure notice
>
>
>
>
>
>
> Hi Folks,
>
> Big note coming up !
>
> I would like to propose some features that we should put into 1.4. I
would
> like to know what everyone is thinking is useful to have in the 1.4
release
> and this small list should act as a starter.
>
>
>
> C support -
> firstly define feasibility of making a 100% C++ engine and design,
> then (if feasible) implement.
> We will temporarily remove C support in 1.4 to be replaced in 1.5
> with new wrapper.
>
> Apache Builds -
> This item is all about getting a daily build. We must also create
all
> the relevant web pages so it's usable.
> We will build the client first then the server.
>
> Refactor WSDL2WS -
> As it says ! This is a pretty much open-ended item so we do as much
> as we can. Remember - at this point we have no C support so anything we
can
> do here to make that easier to reimplement C in 1.5 is good !
>
> Test documentation -
> document the handler mechanism and other test related stuff we
have.
>
>
> AND - A Quick overview of 1.5 work
> 1.5
> C support -
> put back into WSDL2 WS C wrappers for the new 100% C++ engine
>
> Purify and fix -
> As it says - run Rational purify and tackle issues that come out of
> it.
>
> Improve HTTP Support.
> Fix outstanding issues with HTTP support in the new transport
layer.
> There is a lot we can do here and we haven't really defined what it
highest
> priority.
>
> Documentation
> User documentation and CVS based documentation. including sample
can
> be improved
>
>
>
> With the resource that we have here - we can contain all the above 1.4
> items within a 24th November Time-schedule. I would like to propose that
we
> try to maintain this shorter time-line for releases. That way we keep new
> function to a minimum and therefore maintain stability within builds.
>
> I would also like to propose that we move away from our current waterfall
> model of code then test. When we have daily builds we can see immediately
> what has broken and this will help us tremedously. The more we automate
our
> testing the better. The one issue with this is that the daily builds will
> only cover certain compilation options (as discussed in previous mails).
> The test-cycle now appears to consist of running the same tests on
> different configurations - is this true? In which case I would ask that
> someone find the time to automate those configurations and run them daily
> as well?
>
> Please can you feedback your thoughts and ideas on what we should put
into
> 1.4 and what you would like to see in 1.4 We can then make a judgement as
> to what the final goal is to be.
>
>
> many thanks,
> John.
>
>
>
Re: Fw: Re:failure notice
Posted by damitha kumarage <da...@opensource.lk>.
Hi,
Since now we are going to make axis engine more of c++ I suggest
following fault handling.
Derive all complex faults defined in wsdl from a base type. Say
AxisFault.
This base type has methods to serialize, deserialize.
When engine identify that the message in the wire is soap fault
1) If that fault is not a service generated one(generated by
the axis engine itself) then it throw a FaultException which
has accessors for fault code, fault string, fault actor and
fault detail which is a simple string in this case.
2) If that fault is service generated one it throw a
FaultException which has accessors for fault code, fault string,
fault actor but fault detail empty. Since the knowledge to
deserializing
the complex fault detail is with the wsdl generated types which is
with the client, when we receive the FaultException the
fault detail is null. Client need to get the fault detail name
and then create the corresponding fault detail.
Following snippets will explain further.
In the deserializer
...
FaultException* pFaultExceptin = new FaultException(this);//Pass
this deserializer into constructor
pFaultException->setFaultCode(faultcode);
pFaultException->setFaultString(faultcode);
pFaultException->setFaultActor(faultcode);
pcDetail = getElementAsString("detail", 0);
if(pcDetail)
pFaultException->setFaultDetail(pcDetail);
throw pFaultException;
...
Now In client code
...
catch(FaultException& e)
{
String sFaultCode = e.getFaultCode();
String sFaultString = e.getFaultString();
String sFaultActor = e.getFaultActor();
String sFaultDetail = e.getFaultDetail();
if(0 == sFaultDetail.length())//The fault is a service thrown one
{
if(e.getDetailName().compare("DivByZeroType"))
{
DivByZeroType* pDivByZero = new DivByZeroType();
sFaultDetail = e.getFaultDetail(pDivByZero);
}
}
}
...
So in FaultException we have a method
...
String getFaultDetail(BaseFaultType* faultType)
{
return pDZ->getFaultDetail(faultType);
}
...
So in SoapDeserializer we have
...
String getFaultDetail(BaseFaultType* faultType)
{
return faultType->deserialize();
}
...
I think this approach is simple. What do you think?
On Fri, 2004-10-01 at 18:41, John Hawkins wrote:
thanks
damitha
>
>
> >From Fred preston ->
>
>
>
>
>
> Hi Adrian.
> I've started looking at the fault object model and it is in a bit of
> a mess. Currently, faults come back as exceptions from the stub as a
> <ServiceName>_AxisClientException. The actual exception is wrapped inside
> the exception object. You then have to unwrap the exception to find what
> the real exception was. i.e.
>
> catch( ServiceName_AxisClientException e)
> {
> ISoapFault * pFault = (ISoapFault *) e.getFault(); // NB: You will
> probably need
> // to download latest
> axis code
> // to get this method.
> string faultDetail = pFault->getSimpleFaultDetail();
> string faultClassName = "<none>";
> int iExceptionCode = e.getExceptionCode();
> string sExceptionString = e.getMessage( iExceptionCode);
>
> if( faultDetail.length() == 0)
> {
> if( !pFault->getCmplxFaultObjectName().compare( "ExceptionName"))
> {
> faultClassName = pFault->getCmplxFaultObjectName();
>
> ExceptionNameType* pENT = (ExceptionNameType*)
> pFault->getCmplxFaultObject();
>
> if( pENT)
> {
> faultDetail = pENT->....;
> }
> else
> {
> faultDetail = "Unknown type:" + faultClassName;
> }
> }
> }
> }
>
> What I'm proposing is that we have the following model
>
> +---------------------+
> | AxisClientException |
> +---------------------+
> | |
> +-----------------------+ +----------------+
> | ServiceName_Exception | | FaultException |
> +-----------------------+ +----------------+
>
> Where you can catch either a Fault or Service exception directly or catch
> the generic AxisClientException and then unwrap. This removes the need for
> catching the generic exception (and then unwrapping) if you know what
> faults to expect. A fault exception is identical to the fault reply in the
> WSDL and a ServiceName_Exeception is only ever used for a system fault (for
> example, if there is a connection problem). An example of a fault
> exception is shown below:-
>
> If you have the following WSDL...
>
> Service Binding Port Type Message Name
> Type
> ------------------+-----------------+---------------+-------------+----------+-------------------------------
>
> myTestServ ------> myTestBind myTestPT
> mTest mTest
> i: -------------> i: ---------> myTestIn mIn
> xsd:string
> o: -------------> o: ---------> myTestOut mOut
> xsd:int
> f: -------------> f: ---------> myTestFault mFault
> {Info xsd:string, Code xsd:int}
>
> Then the client will be coded as follows:-
>
> try
> {
> myTestServ * myService = new myTestServ( "someUri");
>
> string text = "Hello";
>
> int iRetValue = myService->mTest( text);
>
> cout << text << " has " << iRetValue << " e's" << endl;
> }
> catch( myTestFaultType f)
> {
> cout << "Error info " << f.Info << endl;
> cout << "Error code " << f.Code << endl;
> }
>
> Thus the client now catches the exception type as described in the WSDL.
>
> If the client application uses more than one service or method within a
> service then the calls may have to be separated by individual try catch
> blocks (depending on the uniqueness of the expected exceptions) to ensure
> that the code knows where or when an exception occurred.
>
> Does anyone have any comments on this proposed update?
>
> Regards,
>
> Fred Preston.
>
>
> <adrian.p.smith@b
> t.com>
> To
> 30/09/2004 13:48 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C RE: failure notice
> User List"
>
>
>
>
>
>
>
>
>
> Better SOAP:Fault handling - i.e. be able to access the fields within the
> SOAP:Fault from a client.
>
>
>
> -----Original Message-----
> From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
> Sent: 30 September 2004 13:34
> To: axis-c-user@ws.apache.org
> Subject: Re: failure notice
>
>
>
>
>
>
> Hi Folks,
>
> Big note coming up !
>
> I would like to propose some features that we should put into 1.4. I would
> like to know what everyone is thinking is useful to have in the 1.4 release
> and this small list should act as a starter.
>
>
>
> C support -
> firstly define feasibility of making a 100% C++ engine and design,
> then (if feasible) implement.
> We will temporarily remove C support in 1.4 to be replaced in 1.5
> with new wrapper.
>
> Apache Builds -
> This item is all about getting a daily build. We must also create all
> the relevant web pages so it's usable.
> We will build the client first then the server.
>
> Refactor WSDL2WS -
> As it says ! This is a pretty much open-ended item so we do as much
> as we can. Remember - at this point we have no C support so anything we can
> do here to make that easier to reimplement C in 1.5 is good !
>
> Test documentation -
> document the handler mechanism and other test related stuff we have.
>
>
> AND - A Quick overview of 1.5 work
> 1.5
> C support -
> put back into WSDL2 WS C wrappers for the new 100% C++ engine
>
> Purify and fix -
> As it says - run Rational purify and tackle issues that come out of
> it.
>
> Improve HTTP Support.
> Fix outstanding issues with HTTP support in the new transport layer.
> There is a lot we can do here and we haven't really defined what it highest
> priority.
>
> Documentation
> User documentation and CVS based documentation. including sample can
> be improved
>
>
>
> With the resource that we have here - we can contain all the above 1.4
> items within a 24th November Time-schedule. I would like to propose that we
> try to maintain this shorter time-line for releases. That way we keep new
> function to a minimum and therefore maintain stability within builds.
>
> I would also like to propose that we move away from our current waterfall
> model of code then test. When we have daily builds we can see immediately
> what has broken and this will help us tremedously. The more we automate our
> testing the better. The one issue with this is that the daily builds will
> only cover certain compilation options (as discussed in previous mails).
> The test-cycle now appears to consist of running the same tests on
> different configurations - is this true? In which case I would ask that
> someone find the time to automate those configurations and run them daily
> as well?
>
> Please can you feedback your thoughts and ideas on what we should put into
> 1.4 and what you would like to see in 1.4 We can then make a judgement as
> to what the final goal is to be.
>
>
> many thanks,
> John.
>
>
>