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.
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
>