?
No, protected is wrong. I want to call the write method from another class
in another package so it must be public. ;-)
regards
Steve
--
View this message in context:
http://www.nabble.com/AbstractIoSession-and-final-qualifiers-tp14507695s16868p14574837.html
Sent from the Apache MINA Support
Steve Ulrich (proemion) wrote:
Emmanuel Lecharny-3 wrote:
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 ?
NO!
this message in context:
http://www.nabble.com/AbstractIoSession-and-final-qualifiers-tp14507695s16868p14574728.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
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
Hi Jeff,
Do we need to remove the final modifier if we are going to provide
setters? And assuming you are using DummySession as a mock object,
I'd suggest making AbstractIoSession.setScheduled...(...) protected
and make them public in DummySession. WDYT?
Cheers,
Trustin
On Dec 28, 2007 8:19
Yep...agreed...how is this?
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++
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
I like it (the assert) ;-)
But I am not sure about having a completely different
AbstractIOMockSession since we would then be copying code to a certain
degree. I think it would just be cleaner to have the methods protected
so there is no need for code duplication ;-)
What do *you* think? ;-)
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
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
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
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
12 matches
Mail list logo
