cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: JaxwsInterceptorRemoverInterceptor and RM
Date Mon, 08 Jan 2007 17:31:36 GMT
Dan Diephouse wrote:

> OK, I'm guess that we're talking about different things then? So I'm not
> sure I understand your question any more. I was saying that rather 
> depending
> on this code:
>
>   private boolean isPartialResponse(Message in) {
>        return in.getContent(List.class) == null
>               && getException(in.getExchange()) == null;
>    }
>
> we should explicitly set a property REDISPATCHED. So the code in
> ClientImpl.onMessage becomes:
>
> if (!Boolean.TRUE.equals(message.get(REDISPATCHED)) {
>   message.getExchange().put(FINISHED, Boolean.TRUE);
>   message.getExchange().setInMessage(message);
>   message.getExchange().notifyAll();
> }
>
> And that gets around the problem of having to look for List content. All
> that needs to be done is setting of the REDISPATCHED property when we 
> know
> we have a message destined for the RM service (i.e. a CreateSequence).
>
> That would work with non-anonymous replyTo's just fine. Whatever 
> component
> redirects the message is responsible for setting the redispatched 
> parameter.
> Maybe I am misunderstanding what you're talking about though?


I am talking about processing a partial response to an APPLICATION 
message - not messages destined for an RM endpoint (i.e. not 
CreateSequence, CreateSequenceResponse, TerminateSequence etc. messages).
A partial response is sent by addressing so that RM interceptors, IF 
they happen to be on the chain, can contribute/read Acknowlegement 
headers . But addressing itself does not and should not have any 
knowledge of whether RM is involved -  it always sends a partial 
response for twoways with non-anonymous ReplyTo, or oneways.
These partial responses really are essentially plain HTTP responses with 
response code ACCEPTED, except that in some cases they need to be blown 
up into real soap messages with headers but without a body. For that 
reason the partial response is run through the interceptor chain so that 
RM interceptors can contribute/interprete these headers.
It may turn out that RM interceptors actually have nothing to add to the 
message (that depends on the acknowledgement policies in place), but the 
point is that neither the transports nor the addressing interceptors can 
know this up-front.
In such a case the partial response currently is an soap envelope with 
an empty headers and body element - it was discussed before to not 
marshal the envelope in such a case either. The partial response would 
then in fact be a plain HTTP response.
I hope this is a bit clearer?

Andrea.
 

>
> - Dan
>
> On 1/8/07, Andrea Smyth <andrea.smyth@iona.com> wrote:
>
>>
>> Dan Diephouse wrote:
>>
>> > On 1/8/07, Andrea Smyth <andrea.smyth@iona.com> wrote:
>> >
>> >>
>> >> Dan Diephouse wrote:
>> >>
>> >> > I think that anything before unmarshalling should be pretty 
>> resilient
>> >> > to any
>> >> > type of message. But unmarshalling may be specific from service to
>> >> > service.
>> >> > So I'm cool with starting a new chain which starts after the
>> >> > RmSoapInterceptor.
>> >> >
>> >> > Regarding the partial response check - I thought we decided we were
>> >> > going to
>> >> > set a property which signals that the message isn't destined for 
>> the
>> >> > client.
>> >> > This way we have a general mechanism for other WS-* specs as well.
>> for
>> >> > example:
>> >> >
>> >> > // determine whether the message was redispatched to RM or 
>> somewhere
>> >> else
>> >> > boolean redispatched = Boolean.TRUE.equals(message.get
>> (REDISPATCHED));
>> >> >
>> >> > Other possible property names might be REROUTED, INTERCEPTED, or
>> >> > FORWARDED.
>> >>
>> >> Well that's not the case for now - and I am not sure where exactly 
>> this
>> >> property should be set. It may require changes to several 
>> interceptors
>> >> to make them aware of the possibly empty soap bodies and in such a 
>> case
>> >> identify the message as a partial response.
>> >
>> >
>> >
>> > Wouldn't it just be set in the RMSoapInterceptor?
>> >
>> > if (wsaAction.equals(createSequence)) message.put(REDISPATCHED,
>> > Boolean.TRUE
>> > ));
>>
>> No, this has nothing to do with RM - it would be a problem whenever we
>> use addressing with a non-anonymous ReplyTo. Granted, RM is the only
>> component tyhat actually has an interest in partial responses, but we'd
>> have to send them anyway as we'd need some form of http response.
>>
>> >
>> > In general I'd prefer if we could make it a policy for interceptors to
>> >
>> >> simply do NOTHING rather than deciding to take some default action 
>> (in
>> >> the case of the BareInInterceptor: set the content of the in 
>> message to
>> >> an empty list)  when they do encounter 'abnormal' messages.
>> >
>> >
>> >
>> > I'm not sure I understand. How are we supposed to know if there is an
>> > error
>> > then?
>> >
>> > - Dan
>> >
>>
>>
>
>


Mime
View raw message