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 <[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
>>
>>
>>
>
>
>
