I understand the tendency for defensive style design.
Auto start option should probably be removed from the SSL Filter. If OP
wishes to construct the chain at Open() time then calling SSL Filter.open()
manually should initiate the handshake.
@Override
public void proxySessionOpened(IoSession session) throws Exception {
log.info("proxySessionOpened called");
if (sslFilter != null) {
IoFilter.NextFilter nextFilter = session.getFilterChain().
getNextFilter(sslFilter);
sslFilter.sessionOpened(next, session)
}
}
This seems to me more like a fundamental flow problem of filter
modifications than a design issue with SSL filter.
On Thu, Jan 28, 2016 at 10:45 AM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:
> Le 28/01/16 15:37, Jon V. a écrit :
> > Sorry, I hit enter and my email sent.
> >
> > IoFilterChain filterChain = session.getFilterChain();
> >
> > if (filterChain == null) {
> > throw new SSLException("No filter chain");
> > }
> >
> >
> > This isn’t necessary. I think we need to know more about OPs goals
> before
> > adding hacky workarounds.
>
> Hmm, yeah, it's probably over-protective.
>
> With respect to such check, I should first have added a if (session ==
> null), and not having such a check makes teh second check a bit spurious.
>
> We can drop it and only have :
>
> public void initiateHandshake(IoSession session) throws SSLException {
> IoFilter.NextFilter nextFilter =
> session.getFilterChain().getNextFilter(SslFilter.class);
>
> if (nextFilter == null) {
> throw new SSLException("No SSL next filter in the chain");
> }
>
> initiateHandshake(nextFilter, session);
> }
>
> For teh same reason, I don't see any use case where we can't have a
> nextFilter, so the if (nextFilter == null) is also spurious.
>
>
> I may have been hit too many times by pervasive NPE, and I try to catch
> them before they happen...
>
