Hi Thomas, I am aware of the existence of the JaxWS sample programs and how they behave. I emailed you in order to elicit i) your interpretation of the JaxWS 2.0 spec and ii) an explanation of why your latest JaxWS implementation is behaving the way it does with *my* test program. Your unit tests do indeed exercise the code which handles client and server-side exceptions. However, they do not correspond to the case I am faced with and do not resolve the question I am asking. Perhaps you would allow me to explain once again what is at stake. I am currently trying to make the JBossTS XTS implementation operate over your JBossWS native soap stack rather than employ Kevin Connor's home-grown soap stack. I am hoping to be able to use JaxWS for this purpose, generating the server and client code from the WSDL. I face an interesting challenge because, for example, the WSCOOR 1.0 WSDL employs several pairs of related *one-way* methods with no fault handling defined i.e. the pairs of WSDL operations specify an <input/> message but no <output/> and no <fault/> message. In order to interoperate with other implementations I must conform to the WSDL defined by the WSCOOR protocol. I am not at liberty to add my own fault messages to the WSDL. Nor am I at liberty to add extra operations in order to notify faults. When I generate the interface and server stub code the corresponding web methods are tagged with an @OneWay annotation. My question regarding the spec is very simple: what is meant to happen if the implementation of such a one way method throws a SoapFaultException, a ProtocolException or some other Exception? Is the JaxWS implementation supposed to throw a corresponding exception in the client context? The sections of the spec I cited in my original post do not make the answer clear. I note that your tests are not tagged with the @OneWay annotation so they do not exercise this particular case (your code handles these cases differently as I explain below). I also note that when I ran a test to identify your current implementation it did not generate a client side exception for this case. However, having looked at the code I did not think that indicated a clear decision not to throw an error. On the server side i) the connection is maintained while the service method is executing ii) any exception thrown by the implementing method is caught and wrapped up into a soap fault and iii) the fault is serialized into the return stream for the connection. The current client side implementation does read this returned data although, due to a rather weird implementation of the read method in the remoting layer, the data gets truncated. I assumed this was an error and patched it so that the full message was read but it makes no difference to the outcome. When setting up the one way call your code always installs an http unmarshaller on the stream rather than a soap message unmarshaller. Clearly, whether this is correct or not depends upon the interpretation of the spec. So, I would be grateful if you could let me know what you think the spec intends should happen in this case. If an exception is supposed to be propagated back to the client, I will be glad to file JIRAs detailing the failure to do so. regards, Andrew Dinn ----------- Thomas Diesler wrote: > Hi Andrew, > > you can start with the working exception samples that we ship with the > distribution. Additionally, our test suite contains test cases that deal > with exceptions. > > You can send questions regarding WS support to: support-ws(a)jboss.com > > cheers > -thomas > > On Fri, 2007-09-21 at 10:51 +0100, Andrew Dinn wrote: >> Hi Jonathan, >> >> I'm copying this to Thomas for his advice regarding how JaxWS should >> handle exceptions thrown by service endpoint implementation code. If he >> thinks the problems I am encountering with the current implementation >> are bugs I will be happy to raise JIRAs for them. >> >> Thomas, in case you are puzzled as to the context for this request for >> advice it relates to my current attempts to implement the XTS wscoord >> services and related wsat and wsba transaction management services over >> JaxWS. My previous correspondence with Jonathan is included at the >> bottom of this note for reference. >> >> I went through the JaxWS 2.0 spec in detail yesterday and I think the >> implementation is supposed to notify server-side faults to the client >> (specifically, SOAPFaultExceptions thrown by the service end point >> implementation) *even with one way messages*. The statements on >> exception handling are not explicit but they appear to include by >> default the case where there are no output messages and no specific >> fault messages defined for the operation in the WSDL. It also appears to >> be irrespective of whether a faultto endpoint address is supplied in the >> ws addressing props for the call. >> >> The specific points in the spec I am interpreting this way are section >> 4.4.4 (Remote Exceptions) and 6.4.1/6.4.2. It is not clear that this >> interpretation applies for one-way messages (the example in 6.4.1 is a >> message with response; 6.4.2 is rather cryptic). Section 5.1.1.1 appears >> to require that *all* protocol exceptions generated by Providers are >> transported back to the client and throw; it does not distinguish >> whether the MEP is one-way or request-response. Strangely, the following >> section detailing service endpoint implementations is silent on the >> question of exceptions. Perhaps Thomas could clarify this? >> >> I spent quite a few hours yesterday pinning down what the current >> (2.0.1) JaxWS implementation is doing in my test cases and it appears >> that there are several things stopping an exception being returned from >> a one way invocation. The problem is not as I feared that the connection >> is dropped before message processing completes. It is maintained beyond >> the point where the invocation completes/throws an error and a response >> is actually supplied after the return/throw. However, subsequent >> processing does not result in a client exception. Thomas might >> appreciate the following details. >> >> Firstly, the soap fault is encoded into the response stream without a >> content-length. The process of saving and marshalling the fault into the >> response stream is *very* convoluted -- employing three different >> message contexts and generating a series of (unnecessary?) soap >> messages, including multiple versions of the soap fault. However, >> eventually the appropriate fault content (a soap envelope) does get >> fully serialized. >> >> Secondly, the remoting code (in HTTPUnMarshaller.read) fails to read the >> full reply from the stream. When a content-length property is not >> provided it takes one bite of the apple then decides there can be no >> more data even though there are more available bytes on the input >> stream. For some reason the read operation only returns the first 28 >> bytes of just over 200 that are available. I patched this method so that >> in the absence of a content-length it reads until available() indicates >> no more data is present. With this fixed it does obtain a complete SOAP >> envelope -- as a string, not as a soap fault instance. >> >> Thirdly, the response data is not processed as a fault -- this contrasts >> with the request-response case where the reply *is* processed and a >> fault is generated. This appears to relate to the fact that the >> receiving message context has property NoThrowOnFault set. This property >> is added to the context at request dispatch for both one-way and >> request-response MEPs and I don't know why it gets ignored in the one >> way case but not in the other case. Maybe because the attempt to >> deserialise an object from the message data goes ahead anyway when there >> is a response to return? >> >> >> regards, >> >> >> Andrew Dinn >> ----------- >> >> Jonathan Halliday wrote: >>> This seems like a generic problem with JAX-WS: if you choke whilst >>> processing a one-way message, how do you send a fault back, since the >>> source is expecting only a response message. >>> >>> I guess you could dispatch the fault totally dynamically and just assume >>> the other end will know how to handle it, even though the generated code >>> implies otherwise. >>> >>> Or there is a faultto header I think, with the addressing rules causing >>> faultto to take priority over the replyto header if it's present. I >>> don't know how JaxWS handles that though. >>> >>> I'd probably write this up as a generic problem and put it on the >>> JBossWS forum, maybe someone with a good knowledge of JAX-WS has a >>> general solution to the issue. >>> >>> Failing that, just have the server fail silent, since it can't send a >>> fault notification. The existing retry-timeout approach should >>> eventually cause the client to report the abscence of a response as an >>> exception to its caller. This is not terribly friendly in terms of >>> interop with other implementations, but they should have handling in >>> place for stray messages too so I don't think it's that big a problem. >>> >>> Jonathan. >>> >>> Andrew Dinn wrote: >>>> Hi Jonathan, >>>> >>>> I am progressing on implementing the XTS 1.1 wscoor and wsat/ba >>>> services using JaXWs but I'm currently puzzling over notification of >>>> faults. There does not appear to be a problem with request-response >>>> style MEPs, rather with using one way invocations. The problem is >>>> really associated with 1.0 wscoor not 1.1 since the former is >>>> explicitly based on MEPS which employ related pairs of one way >>>> messages while the latter uses request-response. However, I am >>>> concerned that there may be issues to do with the 1.1 wsat and wsba >>>> since they also use one way invocations. I thought if I explained the >>>> problem you might be able to provide some guidance. >>>> >>>> An example of something which might cause problems would be the >>>> wscoor1.0 ActivationCoordinatorPortType and >>>> ActivationRequesterPortType exchange used to create and return the >>>> coordination context. Implementing this using JaxWS clients/services >>>> generated from the wsdl would require two services, an >>>> ActivationCoordinator service and an ActivationRequester service each >>>> of which provides an endpoint with a single invocable web method, >>>> CreateCoordinationContextOperation (CreateCCO) and >>>> CreateCoordinationContextResponseOperation (CreateCCRO), respectively. >>>> >>>> So, first off here is what *would* work in this scenario. Under >>>> UserTransaction.begin() the (local) client of ActivationCoordinator >>>> obtains a JaxWS proxy and invokes CreateCCO. Before invoking the >>>> service it sets the ws addressing messageid and replyto for the call >>>> to a unqiue id and the endpoint address of the local >>>> RegistrationCoordinator, respectively. >>>> >>>> When the ActivationCoordinator service receives the request it handles >>>> it by obtaining a JaxWS proxy for the RegistrationCoordinator service >>>> and invoking CreateCCRO. The service implementation method can detect >>>> the supplied addressing properties and use them to direct the >>>> CreateCCRO operation to the correct registration coordinator endpoint >>>> and to supply a relatesto header identifying the source messageid. >>>> >>>> This means that the client of ActivationCoordinator can sit in a wait >>>> queue (keyed by message id) pending wake up when the response is >>>> received by the RegistrationCoordinator service. All of this is >>>> feasible using generated service and client stubs and the generic ws >>>> addressing support in JaxWS. Note that JaxWS does not provide a way of >>>> associating these two calls other than enabling the messageid and >>>> relatesto to be set and retrieved. So, the wait and wake up has to be >>>> implemented outside of JaxWS. >>>> >>>> The problem is what to do if a fault happens during delivery or >>>> processing of the request. Note that this only arises when we are >>>> using one way messages. When processing messages which require a >>>> response JaxWS automatically detects and translates delivery errors or >>>> exceptions thrown by the service endpoint implementation into soap >>>> faults thrown in the original client context. >>>> >>>> With a one-way request if an error happens i) on the client side >>>> during initial processing of the message or ii) on the server side >>>> while while the incoming http connection is still open then a fault is >>>> also automatically thrown in the client. However, by the time SOAP >>>> handlers and/or the server endpoint call is reached the connection >>>> will have been closed and there is no way to propagate a fault >>>> directly back to the client. >>>> >>>> Unfortunately, using JaxWS there is no way to send a fault to the >>>> endpoint identified by the replyto header either. The >>>> RegistrationCoordinator service only implements a single operation, >>>> CreateCCRO, which delivers a coordination context response. This >>>> cannot be used to dispatch a soap fault. We could add an extra >>>> operation to the WSDL with a corresponding service implementation >>>> method but that would not be standard and so, would not inter-operate >>>> with other wscoor implementations >>>> >>>> By way of comparison, when Kev's code detects an error on the server >>>> side (for either a one-way or two-way message) it sends a fault back >>>> to the soap stack of the caller or, if address processing has >>>> progressed far enough, to the replyto soap stack. It can do this >>>> because it is managing the soap stack itself rather than calling via a >>>> proxy. It also gets away with this because the soap stack at the other >>>> end recognises the relatesto tag attached to the fault message and >>>> automatically wakes up the client and delivers the fault -- client >>>> suspension and wake-up for this type of MEP is implemented within >>>> Kev's soap stack. >>>> >>>> I am not yet sure what the implications of this are for the wsat and >>>> wsba exchanges. Some of the operations in the WSDLs are specified as >>>> one way messages although these mostly seem to operate as related >>>> pairs. Do you have any idea what the implications for fault handling >>>> are in these cases? >>>> >>>> regards >>>> >>>> >>>> Andrew Dinn >>>> -----------