cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: JaxwsInterceptorRemoverInterceptor and RM
Date Mon, 08 Jan 2007 16:15:12 GMT
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.

- 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
> >>
> >
> >
> >
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message