2010/1/12 Justin Lee <Justin.Lee_at_sun.com>
> I'm not sure this should be fixed by adding support for mulitple
> interceptors (on a ProcessorTask, e.g.). Most of the changes so far involve
> altering deprecated classes which is a little contradictory. In 2.x, the
> planned approach would be to use the port-unification/ProtocolFilter
> approach and I think we should do that for 1.9.x as well. It's a much, much
> clean approach and could be done with relatively little change to existing
> code. It'd just be another PF in the chain that would halt any further
> execution of the chain. So it'd be the same basic logic as the current
> suggested approach without all the ugly hackery going on to retrofit this
> update in a non-breaking fashion. As it is now, it's looking more and more
> like a breaking API change on the 1.9.x tree and that's something we're
> striving to avoid. Thoughts?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
The current impl in trunk dont break any API.
Can you provide a working example of what your proposing, for example how
websocket is to use it?.
The existing code is in processortask in trunk.
--
regards
gustav trede