You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jason Pell <ja...@pellcorp.com> on 2014/11/27 12:45:42 UTC
Two different tests for isRequestor??
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?
Re: Two different tests for isRequestor??
Posted by Aki Yoshida <el...@gmail.com>.
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 <ja...@pellcorp.com>:
> 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 <ja...@pellcorp.com> 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?
>>
>>
>>
>>
>>
Re: Two different tests for isRequestor??
Posted by Jason Pell <ja...@pellcorp.com>.
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 <ja...@pellcorp.com> 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?
>
>
>
>
>