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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

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(a)gmail.com&gt;: > 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(a)gmail.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > -- > > Miere Teixeira > > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)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 <+45%2026%2016%2040%2023> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061> _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

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/ja... 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(a)dartalley.com&gt; 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(a)asseco.dk&gt; 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(a)gmail.com&gt;: >>> >>> 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >>> -- >>> >>> Miere Teixeira >>> >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

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(a)redhat.com&gt; 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(a)gmail.com&gt; 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/exceptio > n/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(a)dartalley.com&gt; 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(a)asseco.dk&gt; 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(a)gmail.com&gt;: > >>>> > >>>> 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(a)gmail.com&gt; 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(a)lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev > >>>> > >>>> -- > >>>> > >>>> Miere Teixeira > >>>> > >>>> > >>>> _______________________________________________ > >>>> undertow-dev mailing list > >>>> undertow-dev(a)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(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/undertow-dev > >> > >> > >> > >> _______________________________________________ > >> undertow-dev mailing list > >> undertow-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev >

On Tue, Feb 7, 2017 at 2:26 PM, Stuart Douglas <sdouglas(a)redhat.com&gt; 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/79ce8210f4003a712f48e4e12c06... (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(a)gmail.com&gt; 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/ja... >> >> 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(a)dartalley.com&gt; 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(a)asseco.dk&gt; 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(a)gmail.com&gt;: >>>>> >>>>> 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>>> >>>>> -- >>>>> >>>>> Miere Teixeira >>>>> >>>>> >>>>> _______________________________________________ >>>>> undertow-dev mailing list >>>>> undertow-dev(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >>> >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev

Hi Kim/Miere, As a temp solution, I have tried both approaches and I can confirm that the system property works. Somehow, I cannot make the SPI work. I even tried to include jboss-logging, jboss-logging-processor and jboss-logmanager. Thanks, Steve On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr(a)asseco.dk&gt; 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(a)gmail.com&gt;: > >> 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(a)gmail.com&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> -- >> >> Miere Teixeira >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)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 <+45%2026%2016%2040%2023> > Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060> > Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061> >

2. As long as you are ok with making every route a blocking route that should be fine. I did the same thing. https://github.com/undertow-io/undertow/blob/master/core/ src/main/java/io/undertow/server/handlers/BlockingHandler.java#L52 I use the blocking handler above before passing to the exception handler. Your return seems out of place and it also never calls startBlocking(). I'm not sure how important that is. On Wed, Feb 8, 2017 at 5:53 AM, Steve Hu <stevehu(a)gmail.com&gt; wrote: > Just summarize what I have done and I think this is working for me very > well. > > 1. I have put a line in my server during server start up to redirect > Undertow logs to slf4j. -D in command line works but I think it impact the > DevOps flow. > > System.setProperty("org.jboss.logging.provider", "slf4j"); > > 2. I have put the following lines to dispatch in the beginning of ExceptionHandler.handleRequest. I think this is fine as most handlers shouldn't be executed in IO thread anyway. This will make sure that all exceptions will be captured by my handler instead of Connectors. > > if (exchange.isInIoThread()) { > exchange.dispatch(this); > return; > } > > Thanks everyone for your help. > > Steve > > > > On Tue, Feb 7, 2017 at 9:48 PM, Steve Hu <stevehu(a)gmail.com&gt; wrote: > >> Hi Kim/Miere, >> >> As a temp solution, I have tried both approaches and I can confirm that >> the system property works. Somehow, I cannot make the SPI work. I even >> tried to include jboss-logging, jboss-logging-processor and >> jboss-logmanager. >> >> Thanks, >> >> Steve >> >> On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr(a)asseco.dk&gt; 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(a)gmail.com&gt;: >>> >>>> 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> >>>> -- >>>> >>>> Miere Teixeira >>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev(a)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 <+45%2026%2016%2040%2023> >>> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060> >>> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061> >>> >> >> > > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev >