I've looked at what Harsha is doing for the ORB and thought about
various ways this might be done. In the end, I though it was better not
to force protocol parsers to use a message data type (because then other
filters in the pipeline would have to know about that), but still to
allow them to use one if they want (which can simplify downstream
filters).
So basically, the idea is this: the protocol parser can return an
arbitrary type from the hasNextMessage() method. However, that method
should still set up the buffer limit/position at the message boundaries.
Then a downstream filter has two options: it can use
context.getAttribute(ProtocolParser.MESSAGE) to see if there is a
defined message (and if so, it can use that message), or it can just use
the correctly established buffer to get the data. That means that things
like LogFilters can work without knowing anything about what's upstream:
they can just process the raw data. But it also means that smart filters
can avoid parsing the message twice. And finally, it means that an
implementor of a particular protocol doesn't have to override
ParserProtocolFilter (Harsha is doing that for the ORB, and given the
complexities of CORBA, that probably makes sense in that case, though I
believe that even the ORB might be able to use the standard
ParserProtocolFilter).
The only downside is that parsers have to do two things: make a message
and set the buffer limits. Actually, there's no requirement that they
make a message: they can safely return null from the hasNextMessage()
method, and everything downstream can just operate on the buffer. So
that helps the simple case too.
I've attached the modified ParserProtocolFilter and ProtocolPaser
interface for comments.
-Scott