[
https://issues.apache.org/jira/browse/SANDESHA2-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Illsley resolved SANDESHA2-130.
-------------------------------------
Resolution: Won't Fix
I'm not sure this is really a bug. If the RM implementation has accepted the
message then there is a failure, then the expected behaviour is that the send
is re-tried. There isn't a way for sandesha2 to identify whether an exception
is transient or permanent, and whether it is an infrastructure bug or transport
failure, or something else. I think that the current behaviour is perhaps the
best we can expect, except perhaps for additional tracing in Sandesha2 and
Rampart...
> Exceptions in Axis stack not reported to client
> -----------------------------------------------
>
> Key: SANDESHA2-130
> URL: https://issues.apache.org/jira/browse/SANDESHA2-130
> Project: Sandesha2
> Issue Type: Bug
> Affects Versions: 1.3
> Environment: Axis2/Rampart/Sandesha2 v 1.3
> Reporter: Hans G Knudsen
> Priority: Blocker
>
> Hi!
> If errors occurs in the Axis stack after Sandesha has taken over handling -
> the exception is not handed back to the calling client.
> Eg. if an error occur in Rampart trying to do the outgoing security handling.
> Testcase:
> - misspell
> <ramp:passwordCallbackClass>wrong.class.Name</ramp:passwordCallbackClass>
> Sandesha does not recognize the error situation - and continues according to
> sending policy. And the session times out with the following error :
> Sandesha2 could not send the message on sequence <URL> as the sequence has
> timed out.
> I have only had time to test on version 1.3.
> /hans
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
