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

Bill O'Neil bill at dartalley.com
Tue Feb 7 18:01:12 EST 2017


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 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
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/1c05fed7/attachment.html 


More information about the undertow-dev mailing list