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 16:24:40 GMT
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.
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.

Andrea.

>
> - Dan
>
> On 1/8/07, Andrea Smyth <andrea.smyth@iona.com> wrote:
>
>>
>> OK, I am now considering to create a new chain and switch over to that
>> as soon as possible (i.e. in RMSoapInterceptor as mentioned earlier).
>> Partly because I need have to ensure that the interceptors appropriate
>> for the parameter style used in the binding for the RM procol messages
>> are used. Initially this style was wrapped, but I am now changing this
>> to BARE (which is what you would get from using the wsdl I mailed around
>> earlier). Whichever style is chosen, there are problems when the
>> application endpoint uses the other style of binding (that is why the
>> RMInInterceptor removed the WrapperClassInInterceptor), and the two
>> solutions are to either replace the (frontend-independent)
>> Wrapped[In/Out]Interceptor on the chain with Bare[In/Out]Interceptor, or
>> to use a new chain containing interceptors chosen specifically for the
>> RM endpoint.
>>
>> Nevertheless, the core - interceptors as well as other parts - should be
>> more robust, as e.g. I just found out that decoupled responses actually
>> don't work with bare bindings
>>
>> https://issues.apache.org/jira/browse/CXF-357
>>
>> I am not sure which is the better way to work around this:
>> Should the BareInInterceptor only do a message.setContent(List.class,
>> parameters);
>> if any parameters were found, or should the isPartialResponse check in
>> ClientImpl be changed to
>> ... if (message.getContent(List.class) == null ||
>> message.getContent(List.class).size() == 0 || ...)?
>>
>> Any opinions?
>> Andrea.
>>
>>
>> Dan Diephouse wrote:
>>
>> > this is very dangerous and way too common of a problem to rely on
>> > catching
>> > exceptions that might occur during processing. Making interceptors 
>> more
>> > fault tolerant this way complicates development for advanced users,
>> > integrators, etc. Lets say I as a user write an interceptor which
>> > verifies
>> > that an authentication header is present and throws a fault if it 
>> is not
>> > present. I now need to add logic now to look for WS-* messages.
>> >
>> > Also, it is dangerous because I think it could give into situations
>> > where it
>> > isn't clear if we should throw an error or if we should be catching
>> > it. What
>> > if the incoming message is formatted wrong and that is what throws the
>> > ClassCastException? Now our fault tolerance has turned into fault
>> > swallowing.
>> >
>> > I would much prefer a more sophisticated dispatching maechanism. 
>> Here's
>> a
>> > look at our incoming interceptor flow with RM and Addressing enabled:
>> >
>> >  receive [AttachmentInInterceptor, InMessageRecorder]
>> >  pre-stream []
>> >  user-stream [StreamHandlerInterceptor]
>> >  post-stream [StaxInInterceptor]
>> >  read [ReadHeadersInterceptor]
>> >  pre-protocol [MustUnderstandInterceptor, MAPCodec,
>> > SOAPHandlerInterceptor,
>> > RMSoapInterceptor]
>> >  user-protocol []
>> >  post-protocol []
>> >  unmarshal [URIMappingInterceptor, WrappedInInterceptor,
>> > SoapHeaderInterceptor]
>> >  pre-logical [OutgoingChainSetupInterceptor, RMInInterceptor,
>> > MAPAggregator]
>> >  user-logical [LogicalHandlerInterceptor]
>> >  post-logical []
>> >  pre-invoke []
>> >  invoke [ServiceInvokerInterceptor]
>> >  post-invoke [OutgoingChainInterceptor]
>> >
>> > We can recognize that a message isn't destined to the original
>> > endpoint (and
>> > is destined to RM) after we've parsed the headers for the most part. I
>> > think
>> > it is at this point that we should be re-dispatching off to the RM
>> > service
>> > or wherever it needs to go (by redispatching I mean creating a new 
>> chain
>> > with the actual service's interceptors and starting it at the current
>> > phase).  Since interceptors at the beginning of the chain work with 
>> the
>> > message itself and shouldn't make assumptions about what Service is
>> being
>> > invoked for the most part, this is a good breaking point to re-
>> dispatch.
>> >
>> > Another option to handle these scenarios would be to implement a more
>> > advanced dispatching mechansim which dispatches to the service later
>> > in the
>> > chain and not at the front. I outlined some ways to do this in [1].
>> > One of
>> > the ways involves creating a MessageObserver for the soap binding
>> itself.
>> > The soap binding would then contain some logic on how to find the
>> correct
>> > service given the URL/soap version/etc. In theory the RM layer could
>> then
>> > override/preempt this logic at some point in the chain.
>> >
>> > I'm not sure if I prefer the redispatching or the delaying Service
>> > resolution, but I don't think I'm cool with just doing a
>> > catch(ClassCastException).
>> >
>> > - Dan
>> >
>> > 1.
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200612.mbox/%3c7b774c950612021343x513c2783o128a032ba93923bb@mail.gmail.com%3e

>>
>> >
>> >
>> > On 1/5/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>> >
>> >>
>> >>
>> >>
>> >> > -----Original Message-----
>> >> > From: Andrea Smyth [mailto:andrea.smyth@iona.com]
>> >> > Sent: 05 January 2007 15:59
>> >> > To: cxf-dev@incubator.apache.org
>> >> > Subject: Re: JaxwsInterceptorRemoverInterceptor and RM
>> >> >
>> >> > >>Can you elaborate on how exactly you see this thing working?
>> >> > >>
>> >> > >>
>> >> > >
>> >> > >Well I was thinking of something even more simple ... the
>> >> > interceptors
>> >> > >should be coded defensively to "expect the unexpected" and
>> >> > simply step
>> >> > >out of the way when that occurs ... e.g. instead of the
>> >> > >HolderOutInterceptor just doing a straight cast of the
>> >> > message parts to
>> >> > >Holder and barfing with ClassCastException on any other
>> >> > type, it would
>> >> > >first check with instanceof to ensure the cast succeeds and
>> >> > otherwise
>> >> > >bail out from handleMessage() immediately.
>> >> > >
>> >> > >
>> >> > I'd be very much in favour of this - hence my question: Is it
>> >> > OK to make the HolderInInterceptor robust by performing a
>> >> > type check before casting to Holder? Or is there a more
>> >> > efficient way, e.g. check the parameter type for INOUT first,
>> >> > and only then attempt the cast?
>> >> >
>> >> > Andrea.
>> >>
>> >> Well if you're worried about the runtime cost of doing the instanceof
>> >> check for every single message dispatch, then we could make an
>> >> assumption that in practice out-of-band RM protocol messages will
>> >> generally only constitute a small minority of the messages dispatched
>> >> (assuming RM sequences have a reasonable lifespan).
>> >>
>> >> If this assumption holds, we could dispense with the instanceof check
>> >> and instead do the Holder cast inside a try ... catch
>> >> (ClassCastException) block, bailing out of handleMessage() in the 
>> catch
>> >> block. That way we'd take the performance hit of throwing and 
>> catching
>> >> the ClassCastException only when an RM protocol message is actually
>> >> being dispatched (presumably relatively rare) and incurr no extra 
>> cost
>> >> in the normal case.
>> >>
>> >> /Eoghan
>> >>
>> >
>> >
>> >
>>
>>
>
>


Mime
View raw message