Hi!
Jeanfrancois Arcand wrote:
>> For me the biggest annoyances of the current Grizzly API are completely
>> different ways of handling client vs server events and HTTP protocol
>> implementation that doesn't work together with
>> ParserProtocolFilter/ProtocolParser (I'd really like to be wrong on
>> this).
>
> Can you elaborate? Do you means you would have liked to be able to add
> an HttpProtocolFilter instead of using the current
> GrizzlyWebServer/SelectorThread API? Then once this filter got added you
> would have liked to add your own ProtocolFilter than could process the
> decoded HTTP?
YES. But that's not all.
Basically the framework gives the impression that it consists of two very
different parts, that it was a code that was originally designed for HTTP
server side _only_ and later was converted into a generic NIO framework
that still has original HTTP protocol handling code that was never
retrofitted to the new structure.
I.e., if we are working with the Grizzly in general then we have to deal
with Controller, SelectorHandler, ProtocolChain, ProtocolFilter,
ProtocolParser etc. - it is a rather straightforward and logical API
(client side support with ConnectorHandler & CallbackHandler is the notable
exception, it doesn't quite fit in this picture). It's logical to assume
that HTTP support should be built on this foundation and one should be
easily able to implement such features as port unification for different
protocols (one of them being HTTP) or HTTP requests pre-/post-processing
(they should come as a messages out of ProtocolParser, shouldn't they? ;-)
or HTTP requests interception etc. at this low level, _before_ HTTP will
come to higher level Comet/Servlet logic.
Unfortunately, the way things are now, HTTP is a completely different
beast. :-( First of all, forget everything you know about Controller - for
HTTP support this not the main entry point to the framework anymore, now it
is SelectorThread. Second, forget about using
ProtocolChain/ProtocolParser - HTTP uses StreamAlgorithm/ProcessorTask
(deprecated!) & requires its own kind of worker threads, it is very
difficult to integrate something additional at this level. Still it _is_
possible to implement port unification/custom processing etc. with HTTP but
this unfortunately involves completely different APIs with ProtocolFinder,
ProtocolHandler, PUProtocolRequest etc. (that BTW are more difficult to use
compared to the ProtocolParser API).
In other words in the Grizzly 1.9.x it is necessary to know two different
sets of APIs that use completely different approaches to solving the same
problems, it is not possible to treat HTTP generically as one of the
protocols among others - it is THE PROTOCOL. And this is unfortunate :-(
>> But there is a minor thing that can be changed easily: IMHO
>> TCPSelectorHandler.connect method should be public. The reason being the
>> 100% asynchronous application that implements both client and server
>> doesn't really need ConnectorHandlers: SelectorHandler
>> (TCPSelectorHandler) already has the required functionality,
>> ConnectorHandlers just complicate the things (i.e. they need to be
>> released).
>
> Interesting. In that case you will just use a CallbackHandler to
> manipulate the transaction.
Yes. It'll just handle connect and delegate event processing to
ProtocolChain (to not reinvent the wheel). Actually very simple to
implement (and I believe I got this idea from your blog ;-).
> I think we can allow that but some of
> features the current ConnectorHandler offer will not be included (like
> configuring the socketChannel properly), and the final steps for
> completing the connect operation. We just need to properly document the
> method I guess. Can you file an RFE here:
>
> * https://grizzly.dev.java.net/issues/
Done:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=735
Regards,
Alexei