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
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
