> -----Original Message----- > From: Andrea Smyth [mailto:[EMAIL PROTECTED] > Sent: 05 January 2007 15:59 > To: [email protected] > 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
