[undertow-dev] Undertow jboss logging redirect to logback log file and console

[Stuart Douglas]

So at the moment it is possible to get this functionality, it is just
not the most intuitive API wise.

If you register a io.undertow.server.DefaultResponseListener it will
be called when the exchange is ended, and if it ended via an exception
the exception will be available under
io.undertow.server.DefaultResponseListener#EXCEPTION, so you can just
check for this attachment, and if it is present do your exception
handling logic.


Stuart

On Thu, Mar 16, 2017 at 8:58 AM, Michael Hixson
<michael.hixson at gmail.com> wrote:
> On Tue, Feb 7, 2017 at 2:26 PM, Stuart Douglas <sdouglas at 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
>>
>
> I was looking for this feature recently.  Did you already decide
> whether to add it or not?
>
> Specifically, I think I want to be able to plug custom behavior into here:
>
> https://github.com/undertow-io/undertow/blob/79ce8210f4003a712f48e4e12c0626ff18cd78c5/core/src/main/java/io/undertow/server/Connectors.java#L239-L249
>
> (That's what you had in mind too, right?)
>
> I'd personally prefer option 2 so that the type and method
> signature(s) of the handler reminds me of its purpose.
>
> -Michael
>
>> On Wed, Feb 8, 2017 at 7:26 AM, Steve Hu <stevehu at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Miere Teixeira
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> undertow-dev mailing list
>>>>>> undertow-dev at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev