Hi Bongjae,
Thank you for your reply. I knew your point.
CacheableConnectorHandler extends AbstractConnectorHandler, and
other protocol dependent handlers (UDP/TCP ConnectorHandler) extend it too.
I think it is not straightforward that behavior of
finishConnect/getUnderlyingChannel is different between
CacheableConnectorHandler and the others. Anyway, it is OK for me.
Thanks!
> Hi Minoru,
>
> I think that CCH#getUnderlyingChannel doesn't return null if you use DefaultCallback.
>
> See the following code:
>
> In DefaultCallback#onConnect()
> ---
> public void onConnect(...)
> SelectionKey key = ioEvent.attachment().getSelectionKey();
> if( connectorHandler instanceof AbstractConnectorHandler ) {
> ((AbstractConnectorHandler) connectorHandler).setUnderlyingChannel( key.channel());
> }
> ---
>
> I think that it can depend on your CallbackHandler.
>
> What do you think?
>
> --
> Bongjae Chang
>
>
> ----- Original Message -----
> From: "Minoru Nitta" <minoru.nitta_at_jp.fujitsu.com>
> To: <dev_at_grizzly.dev.java.net>
> Sent: Thursday, June 18, 2009 2:03 PM
> Subject: CacheableConnectorHandler.getUnderlyingChannel returns null
>
>
> > Salut,
> >
> >
> > I think CacheableConnectorHandler.getUnderlyingChannel returns null
> > in some cases. That is because CacheableConnectorHandler.finishConnect
> > calls underlyingConnectorHandler.finishConnect, but underlyingChannel
> > is set to the underlyingConnectorHandler, not to CacheableConnectorHandler.
> >
> > To get underlyingChannel, I should fist call
> > CacheableConnectorHandler.getUnderlyingConnectorHandler and after that,
> > I should call getUnderlyingChannel? Or is this a bug of Grizzly?
> >
> > Minoru
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >
> >
> >
> >