The current approach alexey and I have been talking about is to allow
more than one Interceptor on a task. This causes all sorts of cascading
and breaking changes on the StreamAlgorithm classes, e.g., which are
deprecated in favor of the port unification classes favored by 2.0.
On 1/12/10 4:23 PM, gustav trede wrote:
> 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.
>
>
>