dev@grizzly.java.net

Re: ParserProtocolFilter API

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 27 May 2008 10:26:16 +0200

Hi John,

On May 27, 2008, at 8:28 , John ROM wrote:

> well that was my first thought too but even
> when you use delagation and share the same ReadFilter
> PUReadFilter still comes first in the chain and reads
> the bytes away.....
Right. But will it be fine, if just PUReadFilter will read a data from
a channel? ParserProtocolFilter will not try to make a read, but work
with data, which was read by PUReadFilter.

>
> maybe you should leave everything as it is because flags
> always make things worse....
I agree. However as ParserProtocolFilter is abstract class, I can add
this flag as protected field, which will not be visible outside, but
custom ParserProtocolFilter implementation can change it. Besides that
default logic of the ParserProtocolFilter will remain the same as it
was.

I attach patched ParserProtocolFilter with "isSkipRead" flag. Let me
know if it works for you.

Thanks.

WBR,
Alexey.





>
>
> Many Greetings
> John
> -------- Original-Nachricht --------
>> Datum: Mon, 26 May 2008 16:46:39 +0200
>> Von: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
>> An: dev_at_grizzly.dev.java.net
>> Betreff: Re: ParserProtocolFilter API
>
>> Hello John,
>>
>>
>>> I had the following problem.
>>>
>>> I set up Portunification
>>>
>>> I have a Protocol parser down the chain.
>>>
>>> Now when MyProtocolParser returns true on isExpectingMoreData()
>>> the ReadFilter of MyProtocolParser fails because
>>> PUReadFilter read the expected bytes.
>> I see. It's really bad issue. Currently both PUReadFilter and
>> ParserProtocolFilter extend ReadFilter, which makes them difficult to
>> use together :(
>> So ideally we should split PUReadFilter and ParserProtocolFilter with
>> ReadFilter, so they will not extend ReadFilter any more.
>>
>>>
>>> Ok since My MyProtocolParsER is statefull I can cope with this, but
>>> it makes my Parser ugly.
>>>
>>> So I am thinking maybe you could change the API with a flag on
>>> ParserProtocolFilter
>>> forcing a skipping of the Reading of the ParserProtocolFilter
>>> ReadFilter.
>>>
>>> for Example in
>>> ParserProtocolFilter.java
>>>
>>> boolean continueExecution = isFlag()? true:super.execute(ctx);
>>>
>>> private boolean flag=false;
>>> public void setFlag(boolean flag) {
>>> this.flag = flag;
>>> }
>>>
>>> public boolean isFlag() {
>>> return flag;
>>> }
>> I will add some flag to ParserProtocolFilter and PUFilter, which will
>> mean whether we want these Filters to read bytes from channel. By
>> default flag will be true, so we will not break anyone.
>>
>> Can you pls. fill the issue?
>>
>> WBR,
>> Alexey.
>>
>>>
>>>
>>> Many Greetings
>>> John
>>>
>>>
>>>
>>>
>>> --
>>> Psssst! Schon vom neuen GMX MultiMessenger gehört?
>>> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
> --
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>