Would taking the approach used in CombinedChannelDuplexHandler work,
perhaps?
i.e. using something like the DelegatingChannelHandlerContext to
intermediate access to the pipeline? Possibly creating sub-pipelines using
EmbeddedPipeline, perhaps?
Rogan
On Wednesday, March 21, 2018 at 8:57:15 PM UTC+2, Rogan Dawes wrote:
>
> Nope, java.lang.reflect.Proxy won't work either, because of things like:
>
> ChannelInitializer:
>
> void initChannel(Channel ch) throws Exception {
> String me = ch.context(this).name();
> ch.pipeline().addAfter(me, null, new WhateverHandler());
> }
>
> fails with a NullPointerException because context(this) returns null,
> because "this" is not actually in the pipeline(), Proxy(this) is!
>
> Sigh!
>
> While in theory, I could extend handlerAdded(ctx) and save a ref to the
> ctx to be used in initChannel(), that would work for my own code, but is
> unlikely to work for anyone else's!
>
> Perhaps there is a way to achieve what I want without the shenanigans?
>
> What I'm ultimately trying to do is "blame" the ChannelHandler that throws
> an Exception.
>
> So while I can implement exceptionCaught() in the last handler of the
> pipeline, and catch the Exception, it's impossible to know which
> ChannelHandler actually threw that Exception, other than by stepping
> through the stackTrace, and looking for my own code (or Netty code, as the
> case may be!) However, if there is more than one instance of a particular
> ChannelHandler (e.g. tunnelling SSL in SSL), that still doesn't tell you
> which *instance* threw the exception.
>
> My solution to that was to alternate legitimate ChannelHandlers with an
> ExceptionCatcher ChannelHandler. Each ExceptionCatcher has a reference to
> the ChannelHandler before it. The first ExceptionCatcher to have its
> exceptionCaught() method called can blame the ChannelHandler immediately
> preceding it.
>
> HOWEVER, should that ChannelHandler remove itself from the pipeline, or
> insert other ChannelHandlers, it all falls down, because the
> ExceptionCatcher gets left behind!
>
> An alternative way to approach this would be to extend
> DefaultChannelPipeline, but that kind of thing seems to be deprecated in
> netty 4.
>
> Any suggestions?
>
> Thanks!
>
> Rogan
>
>
> On Wed, Mar 21, 2018 at 3:56 PM Rogan Dawes <[email protected]
> <javascript:>> wrote:
>
>> I guess I could try using Java.lang.reflect.Proxy to wrap the class and
>> supplement handlerRemoved.
>>
>> Should work ok, I think.
>>
>> Rogan
>> On Wed, 21 Mar 2018 at 10:59 'Norman Maurer' via Netty discussions <
>> [email protected] <javascript:>> wrote:
>>
>>> No there is nothing like that.
>>>
>>> Bye
>>> Norman
>>>
>>>
>>> On 20. Mar 2018, at 21:53, Rogan Dawes <[email protected] <javascript:>>
>>> wrote:
>>>
>>> Hi folks,
>>>
>>> I'm trying to monitor changes to the pipeline, and wondering if there is
>>> any way to be notified when a handler is removed from a pipeline?
>>>
>>> By that I mean, independently of the specific handler's
>>> handlerRemoved(ctx) method call. I'd like to be able to tell when a
>>> particular handler is removed, without having to extend it and override
>>> that method on every single handler.
>>>
>>> From what I can see, the only way to do it at the moment is by using
>>> Aspect-Oriented programming, and decorating each handler that is added (a
>>> slight difference from manually extending each handler).
>>>
>>> Am I missing something?
>>>
>>> Thanks!
>>>
>>> Rogan
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Netty discussions" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected] <javascript:>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/netty/0c580f34-35bf-4d69-ad80-f0ad0d7e1605%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/netty/0c580f34-35bf-4d69-ad80-f0ad0d7e1605%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Netty discussions" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected] <javascript:>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/netty/3CA9AB84-DC67-4BAB-8392-AC8143F79440%40googlemail.com
>>>
>>> <https://groups.google.com/d/msgid/netty/3CA9AB84-DC67-4BAB-8392-AC8143F79440%40googlemail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Netty discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/netty/c72b76af-20ea-4b00-8ecd-2419a5784fb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
