Salut,
Oleksiy Stashok wrote:
> Hi John,
>
> thank you for good description.
> Agree with your point on each possible solution.
> I think #2 is quite good. This way we will rid off the ReadFilter
> dependancy and mostly will not require rewriting of existing code.
> #3 is good, but I agree with you, it could cause a lot of backwards
> compatibility issues.
I would go with John on that one and maybe we should implement #1. I
agree it will be quite ugly but so far it doesn't seems SSL was used
with the ProtocolParser. Although 2 would be the best solution, I would
think 1 is safer because we aren't breaking anybody.
What do you think?
A+
-- Jeanfrancois
>
> Thanks.
>
> WBR,
> Alexey.
>
> PS: If we'll decide to implement #2, we need to make
> ParserProtocolFilter implement ReinvokeAware interface.
>
> On Oct 6, 2008, at 11:59 , John ROM wrote:
>
>> Hi,
>> In issue 255 we found that
>> "com.sun.grizzly.filter.ParserProtocolFilter does not
>> support SSL". Normally it should be very simple to support SSL.
>> Just add SSLFilter instead of ReadFilter to the ProtocolChain. But since
>> ParserProtocolFilter extends ReadFilter this is currently not possible.
>>
>> I see 3 ways to fix this
>>
>> Option 1 :
>>
>> Simplest way. Give ParserProtocolFilter a member SSLFilter and
>> if ParserProtocolFilter is in "SSL mode" delegate to SSLFilter instead
>> of its parent.
>>
>> Advantage : does not break any code and documentation (blogs,etc.) and
>> very easy to implement. (Maybe SSLFilter needs to be changed a little)
>> Disadvantage: ugly
>>
>> Option 2:
>>
>> Get rid of ReadFilter Inheritance.
>> Let ParserProtocolFilter have a member (ProtocolFilter) which defaults
>> to ReadFilter but could be set to SSLFilter or any "Reading-Filter"
>>
>> Advantage : Only breaks existing code if some subclass uses ReadFilter
>> members.
>> Easy to implement since internal logic of
>> ProtocolFilter and also Protocolchain behaviour does not need to change.
>>
>> Option 3:
>>
>> Get rid of ReadFilter Inheritance and rely on user adding a
>> "Reading-Filter" before to the Protocolchain.
>>
>> Disadvantage:
>> breaks all code relying on ParserProtocolFilter and its subclasses
>> (for example ResourceAllocationFilter)
>> I think there's a lot of code using these classes.
>> Basically they all have to add a ReadFilter to the ProtocolChain.
>> Also quite a change to the internal logic of ParserProtocolFilter is
>> necessary.
>> For example "hasMoreBytes state" can not just reinvoke the chain
>> because then the ReadFilter Filter would also then be invoked.
>>
>>
>> So at first I thought option 3 is best. But now especially since
>> Grizzly 2.0 is on the road I now favor Option 1
>>
>> What do you think?
>>
>> Many Greetings
>> John
>>
>> --
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>