Hi Minoru,
Minoru wrote:
> 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.
Your view is true in a way. I could see..
In my old memory, CacheableConnectorHandler didn't extend AbstractConnectorHandler.
But from a reusable point of view(repeated code's recycle), I think that it seems that this change is not bad.
It is just my opinion. :-)
Thanks!
--
Bongjae Chang
----- Original Message -----
From: "Minoru Nitta" <minoru.nitta_at_jp.fujitsu.com>
To: <dev_at_grizzly.dev.java.net>
Sent: Friday, June 19, 2009 8:04 AM
Subject: Re: CacheableConnectorHandler.getUnderlyingChannel returns null
> 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
>> >
>> >
>> >
>> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
>
>