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 Sat, 23 Dec 2006 02:59:45 GMT
Hi Eoghan,

On 12/19/06, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> OK, conceptually I agree with your picture of the RM out-of-band
> protocol messages (such as the CreateSequence) being akin to invocations
> on a separate service.
>
> However, in practice I'm not sure as to what exactly we'd gain over the
> current implementation (where the RM interceptor effectively services
> these invocations directly itself).


By not jumping between chains to dispatch the RM out-of-band invocation,
> we avoid having to make the error-prone decision as to exactly what
> interceptors this special chain should include. This question is not
> straight-forward, as the request will already have been partially
> dispatched on the normal chain, so the special RM chain would have to
> take cognizance of this.
>
> In fact by the time the request has reached the RM interceptor, i.e. the
> point at which we recognize it as an RM out-of-band protocol message as
> opposed to an application-level request, most of the work has already
> being done ... so there wouldn't be many (if any) interceptors that it
> would make sense to include in a special chain to handle the out-of-band
> messages.


I see your point. The flip side of this though is that there aren't many
frontend specific interceptors in the beginning of the chain though.  The
holder/wrapper/logicla interceptors are at the end at least.

(On a separate note - should the SOAPHandlers even be invoked on an RM
createsequence??)

However, I'd agree that the current practice in the RM implementation of
> scanning the remainder of the chain to remove problematic interceptors
> is bad, not least as its dependent on the implementation details of a
> specific (JAX-WS) frontend. So we have to come up with a better way of
> doing this, and if possible I'd prefer to leave these interceptors in
> place in the normal chain, but make them more robust in the sense of
> being tolerant to unexpected message content.
>
> So your proposal is to make the current interceptors more tolerant of
messages not bound to them?  So if I was a WrapperClassInInterceptor I would
check to make sure the service being invoked was actually a JAX-WS service?
Can you elaborate on how exactly you see this thing working?

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

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