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 18:49:48 GMT
Dan Diephouse wrote:

> Hopefully I understand this time (sorry if I'm being slow). So you're
> talking about what we do when we receive a partial response on a client
> endpoint? i.e. do we run it through the service's BareInInterceptor even
> though there isn't a Body? And if so, how should that interceptor 
> handle it?

Yes, that's the situation.

>
>
> My take would be that since the operation has no parts, the bare 
> interceptor
> should indeed set an empty list content. However that breaks the
> ClientImpl.isPartialResponse code, which leads me back to setting the
> property REDISPATCHED if the message isn't actually destined toward the
> Client...

The operation is the twoway operation (with non-anonymous replyTo) or 
the oneway operation for which the partial response is sent, and it is 
destined to the (application) client. Rather, the underlying message, 
i.e. the partial response, does not include the output for that 
operation (which will be sent with the full response instead), and that 
fact IMO is better represented by not setting the message content at 
all. In  other words: no body == no (list) content.

Aside from that, it seems that SoapHeaderInterceptor relies on 
BareInInterceptor having assigned at least an empty list (NPE 
otherwise). This kind of interdependence IMO is fragile, the 
SoapHeaderInterceptor would better do a:

List<Object> parameters = CastUtils.cast(message.getContent(List.class));

        if (null == parameters) {
            parameters = new ArrayList<Object>();
        }

and it also should only assign message content if there actually is 
some, i.e.

if (parameters.size() > 0) {
    message.setContent(List.class, parameters);
}

What's wrong with that?

>
> Although, technically there is no operation. We could define a pseudo
> operation with no parts that gets called. Or we could just abort() the 
> chain
> once we process the acknowledgements if we know its the partial response.

We'd have to continue intercepting at least until all interceptors that 
have an interest in the partial response have executed, so inbound up to 
the logical rm interceptor - this is nearly towards the end anyway, and 
definitely after the marshalling interceptors.

Andrea.

>
> - Dan
>
> On 1/8/07, Andrea Smyth <andrea.smyth@iona.com> wrote:
>
>>
>> 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