axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter McEvoy (JIRA)" <>
Subject [jira] Commented: (AXIS2-345) InOnly MEP should rethrow transport level exceptions
Date Mon, 09 Jan 2006 18:47:49 GMT
    [ ] 

Peter McEvoy commented on AXIS2-345:

OK - this is good news.   However, I am using proxies generated by the wsdl2java tool, and
it does not seem to generate client proxies that ues this sendRobust method (I think).  It
seems to be using invokeOneWay (unless of course the code you are are refering to is in a
newer build that what I use)

I really would like to use auto-generated proxies and not have to worry about writing that
code myself.  

Perhaps this should be a usability issue against the wsd2java tool?


> InOnly MEP should rethrow transport level exceptions
> ----------------------------------------------------
>          Key: AXIS2-345
>          URL:
>      Project: Apache Axis 2.0 (Axis2)
>         Type: Bug
>   Components: core
>     Reporter: Peter McEvoy

> After a series of emails on axis-users, it was recommended [1] that I log an issue here.
> The in-only MEP should rethrow transport level exceptions if there was a problem with
transmission.  In particular, the HTTP transport buries all exceptions, and it is impossible
to tell on the client side if there was a problem with the transmission (such as the remote
server not being available).
> WS-I BP 1.1 specifies the following:
> "The HTTP response to a one-way operation indicates the success or failure of the transmission
of the message. Based on the semantics of the different response status codes supported by
the HTTP protocol, the Profile specifies that "200" and "202" are the preferred status codes
that the sender should expect, signifying that the one-way message was received." [2]
> And that 
> "HTTP uses the 5xx series of status codes to indicate failure due to a server error."
> I hope this is enough information....
> [1]
> [2]
> [3]

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message