I didn't know there are so many isRequest methods hiding in the code ;-) I knew only MessageUtils's one, which was probably added later after some time.
The inconsistency that you observed between AbstractInDatabindingIntereceptor and AbstractOutDatabindingIntereceptor was the result of this patch https://svn.apache.org/viewvc?view=revision&revision=477226 which only fixed this method in AbstractInDatabindingIntereceptor. In any case, I think we should remove these other methods from the master version. For the released tracks, we probably need to keep them as @deprecated with delegating to MessageUtils impl. 2014-11-27 12:49 GMT+01:00 Jason Pell <[email protected]>: > Oh and then we have another method in the AbstractPhaseInterceptor which > calls > > protected boolean isRequestor(T message) { > return MessageUtils.isRequestor(message); > } > > Would it be possible to remove the isRequestor methods from > AbstractOutDatabindingInterceptor and AbstractInDatabindingInterceptor > > Anyone know of any reason why that would be problematic? > > On Thu, Nov 27, 2014 at 10:45 PM, Jason Pell <[email protected]> wrote: > >> Hi All >> >> Was wondering if anyone knows why in AbstractOutDatabindingInterceptor, >> isRequestorRole has a definition of: >> >> protected boolean isRequestor(Message message) { >> return >> Boolean.TRUE.equals(message.containsKey(Message.REQUESTOR_ROLE)); >> } >> >> Whereas in AbstractInDatabindingInterceptor its: >> >> protected boolean isRequestor(Message message) { >> return Boolean.TRUE.equals(message.get(Message.REQUESTOR_ROLE)); >> } >> >> >> The first is just returning true if the Message.REQUESTOR_ROLE exists, >> whereas for the second the Message.REQUESTOR_ROLE must be equal to TRUE. >> >> Seems very strange to have this difference. Dones anyone know the history >> of this? >> >> >> >> >>
