You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Guillaume Nodet <gn...@apache.org> on 2018/05/31 14:42:32 UTC
[DISCUSS] Some SSHD refactoring before 2.0.0
Following the discussion in SSHD-340
<https://issues.apache.org/jira/browse/SSHD-340>, I'd like to start
refactoring a few internal things.
- remove a few interfaces which are not actually used, i.e. they've been
introduced because various classes have methods with similar signatures,
but there's no real concept behind, so the interface itself is never really
used beyond the fact that it declares abstract methods: WaitableFuture,
ClientSessionHolder, SessionHolder, ServerSessionHolder, IOFunction,
FactoryManagerHolder, MutableUserHolder, UsernameHolder, ChannelHolder,
UserAuthInstance, KeyPairProviderHolder, ServerProxyAcceptorHolder,
ScpFileOpenerHolder
- remove the usage of java.nio.channels.Channel which is overused. In
the JVM, it is an abstract interface for socket, file or other kind of byte
streams (input or output)
- introduce an ExecutorService, extending the usual
java.util.concurrent.ExecutorService and the
org.apache.sshd.common.Closeable interfaces and refactor all the usage to
use this interface instead of conveying both the ExecutorService along with
a shutdownExecutor flag
- enforce the usage of the Closeable interface and its subclass by
marking a few methods as final, mainly: AbstractCloseable#close,
AbstractInnerCloseable#doCloseGracefully and
AbstractInnerCloseable#doCloseImmediately
Cheers,
Guillaume Nodet
Re: [DISCUSS] Some SSHD refactoring before 2.0.0
Posted by Guillaume Nodet <gn...@apache.org>.
I've pushed a branch that can be discussed further at:
https://github.com/gnodet/mina-sshd/tree/refactoring
2018-05-31 16:42 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
> Following the discussion in SSHD-340
> <https://issues.apache.org/jira/browse/SSHD-340>, I'd like to start
> refactoring a few internal things.
>
> - remove a few interfaces which are not actually used, i.e. they've been
> introduced because various classes have methods with similar signatures,
> but there's no real concept behind, so the interface itself is never really
> used beyond the fact that it declares abstract methods: WaitableFuture,
> ClientSessionHolder, SessionHolder, ServerSessionHolder, IOFunction,
> FactoryManagerHolder, MutableUserHolder, UsernameHolder, ChannelHolder,
> UserAuthInstance, KeyPairProviderHolder, ServerProxyAcceptorHolder,
> ScpFileOpenerHolder
>
> - remove the usage of java.nio.channels.Channel which is overused. In
> the JVM, it is an abstract interface for socket, file or other kind of byte
> streams (input or output)
>
> - introduce an ExecutorService, extending the usual
> java.util.concurrent.ExecutorService and the org.apache.sshd.common.
> Closeable interfaces and refactor all the usage to use this interface
> instead of conveying both the ExecutorService along with a
> shutdownExecutor flag
>
> - enforce the usage of the Closeable interface and its subclass by
> marking a few methods as final, mainly: AbstractCloseable#close,
> AbstractInnerCloseable#doCloseGracefully and AbstractInnerCloseable#
> doCloseImmediately
>
> Cheers,
> Guillaume Nodet
>
>
>
--
------------------------
Guillaume Nodet