Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950612221859p23946fc6va1289e2fa0468e0b@mail.gmail.com>
Date: Fri, 22 Dec 2006 16:59:45 -1000
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: JaxwsInterceptorRemoverInterceptor and RM
In-Reply-To: <FA1787F64A095C4090E76EBAF8B183E071FB47@owa-emea.iona.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_55788_10686699.1166842785629"
References: <FA1787F64A095C4090E76EBAF8B183E071FB47@owa-emea.iona.com>

------=_Part_55788_10686699.1166842785629
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_55788_10686699.1166842785629--