Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of Andrea.Smyth@iona.com
 designates 62.221.12.33 as permitted sender)
Message-ID: <45A26988.4010607@iona.com>
Date: Mon, 08 Jan 2007 15:55:52 +0000
From: Andrea Smyth <andrea.smyth@iona.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: JaxwsInterceptorRemoverInterceptor and RM
References: <FA1787F64A095C4090E76EBAF8B183E071FB69@owa-emea.iona.com>
 <7b774c950701071728iefa0035he3affe083b95ecf7@mail.gmail.com>
In-Reply-To: <7b774c950701071728iefa0035he3affe083b95ecf7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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