DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20930.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20961.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Alan George wrote:
Forgoing the ideal situation, it seams broken to me to just drop these
exceptions on the floor.
I have made a local change to throw these exceptions. Does anyone know
of any issues with this change I should be aware of?
I would guess because till now nobody has cared about
Steve Loughran wrote:
I would guess because till now nobody has cared about an IOE on the
writeback,
because it just meant the caller had broken the link. And there was not
a lot to do with the IOE but log it. It was not like you could send a
SoapFault
back to the caller, for example.
What
Attached is a PDF which outlines the next rev of the spec for
implementing the JMS URL syntax for the JMS transport layer in Axis.
This is an evolution of the spec that we proposed a few months back.
This is a significant next step towards being able to swap between HTTP
and JMS as the underlying
David,
FYI, 1.1 branch has been cut. So you are free to check in code.
-- dims
--- [EMAIL PROTECTED] wrote:
Attached is a PDF which outlines the next rev of the spec for
implementing the JMS URL syntax for the JMS transport layer in Axis.
This is an evolution of the spec that we proposed a
Alan George wrote:
Steve Loughran wrote:
I would guess because till now nobody has cared about an IOE on the
writeback,
because it just meant the caller had broken the link. And there was not
a lot to do with the IOE but log it. It was not like you could send a
SoapFault
back to the caller,
