Fwd: [Axis2] AxisFault

[Eran Chinthaka <ch...@gmail.com>]

Hi Steve,

Any plans of completing this ? Its been a long time you made these
changes, but still they are in a transition stage.

Initialy I implemented AxisFault and included some stuff based on
OMElements. But you have changed them and included a parallel
hierarchy. Assuming its fine (but I can remember I and some others
didn't agree for that), your changes are yet to be completed.
So the fault handling in AxisEngine is not happening well due to those changes.

I had this problem in implementing some interop scenarios, but I made
a workaround to make it working, without using details found in
AxisFault.

Is possible, please be kind enough to take AxisFault couple to fault
handling in Axis2.

-- Chinthaka

On 11/18/05, Steve Loughran <st...@apache.org> wrote:
> Sanjiva Weerawarana wrote:
> > On Thu, 2005-11-17 at 21:58 +0000, dims@apache.org wrote:
> >
> >>Author: dims
> >>Date: Thu Nov 17 13:58:06 2005
> >>New Revision: 345338
> >>
> >>URL: http://svn.apache.org/viewcvs?rev=345338&view=rev
> >>Log:
> >>This is the last chance we are gonna get to muck around with package names...so am taking it :)
> >
> >
> > This breaks Sandesha, Kandula and Synapse .. pls send a note to those
> > -dev lists to warn them! (We better remember to put this stuff in
> > release notes .. I can see another message from SteveL otherwise :))
>
> No, now its your turn to complain about what I've just checked in for
> AxisFault
>
>
> 1. a new package fault that contains
>
> 1. the various classes to model SOAPFault bits and bobs in a
> SOAP-envelope-neutral format
> 2. an interface to replace the one dims deleted, in which an exception
> can be asked to provide a soap fault, and if so, it is given complete
> control over marshalling,
>
> I'm not so sure about (2). it works well in  my alpine prototype,
> because I dont care about soap1.1. compatibiity,
>
> I've also checked in a version of AxisFault that uses the new stuff.
>
> This is a first step towards soap fault handing. What is now needed is
>
> -extraction of stack traces and storage in the axisfault details
> -extraction of http error codes and storage in the axisfault details
> -lossless mapping two and from soapfaults.
>
> Again, the need to support multiple OMFactories complicates things; I
> cant' just store details as elements in a list, they've got to be under
> some node that is bound to a particular factory. Some assistance or
> advice would help here.
>
> -steve
>



From: Steve Loughran <st...@apache.org>
Date: Nov 18, 2005 10:09 PM
Subject: AxisFault
To: Axis-Dev <ax...@ws.apache.org>


Sanjiva Weerawarana wrote:
> On Thu, 2005-11-17 at 21:58 +0000, dims@apache.org wrote:
>
>>Author: dims
>>Date: Thu Nov 17 13:58:06 2005
>>New Revision: 345338
>>
>>URL: http://svn.apache.org/viewcvs?rev=345338&view=rev
>>Log:
>>This is the last chance we are gonna get to muck around with package
names...so am taking it :)
>
>
> This breaks Sandesha, Kandula and Synapse .. pls send a note to those
> -dev lists to warn them! (We better remember to put this stuff in
> release notes .. I can see another message from SteveL otherwise :))

No, now its your turn to complain about what I've just checked in for
AxisFault


1. a new package fault that contains

1. the various classes to model SOAPFault bits and bobs in a
SOAP-envelope-neutral format
2. an interface to replace the one dims deleted, in which an exception
can be asked to provide a soap fault, and if so, it is given complete
control over marshalling,

I'm not so sure about (2). it works well in  my alpine prototype,
because I dont care about soap1.1. compatibiity,

I've also checked in a version of AxisFault that uses the new stuff.

This is a first step towards soap fault handing. What is now needed is

-extraction of stack traces and storage in the axisfault details
-extraction of http error codes and storage in the axisfault details
-lossless mapping two and from soapfaults.

Again, the need to support multiple OMFactories complicates things; I
cant' just store details as elements in a list, they've got to be under
some node that is bound to a particular factory. Some assistance or
advice would help here.

-steve

Re: Fwd: [Axis2] AxisFault

[Steve Loughran <st...@apache.org>]

Eran Chinthaka wrote:
> Hi Steve,
> 
> Any plans of completing this ? Its been a long time you made these
> changes, but still they are in a transition stage.
> 
> Initialy I implemented AxisFault and included some stuff based on
> OMElements. But you have changed them and included a parallel
> hierarchy. Assuming its fine (but I can remember I and some others
> didn't agree for that), your changes are yet to be completed.
> So the fault handling in AxisEngine is not happening well due to those changes.
> 
> I had this problem in implementing some interop scenarios, but I made
> a workaround to make it working, without using details found in
> AxisFault.
> 
> Is possible, please be kind enough to take AxisFault couple to fault
> handling in Axis2.
> 

I havent been doing axis work for three months, and for the last couple 
of week's I've been trying to get my build back to where it was, i.e. 
running.

My goal for all this was to not just send axisfaults over the wire, but 
properly marshall things like WS-BaseFault faults, for which I need full 
access to the SOAPFault, and the ability to nest lots of stuff inside, 
at the app level, without having to care whether its a SOAP1.1 or 1.2 
connection. Maybe that latter thin is an unrealistic goal, because the 
faults are so different.


> -- Chinthaka
> 
> On 11/18/05, Steve Loughran <st...@apache.org> wrote:
>> Sanjiva Weerawarana wrote:
>>> On Thu, 2005-11-17 at 21:58 +0000, dims@apache.org wrote:
>>>
>>>> Author: dims
>>>> Date: Thu Nov 17 13:58:06 2005
>>>> New Revision: 345338
>>>>
>>>> URL: http://svn.apache.org/viewcvs?rev=345338&view=rev
>>>> Log:
>>>> This is the last chance we are gonna get to muck around with package names...so am taking it :)
>>>
>>> This breaks Sandesha, Kandula and Synapse .. pls send a note to those
>>> -dev lists to warn them! (We better remember to put this stuff in
>>> release notes .. I can see another message from SteveL otherwise :))
>> No, now its your turn to complain about what I've just checked in for
>> AxisFault
>>
>>
>> 1. a new package fault that contains
>>
>> 1. the various classes to model SOAPFault bits and bobs in a
>> SOAP-envelope-neutral format
>> 2. an interface to replace the one dims deleted, in which an exception
>> can be asked to provide a soap fault, and if so, it is given complete
>> control over marshalling,
>>
>> I'm not so sure about (2). it works well in  my alpine prototype,
>> because I dont care about soap1.1. compatibiity,
>>
>> I've also checked in a version of AxisFault that uses the new stuff.
>>
>> This is a first step towards soap fault handing. What is now needed is
>>
>> -extraction of stack traces and storage in the axisfault details
>> -extraction of http error codes and storage in the axisfault details
>> -lossless mapping two and from soapfaults.
>>
>> Again, the need to support multiple OMFactories complicates things; I
>> cant' just store details as elements in a list, they've got to be under
>> some node that is bound to a particular factory. Some assistance or
>> advice would help here.
>>
>> -steve
>>
> 
> 
> 
> From: Steve Loughran <st...@apache.org>
> Date: Nov 18, 2005 10:09 PM
> Subject: AxisFault
> To: Axis-Dev <ax...@ws.apache.org>
> 
> 
> Sanjiva Weerawarana wrote:
>> On Thu, 2005-11-17 at 21:58 +0000, dims@apache.org wrote:
>>
>>> Author: dims
>>> Date: Thu Nov 17 13:58:06 2005
>>> New Revision: 345338
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=345338&view=rev
>>> Log:
>>> This is the last chance we are gonna get to muck around with package
> names...so am taking it :)
>>
>> This breaks Sandesha, Kandula and Synapse .. pls send a note to those
>> -dev lists to warn them! (We better remember to put this stuff in
>> release notes .. I can see another message from SteveL otherwise :))
> 
> No, now its your turn to complain about what I've just checked in for
> AxisFault
> 
> 
> 1. a new package fault that contains
> 
> 1. the various classes to model SOAPFault bits and bobs in a
> SOAP-envelope-neutral format
> 2. an interface to replace the one dims deleted, in which an exception
> can be asked to provide a soap fault, and if so, it is given complete
> control over marshalling,
> 
> I'm not so sure about (2). it works well in  my alpine prototype,
> because I dont care about soap1.1. compatibiity,
> 
> I've also checked in a version of AxisFault that uses the new stuff.
> 
> This is a first step towards soap fault handing. What is now needed is
> 
> -extraction of stack traces and storage in the axisfault details
> -extraction of http error codes and storage in the axisfault details
> -lossless mapping two and from soapfaults.
> 
> Again, the need to support multiple OMFactories complicates things; I
> cant' just store details as elements in a list, they've got to be under
> some node that is bound to a particular factory. Some assistance or
> advice would help here.
> 
> -steve
>