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