I think I added this a long time ago not sure if anyone other than me uses it. https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/ExceptionHandler.java
It does add the exception to the exchange as an attachment. However in the above scenario it still might not be handled.

I prefer the first option I think its pretty clean when all the handlers follow the same interface. Using attachments is already a common pattern.

I was thinking of a way to modify the existing ExceptionHandler to call your proposed setExceptionHandler or even set it as an attachment but realized it might infinite loop. Would it instead need to be split to a handler responsible for setting the attachment and one for handling it? Ideally my ExceptionHandler in the handler chain as well as the registered handler for exceptions that propagate outside the chain could be one and the same.


On Tue, Feb 7, 2017 at 5:26 PM, Stuart Douglas <sdouglas@redhat.com> wrote:
I think this is something I should address in Undertow Core (Servlet
already has io.undertow.servlet.api.ExceptionHandler), to allow you to
register a handler that will be called if an exception propagates
outside of the handler chain.

I think there are two options:

1) HttpServerExchange.setExceptionHandler(HttpHandler handler), and
then make the exception available as an attachment on the Exchange.
2) HttpServerExchange.setExceptionHandler(ExceptionHandler handler),
where ExceptionHandler has a single method that takes the exchange and
the exception.

Thoughts?

Stuart

On Wed, Feb 8, 2017 at 7:26 AM, Steve Hu <stevehu@gmail.com> wrote:
> Hi Bill,
>
> My exception handler is the first in the chain and it captures majority of
> exceptions but this one. It is basically a try/catch block to wrap all
> handler calls and you can find the source code at
> https://github.com/networknt/light-java/blob/master/exception/src/main/java/com/networknt/exception/ExceptionHandler.java
>
> I will try to dispatch in this handler first tonight and see if it works
> based on your recommendation.
>
> Hi Miere/Kim,
>
> I am in the office now and will try both your approaches tonight on my home
> computer.
>
> Thanks a lot for your help.
>
> Steve
>
> On Tue, Feb 7, 2017 at 2:22 PM, Bill O'Neil <bill@dartalley.com> wrote:
>>
>> @Steve - If your exception handler is in the handler chain before calling
>> dispatch then an exception is thrown it might not be handled properly (I
>> think I ran into this). If you make sure you add an exception handler after
>> calling dispatch that handles Throwable.class but before your logic, you
>> should be able to catch all Exceptions. I'm not 100% positive here but this
>> seemed to work for me.
>>
>>
>> On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr@asseco.dk> wrote:
>>>
>>> Hi,
>>>
>>> I have had success with adding the system property:
>>>
>>> -Dorg.jboss.logging.provider=slf4j
>>>
>>> A random search for this on the net revelated this page which does a good
>>> job of explaining various ways of getting it working with WildFly - I myself
>>> use Undertow embedded, so the system property is enough for me.
>>>
>>> /Kim
>>>
>>> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira@gmail.com>:
>>>>
>>>> Hi Steve,
>>>>
>>>> I've found myself on the same situation couple of years ago and to solve
>>>> my problem I've configured the LoggerProvider to point to
>>>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
>>>> META-INF/services/org.jboss.logging.LoggerProvider file with
>>>> org.jboss.logging.Slf4jLoggerProvider as a value.
>>>>
>>>> I hope it helps.
>>>>
>>>> Cheers!
>>>>
>>>>
>>>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Undertow is using jboss logger to log errors and my application is
>>>>> using slf4j/logback with logback.xml config file in the classpath with
>>>>> Undertow core http server embedded. I handles most exceptions in my own
>>>>> handlers but sometimes uncaught exceptions reaches Connectors class -
>>>>> executeRootHandler method which logs the error and return 500 response code.
>>>>>
>>>>> My first question: Is there a way to redirect the logs from Undertow to
>>>>> logback logs and controlled by logback.xml? I've found some discussions
>>>>> about replacing logger in WildFly but I am using embedded Undertow core
>>>>> only.
>>>>>
>>>>> Second question: When Connectors.executeRootHandler will be called? Is
>>>>> it called when you have the following line in your handler?
>>>>>
>>>>> if (exchange.isInIoThread()) {
>>>>>      exchange.dispatch(this);
>>>>>      return;
>>>>>
>>>>> }
>>>>>
>>>>> Is there any way we can by pass this so that I can handle uncaught
>>>>> exceptions in my ExceptionHandler in the handler chain?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>>> --
>>>>
>>>> Miere Teixeira
>>>>
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>>
>>>
>>>
>>> --
>>> Med venlig hilsen / Best regards
>>>
>>> Kim Rasmussen
>>> Partner, IT Architect
>>>
>>> Asseco Denmark A/S
>>> Kronprinsessegade 54
>>> DK-1306 Copenhagen K
>>> Mobile: +45 26 16 40 23
>>> Ph.: +45 33 36 46 60
>>> Fax: +45 33 36 46 61
>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev