forgot to cc on dev@cxf. doing it now so that i can link the whole thread in a jira ticket.
2012/2/6 Aki Yoshida <elak...@googlemail.com>: > 2012/2/6 Daniel Kulp <dk...@apache.org>: >> On Monday, February 06, 2012 5:50:05 PM Aki Yoshida wrote: >>> 2012/2/6 Daniel Kulp <dk...@apache.org>: >>> > On Monday, February 06, 2012 11:39:24 AM Aki Yoshida wrote: >>> >> Hi, >>> >> I would like to have an option to be able to invoke oneway calls >>> >> synchronously so that the caller will get an HTTP 202 when no error >>> >> occurs at the provider side but it will get an HTTP 500 SOAP fault >>> >> when some error occurs. There seems to be no option available to >>> >> enforce this behavior. >>> > >>> > Yea, as it's against spec and likely wouldn't be interopable with other >>> > stacks..... One thing that may need to be checked is how the various >>> > stacks would deal with a soap:fault on a one-way. If a stack isn't >>> > expecting it, not sure what they'd do. >>> >>> I think there is a grey area in the interpretation of the spec. >>> Logically, in the application's message exchange level, we can all >>> agree that there is no fault returned to the caller. But there are all >>> kinds of error situations during the oneway call. Some errors are >>> already generating an HTTP 500 response >> >> In theory, this would only occur for faults that occur prior to being able to >> determine which operation is being invoked. Basically, prior to knowing if >> the incoming message is a one-way or not. Once we know it's a one-way, then >> the normal one-way rule apply. > > Right. > >> >> What's interesting is that this is an area that has even changed in the >> WSI-BP >> specs. In 1.1 and earlier: >> http://www.ws-i.org/Profiles/BasicProfile-1.1.html#One-Way_Operations >> >> you can see that for one-way, you CANNOT send a fault response back. >> >> But that has changed for 1.2: >> >> http://ws-i.org/profiles/BasicProfile-1.2-2010-11-09.html#One-Way_Operations >> >> So your changes would violate BP 1.0/1.1, but not 1.2. So I'm OK with it. >> :-) >> > > Yeah. It looks like the spec has been corrected so that is is more > aligned with reality. > If we interpret the BP1.0/1.1 paragraph strictly, we might say that we > are already violating BP 1.0/1.1 for some error cases mentioned > earlier. However, we could use slightly a loose interpretation of that > paragraph so that oneway operations cannot return a soap fault to > actually convey the fault information back to the caller. But a oneway > call is allowed to return an HTTP 500 to indicate the failure of the > transmission of the message. And this "transmission" thing could be > loosely interpreted :-). > >>> > Actually, what I'd even suggest is to add an @RobustInOnly annotation that >>> > would set the property on the BindingOperationInfo. >>> >>> That would be possible. But that means you want to statically >>> differentiate the service method to be either non-robust and robust, >>> as if we are going the wsdl2 route? >>> >>> I thought it would be beneficial to be able to set this option at the >>> published endpoint by using some message contextual property. >> >> One doesn't preclude the other.... >> >> If the OneWayInInterceptor just looks for >> message.getContextualProperty("....") and basis it's work on that property, >> it >> can be set in a number of places including the Endpoint, the bus, the >> operation, etc... >> >> The annotation can just be used to set the property on that specific >> operation. (and if you allow TYPE for @Target, you could set it on the >> EndpointImpl or interface to apply to all oneways) Basically, just an easy >> "java first" way to set the property. >> > > That sounds good. > > Thanks. > > Regards, aki >> >> >>> Regards, aki >>> >>> > -- >>> > Daniel Kulp >>> > dk...@apache.org - http://dankulp.com/blog >>> > Talend Community Coder - http://coders.talend.com >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com
