Return-Path: 
 <axis-c-user-return-924-apmail-ws-axis-c-user-archive=ws.apache.org@ws.apache.org>
Delivered-To: apmail-ws-axis-c-user-archive@www.apache.org
Received: (qmail 48886 invoked from network); 1 Oct 2004 12:43:25 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 1 Oct 2004 12:43:25 -0000
Received: (qmail 25825 invoked by uid 500); 1 Oct 2004 12:43:20 -0000
Delivered-To: apmail-ws-axis-c-user-archive@ws.apache.org
Received: (qmail 25753 invoked by uid 500); 1 Oct 2004 12:43:19 -0000
Mailing-List: contact axis-c-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:axis-c-user-help@ws.apache.org>
list-unsubscribe: <mailto:axis-c-user-unsubscribe@ws.apache.org>
list-post: <mailto:axis-c-user@ws.apache.org>
List-Id: "Apache AXIS C User List" <axis-c-user.ws.apache.org>
Reply-To: "Apache AXIS C User List" <axis-c-user@ws.apache.org>
Delivered-To: mailing list axis-c-user@ws.apache.org
Received: (qmail 25730 invoked by uid 99); 1 Oct 2004 12:43:18 -0000
X-ASF-Spam-Status: No, hits=0.1 required=10.0
	tests=DNS_FROM_RFC_ABUSE
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from [195.212.29.134] (HELO mtagate1.uk.ibm.com) (195.212.29.134)
  by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 01 Oct 2004 05:43:18 -0700
Received: from d06nrmr1407.portsmouth.uk.ibm.com
 (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i91ChEDq227504
	for <axis-c-user@ws.apache.org>; Fri, 1 Oct 2004 12:43:14 GMT
Received: from d06ml068.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com
 [9.149.37.228])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
 i91ChDJM138542
	for <axis-c-user@ws.apache.org>; Fri, 1 Oct 2004 13:43:13 +0100
Subject: Fw: Re:failure notice
To: axis-c-user@ws.apache.org
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: 
 <OFE0AAC307.F23386F2-ON80256F20.0045B6AD-80256F20.0045BF79@uk.ibm.com>
From: John Hawkins <HAWKINSJ@uk.ibm.com>
Date: Fri, 1 Oct 2004 13:41:50 +0100
X-MIMETrack: Serialize by Router on D06ML068/06/M/IBM(Release 6.51HF338 | June
 21, 2004) at
 01/10/2004 13:46:20
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N





>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          <axis-c-user@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.