Hi,
I thought about that but it seemd a lot more clumsy for anyone wanting
to use it... so I don't see it as a better solution ;-) If you feel
strongly about it I'm happy to go down the property route instead?
David

On 07/03/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi David,

The proposal you suggested works, but aren't we polluting AxisFault with
that. I'd like to see AxisFault as THE main exception class within Axis2
and the bridge to SOAP fault and only that.

So if there is anything to do with the headers, even with addressing,
isn't it better if we set those properties to the message context?

AxisFault is one of the main APIs that is directly visible to users, so
I think it is better to have the minimal number of methods in those
classes.

So my suggestion is, if you wanna change the wsa:Action, set that to
current message context and then transfer that to the fault message context.

this is not a rejection of the initial proposal, rather an evaluation of
repercussions for a better solution :)

Thanks,
- - Chinthaka

David Illsley wrote:
> Hi All,
> I've had a quick think about AXIS2-2291 and I think the cleanest
> solution is to add a get/setFaultAction to the AxisFault class to
> allow someone throwing an AxisFault to set the fault wsa:Action they
> wish to use. (This would then be picked up by the
> MessageContextBuilder and set in the appropriate place)
>
> I think this has a broader scope than the specific RM issue mentioned
> in AXIS2-2291 and will be more broadly useful.
>
> I think AxisFault is probably part of the Axis2 API, hence the 'proposal'.
>
> Does anyone object to this/have a better suggestion?
>
> I'll add the relevant code in a few days if there are no objections,
> David
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF7h+/jON2uBzUhh8RAtbOAKCASWM4FRoHaoanbaBl1DdsreRadwCfVGGX
sx/Uw94gbGoW5lRMp7cjxik=
=/smB
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
David Illsley - IBM Web Services Development

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to