I agree...this makes sense...Filter is the way to go.
Jeff
Trustin Lee wrote:
> Alternatively, we could add a protected method in AbstractIoSession
> and make write() method to call it before returning. However, it is
> essentially the same with adding an IoFilter IMHO.
>
> The implementation of IoSession and IoFilterChain is not so trivial so
> creating another mock object is a kind of huge task so we will finally
> have a lot of duplicated code there, so I think it is somewhat
> difficult to create a separate mock object; I already tried to do that
> and gave up. :)
>
> Trustin
>
> On Dec 27, 2007 10:48 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
>> Hi Jeff and Emmanuel,
>>
>> You can add some hook for IoSession.write() by inserting an IoFilter,
>> so I am not sure about removing the final modifier from write().
>>
>> Overriding getScheduledMessages and getScheduledBytes makes sense
>> though because they will always be 0 because messageSent event will be
>> always fired immediately.
>>
>> WDYT?
>>
>> Trustin
>>
>>
>> On Dec 27, 2007 10:21 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
>>> Jeff Genender wrote:
>>>> What do *you* think? ;-)
>>>>
>>> Beside the assert, which was a side effect of my quick glance at the
>>> method you want to override, I think that dooming the final is sane.
>>>
>>> If someone needs to protect this method, then the best solution would be
>>> to define a super class with final methods calling the AbstractIoSession
>>> non final methods.
>>>
>>> Another solution (puke....) would be to remove the
>>> public/protected/private qualifier, and to add a MockIoSession in the
>>> same package. Not very elegant, but does the job too...
>>>
>>> There are always tradeoff when you want to thoroughly unit-test some
>>> code. When it comes to an API, it seems impossible to avoid those
>>> tradeoff, IMHO.
>>>
>>> Any other opinion ? Trustin ? Julien ?
>>>
>>>> Jeff
>>>>
>>>>
>>>> Emmanuel Lecharny wrote:
>>>>
>>>>> Jeff Genender wrote:
>>>>>
>>>>>> Hey guys,
>>>>>>
>>>>>> I was hoping to see if we could discuss some of the "final" qualifiers
>>>>>> on some of the methods in the AbstractIOSession. The reason I ask is it
>>>>>> would be cool to be able to override some of the methods such as:
>>>>>>
>>>>>> public WriteFuture write(Object message)
>>>>>> public final int getScheduledWriteMessages()
>>>>>>
>>>>>> To be able to write MockObjects for unit tests of code. Any thoughts on
>>>>>> making these protected instead of final?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>>
>>>>>>
>>>>> Hi,
>>>>>
>>>>> makes sense to me... Or we may have a AbstractMockIoSession implementing
>>>>> the IoSession interface, for unit tests ?
>>>>>
>>>>> While looking at the abstract class, I found some methods with this kind
>>>>> of code :
>>>>>
>>>>> public final WriteFuture write(Object message, SocketAddress
>>>>> remoteAddress) {
>>>>> if (message == null) {
>>>>> throw new NullPointerException("message");
>>>>> }
>>>>> ...
>>>>>
>>>>> Wouldn't be a perfect case for an assert ? Like :
>>>>>
>>>>> public final WriteFuture write(Object message, SocketAddress
>>>>> remoteAddress) {
>>>>> assert message != null : "Null messages are not allowed";
>>>>> ...
>>>>>
>>>>> wdyt ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> cordialement, regards,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>> directory.apache.org
>>>
>>>
>>>
>>
>>
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>> --
>> PGP Key ID: 0x0255ECA6
>>
>
>
>
