mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: AbstractIoSession and final qualifiers
Date Thu, 27 Dec 2007 23:19:56 GMT
Trustin (and others)...so how about these changes and additions to the
AbstractIoSession?  This will allow the scheduledBytes/messages to be
overriden, and also allow someone to set them.

Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===================================================================
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -488,14 +488,22 @@
         lastThroughputCalculationTime = currentTime;
     }

-    public final long getScheduledWriteBytes() {
+    public long getScheduledWriteBytes() {
         return scheduledWriteBytes.get();
     }

-    public final int getScheduledWriteMessages() {
+    public int getScheduledWriteMessages() {
         return scheduledWriteMessages.get();
     }

+    public void setScheduledWriteBytes(long byteCount){
+        scheduledWriteBytes.set(byteCount);
+    }
+
+    public void setScheduledWriteMessages(int messages) {
+        scheduledWriteMessages.set(messages);
+    }
+
     protected final void increaseReadBytes(long increment, long
currentTime) {
         if (increment <= 0) {
             return;


Thanks,

Jeff

Trustin Lee 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 <elecharny@gmail.com> 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
>>
>>
>>
> 
> 
> 

Mime
View raw message