logback-access in an embedded jetty server
I have small main program that fires up a Jetty 9 server. This server is able to run/deploy any war file supplied to it as a command line argument. I construct a *logback-access* appender programmatically, give that appender to an instance of *ch.qos.logback.access.jetty.RequestLogImpl* and wrap that instance in a *org.eclipse.jetty.server.handler.RequestLogHandler* that is finally supplied to the jetty server: handlers.addHandler(webappHandler(contextPath(), warURL())); handlers.addHandler(requestLogHandler()); server.setHandler(handlers); Now, the web-application also uses logback, and has those artifacts in its *WEB_INF/lib* directory inside the war. It appears that the logback-access configuration in the main program and the logging performed by the webapp somewhat interfere with eachother. The symptom is that I see nothing in the request log, so I guess the logging configuration in the webapp "wins", and overrides the request log configuration in the main program. If I do not deploy a webapp, but instead just serve some static files, the request log works as expected, so I believe that my appender is constructed correctly. Is there any way the logging configuration from the webapp and the request log configuration from the server can co-exist ?
Hi Jan-Olav, Thank you for your message. In principle, logback-access and logback-classic are initialized independently. However, both are based on logback-core and require it to be available and the class path. Thus, if you wish to use logback-access and logback-classic than you need to make sure that logback-core.jar is accessible to your web-app as well as jetty. Without knowing how jetty sets up its classpath, it is hard to be more specific. However, I am 100% certain that your hypothesis about one configuration winning over the other is incorrect. As mentioned above, logback-access and logback-classic are initialized independently. In no way do they reference each-other's configuration files. I hope this helps. -- Ceki Ps. please let us know if you figure this out. On 1/23/2017 17:23, Jan-Olav Eide wrote:
I have small main program that fires up a Jetty 9 server. This server is able to run/deploy any war file supplied to it as a command line argument.
I construct a /logback-access/ appender programmatically, give that appender to an instance of /ch.qos.logback.access.jetty.RequestLogImpl/ and wrap that instance in a /org.eclipse.jetty.server.handler.RequestLogHandler/ that is finally supplied to the jetty server:
|handlers.addHandler(webappHandler(contextPath(), warURL())); handlers.addHandler(requestLogHandler()); server.setHandler(handlers); |
Now, the web-application also uses logback, and has those artifacts in its /WEB_INF/lib/ directory inside the war. It appears that the logback-access configuration in the main program and the logging performed by the webapp somewhat interfere with eachother. The symptom is that I see nothing in the request log, so I guess the logging configuration in the webapp "wins", and overrides the request log configuration in the main program. If I do not deploy a webapp, but instead just serve some static files, the request log works as expected, so I believe that my appender is constructed correctly.
Is there any way the logging configuration from the webapp and the request log configuration from the server can co-exist ?
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Thanks for replying. Logback classic and core are available to both jetty and the webapp. Any theory why *not* deploying the war makes the request log behave as expected serving static files? My only explanation was some sort of race condition. Note that my appender is set up in code, not via a logback-access.xml. Would that make a difference ? -- Sendt fra min Sinclair ZX Spectrum Den 23. jan. 2017 kl. 18.15 skrev Ceki Gülcü <ceki@qos.ch>: Hi Jan-Olav, Thank you for your message. In principle, logback-access and logback-classic are initialized independently. However, both are based on logback-core and require it to be available and the class path. Thus, if you wish to use logback-access and logback-classic than you need to make sure that logback-core.jar is accessible to your web-app as well as jetty. Without knowing how jetty sets up its classpath, it is hard to be more specific. However, I am 100% certain that your hypothesis about one configuration winning over the other is incorrect. As mentioned above, logback-access and logback-classic are initialized independently. In no way do they reference each-other's configuration files. I hope this helps. -- Ceki Ps. please let us know if you figure this out.
On 1/23/2017 17:23, Jan-Olav Eide wrote: I have small main program that fires up a Jetty 9 server. This server is able to run/deploy any war file supplied to it as a command line argument.
I construct a /logback-access/ appender programmatically, give that appender to an instance of /ch.qos.logback.access.jetty.RequestLogImpl/ and wrap that instance in a /org.eclipse.jetty.server.handler.RequestLogHandler/ that is finally supplied to the jetty server:
|handlers.addHandler(webappHandler(contextPath(), warURL())); handlers.addHandler(requestLogHandler()); server.setHandler(handlers); |
Now, the web-application also uses logback, and has those artifacts in its /WEB_INF/lib/ directory inside the war. It appears that the logback-access configuration in the main program and the logging performed by the webapp somewhat interfere with eachother. The symptom is that I see nothing in the request log, so I guess the logging configuration in the webapp "wins", and overrides the request log configuration in the main program. If I do not deploy a webapp, but instead just serve some static files, the request log works as expected, so I believe that my appender is constructed correctly.
Is there any way the logging configuration from the webapp and the request log configuration from the server can co-exist ?
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Well, things worked much better with a logback-access.xml file rather than a programmatic construction of the same configuration. Strange, since the latter code works fine elsewhere. But I am happy now -- Sendt fra min Sinclair ZX Spectrum Den 23. jan. 2017 kl. 18.20 skrev Jan-Olav Eide <janolaveide@gmail.com>: Thanks for replying. Logback classic and core are available to both jetty and the webapp. Any theory why *not* deploying the war makes the request log behave as expected serving static files? My only explanation was some sort of race condition. Note that my appender is set up in code, not via a logback-access.xml. Would that make a difference ? -- Sendt fra min Sinclair ZX Spectrum Den 23. jan. 2017 kl. 18.15 skrev Ceki Gülcü <ceki@qos.ch>: Hi Jan-Olav, Thank you for your message. In principle, logback-access and logback-classic are initialized independently. However, both are based on logback-core and require it to be available and the class path. Thus, if you wish to use logback-access and logback-classic than you need to make sure that logback-core.jar is accessible to your web-app as well as jetty. Without knowing how jetty sets up its classpath, it is hard to be more specific. However, I am 100% certain that your hypothesis about one configuration winning over the other is incorrect. As mentioned above, logback-access and logback-classic are initialized independently. In no way do they reference each-other's configuration files. I hope this helps. -- Ceki Ps. please let us know if you figure this out.
On 1/23/2017 17:23, Jan-Olav Eide wrote: I have small main program that fires up a Jetty 9 server. This server is able to run/deploy any war file supplied to it as a command line argument.
I construct a /logback-access/ appender programmatically, give that appender to an instance of /ch.qos.logback.access.jetty.RequestLogImpl/ and wrap that instance in a /org.eclipse.jetty.server.handler.RequestLogHandler/ that is finally supplied to the jetty server:
|handlers.addHandler(webappHandler(contextPath(), warURL())); handlers.addHandler(requestLogHandler()); server.setHandler(handlers); |
Now, the web-application also uses logback, and has those artifacts in its /WEB_INF/lib/ directory inside the war. It appears that the logback-access configuration in the main program and the logging performed by the webapp somewhat interfere with eachother. The symptom is that I see nothing in the request log, so I guess the logging configuration in the webapp "wins", and overrides the request log configuration in the main program. If I do not deploy a webapp, but instead just serve some static files, the request log works as expected, so I believe that my appender is constructed correctly.
Is there any way the logging configuration from the webapp and the request log configuration from the server can co-exist ?
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Hi Jan-Olav, It's not possible to tell without seeing the code in question. Would you want to post it here? -- Ceki On 1/24/2017 19:43, Jan-Olav Eide wrote:
Well, things worked much better with a logback-access.xml file rather than a programmatic construction of the same configuration. Strange, since the latter code works fine elsewhere.
This works : <configuration debug="true"> <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> <appender name="REQUESTLOG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/bps/log/request/bpayadmin_request.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/bps/log/archive/request/my_request_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip </fileNamePattern> <maxHistory>30</maxHistory> <TimeBasedFileNamingAndTriggeringPolicy class="no.buypass.gen.log.StartupTimeBasedTriggeringPolicy" /> </rollingPolicy> <encoder> <pattern>combined</pattern> </encoder> </appender> <appender-ref ref="REQUESTLOG" /> </configuration> This does not work (it archives etc, but never any contents in the file) : LoggerContext loggerContext = LoggerContext.class.cast(LoggerFactory.getILoggerFactory()); RollingFileAppender<IAccessEvent> appender = new RollingFileAppender<>(); appender.setName("REQUESTLOG"); appender.setFile("/bps/log/request/myrequest.log"); TimeBasedRollingPolicy<IAccessEvent> timePolicy = new TimeBasedRollingPolicy<>(); timePolicy.setFileNamePattern("/bps/log/archive/request/my_request_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip"); timePolicy.setContext(loggerContext); timePolicy.setMaxHistory(30); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(new StartupTimeBasedTriggeringPolicy<IAccessEvent>()); timePolicy.setParent(appender); appender.setRollingPolicy(timePolicy); appender.setTriggeringPolicy(timePolicy); PatternLayoutEncoder encoder = new PatternLayoutEncoder(); encoder.setPattern("combined"); appender.setEncoder(encoder); RequestLogImpl requestLog = new RequestLogImpl(); requestLog.addAppender(appender); On 24 January 2017 at 22:04, Ceki Gülcü <ceki@qos.ch> wrote:
Hi Jan-Olav,
It's not possible to tell without seeing the code in question. Would you want to post it here?
-- Ceki
On 1/24/2017 19:43, Jan-Olav Eide wrote:
Well, things worked much better with a logback-access.xml file rather than a programmatic construction of the same configuration. Strange, since the latter code works fine elsewhere.
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
LoggerContext is the context for logback-classic whereas RequestLogImpl *is* the context for logback-access+Jetty. You need to set requestLog (of type RequestLogImpl) as the context for components such as RollingFileAppender and TimeBasedRollingPolicy. By the way, all logback components must be started. Otherwise, they will not work. As such, here a revised version which should work better. Beware, I have not tested this code and it may still contain some wrinkles. Without further ado here is the code: RequestLogImpl requestLog = new RequestLogImpl(); // implements Context ch.qos.logback.access.PatternLayoutEncoder encoder = new ch.qos.logback.access.PatternLayoutEncoder(); encoder.setContext(requestLog); encoder.setPattern("combined"); encoder.start(); // // components must be started RollingFileAppender<IAccessEvent> appender = new RollingFileAppender<IAccessEvent>(); appender.setContext(requestLog); // requestLog is the context appender.setName("REQUESTLOG"); appender.setFile("/bps/log/request/myrequest.log"); appender.setEncoder(encoder); TimeBasedRollingPolicy<IAccessEvent> timePolicy = new TimeBasedRollingPolicy<IAccessEvent>(); timePolicy.setFileNamePattern("/bps/log/archive/request/my_request_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip"); timePolicy.setContext(requestLog); // requestLog is the context timePolicy.setMaxHistory(30); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(new StartupTimeBasedTriggeringPolicy<IAccessEvent>()); timePolicy.setParent(appender); timePolicy.start(); // components must be started appender.setRollingPolicy(timePolicy); appender.setTriggeringPolicy(timePolicy); appender.start(); // // components must be started requestLog.addAppender(appender); Let us know how it goes. -- Ceki On 1/25/2017 8:20, Jan-Olav Eide wrote: [snip]
This does not work (it archives etc, but never any contents in the file) :
LoggerContext loggerContext = LoggerContext.class.cast(LoggerFactory.getILoggerFactory());
RollingFileAppender<IAccessEvent> appender = new RollingFileAppender<>(); appender.setName("REQUESTLOG"); appender.setFile("/bps/log/request/myrequest.log"); TimeBasedRollingPolicy<IAccessEvent> timePolicy = new TimeBasedRollingPolicy<>();
timePolicy.setFileNamePattern("/bps/log/archive/request/my_request_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip"); timePolicy.setContext(loggerContext); timePolicy.setMaxHistory(30); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(new StartupTimeBasedTriggeringPolicy<IAccessEvent>()); timePolicy.setParent(appender); appender.setRollingPolicy(timePolicy); appender.setTriggeringPolicy(timePolicy); PatternLayoutEncoder encoder = new PatternLayoutEncoder(); encoder.setPattern("combined"); appender.setEncoder(encoder); RequestLogImpl requestLog = new RequestLogImpl(); requestLog.addAppender(appender);
On 24 January 2017 at 22:04, Ceki Gülcü <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Hi Jan-Olav,
It's not possible to tell without seeing the code in question. Would you want to post it here?
-- Ceki
On 1/24/2017 19:43, Jan-Olav Eide wrote:
> Well, things worked much better with a logback-access.xml file rather > than a programmatic construction of the same configuration. Strange, > since the latter code works fine elsewhere.
That worked out of the box, thanks a lot four your help. I had missed the fact that the RequestLogImpl was in fact the context. On 25 January 2017 at 09:09, Ceki Gülcü <ceki@qos.ch> wrote:
LoggerContext is the context for logback-classic whereas RequestLogImpl *is* the context for logback-access+Jetty. You need to set requestLog (of type RequestLogImpl) as the context for components such as RollingFileAppender and TimeBasedRollingPolicy. By the way, all logback components must be started. Otherwise, they will not work.
As such, here a revised version which should work better. Beware, I have not tested this code and it may still contain some wrinkles. Without further ado here is the code:
RequestLogImpl requestLog = new RequestLogImpl(); // implements Context
ch.qos.logback.access.PatternLayoutEncoder encoder = new ch.qos.logback.access.PatternLayoutEncoder(); encoder.setContext(requestLog); encoder.setPattern("combined"); encoder.start(); // // components must be started
RollingFileAppender<IAccessEvent> appender = new RollingFileAppender<IAccessEvent>(); appender.setContext(requestLog); // requestLog is the context appender.setName("REQUESTLOG"); appender.setFile("/bps/log/request/myrequest.log"); appender.setEncoder(encoder);
TimeBasedRollingPolicy<IAccessEvent> timePolicy = new TimeBasedRollingPolicy<IAccessEvent>();
timePolicy.setFileNamePattern("/bps/log/archive/request/my_r equest_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip"); timePolicy.setContext(requestLog); // requestLog is the context timePolicy.setMaxHistory(30); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(new StartupTimeBasedTriggeringPolicy<IAccessEvent>()); timePolicy.setParent(appender); timePolicy.start(); // components must be started
appender.setRollingPolicy(timePolicy); appender.setTriggeringPolicy(timePolicy);
appender.start(); // // components must be started requestLog.addAppender(appender);
Let us know how it goes.
-- Ceki
On 1/25/2017 8:20, Jan-Olav Eide wrote:
[snip]
This does not work (it archives etc, but never any contents in the file) :
LoggerContext loggerContext = LoggerContext.class.cast(LoggerFactory.getILoggerFactory());
RollingFileAppender<IAccessEvent> appender = new
RollingFileAppender<>(); appender.setName("REQUESTLOG"); appender.setFile("/bps/log/request/myrequest.log"); TimeBasedRollingPolicy<IAccessEvent> timePolicy = new TimeBasedRollingPolicy<>();
timePolicy.setFileNamePattern("/bps/log/archive/request/my_r equest_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip"); timePolicy.setContext(loggerContext); timePolicy.setMaxHistory(30); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(new StartupTimeBasedTriggeringPolicy<IAccessEvent>()); timePolicy.setParent(appender); appender.setRollingPolicy(timePolicy); appender.setTriggeringPolicy(timePolicy); PatternLayoutEncoder encoder = new PatternLayoutEncoder(); encoder.setPattern("combined"); appender.setEncoder(encoder); RequestLogImpl requestLog = new RequestLogImpl(); requestLog.addAppender(appender);
On 24 January 2017 at 22:04, Ceki Gülcü <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Hi Jan-Olav,
It's not possible to tell without seeing the code in question. Would you want to post it here?
-- Ceki
On 1/24/2017 19:43, Jan-Olav Eide wrote:
> Well, things worked much better with a logback-access.xml file rather > than a programmatic construction of the same configuration. Strange, > since the latter code works fine elsewhere.
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Well, I cheered a bit too soon... handlers.addHandler(logbackInlinedRequestHandler()); handlers.addHandler(webappHandler(contextPath(), warURL())); This causes no data being available on the InputStream of the servlet inside the webapp. Reversing the order of the handler registrations causes nothing to be request-logged, Probably for the same reason, the data is consumed by the servlet. Should not the logback handler be non-invasive in that it should put the data back on the InputStream, or am I missing something here ? On 25 January 2017 at 09:50, Jan-Olav Eide <janolaveide@gmail.com> wrote:
That worked out of the box, thanks a lot four your help. I had missed the fact that the RequestLogImpl was in fact the context.
On 25 January 2017 at 09:09, Ceki Gülcü <ceki@qos.ch> wrote:
LoggerContext is the context for logback-classic whereas RequestLogImpl *is* the context for logback-access+Jetty. You need to set requestLog (of type RequestLogImpl) as the context for components such as RollingFileAppender and TimeBasedRollingPolicy. By the way, all logback components must be started. Otherwise, they will not work.
As such, here a revised version which should work better. Beware, I have not tested this code and it may still contain some wrinkles. Without further ado here is the code:
RequestLogImpl requestLog = new RequestLogImpl(); // implements Context
ch.qos.logback.access.PatternLayoutEncoder encoder = new ch.qos.logback.access.PatternLayoutEncoder(); encoder.setContext(requestLog); encoder.setPattern("combined"); encoder.start(); // // components must be started
RollingFileAppender<IAccessEvent> appender = new RollingFileAppender<IAccessEvent>(); appender.setContext(requestLog); // requestLog is the context appender.setName("REQUESTLOG"); appender.setFile("/bps/log/request/myrequest.log"); appender.setEncoder(encoder);
TimeBasedRollingPolicy<IAccessEvent> timePolicy = new TimeBasedRollingPolicy<IAccessEvent>();
timePolicy.setFileNamePattern("/bps/log/archive/request/my_r equest_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip"); timePolicy.setContext(requestLog); // requestLog is the context timePolicy.setMaxHistory(30); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(new StartupTimeBasedTriggeringPolicy<IAccessEvent>()); timePolicy.setParent(appender); timePolicy.start(); // components must be started
appender.setRollingPolicy(timePolicy); appender.setTriggeringPolicy(timePolicy);
appender.start(); // // components must be started requestLog.addAppender(appender);
Let us know how it goes.
-- Ceki
On 1/25/2017 8:20, Jan-Olav Eide wrote:
[snip]
This does not work (it archives etc, but never any contents in the file) :
LoggerContext loggerContext = LoggerContext.class.cast(LoggerFactory.getILoggerFactory());
RollingFileAppender<IAccessEvent> appender = new
RollingFileAppender<>(); appender.setName("REQUESTLOG"); appender.setFile("/bps/log/request/myrequest.log"); TimeBasedRollingPolicy<IAccessEvent> timePolicy = new TimeBasedRollingPolicy<>();
timePolicy.setFileNamePattern("/bps/log/archive/request/my_r equest_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip"); timePolicy.setContext(loggerContext); timePolicy.setMaxHistory(30); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(new StartupTimeBasedTriggeringPolicy<IAccessEvent>()); timePolicy.setParent(appender); appender.setRollingPolicy(timePolicy); appender.setTriggeringPolicy(timePolicy); PatternLayoutEncoder encoder = new PatternLayoutEncoder(); encoder.setPattern("combined"); appender.setEncoder(encoder); RequestLogImpl requestLog = new RequestLogImpl(); requestLog.addAppender(appender);
On 24 January 2017 at 22:04, Ceki Gülcü <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Hi Jan-Olav,
It's not possible to tell without seeing the code in question. Would you want to post it here?
-- Ceki
On 1/24/2017 19:43, Jan-Olav Eide wrote:
> Well, things worked much better with a logback-access.xml file rather > than a programmatic construction of the same configuration. Strange, > since the latter code works fine elsewhere.
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Got bitten by HandlerCollection vs HandlerList, which have different semantics. Works fine with a HandlerCollection. On 31 January 2017 at 13:56, Jan-Olav Eide <janolaveide@gmail.com> wrote:
Well, I cheered a bit too soon...
handlers.addHandler(logbackInlinedRequestHandler()); handlers.addHandler(webappHandler(contextPath(), warURL()));
This causes no data being available on the InputStream of the servlet inside the webapp. Reversing the order of the handler registrations causes nothing to be request-logged, Probably for the same reason, the data is consumed by the servlet.
Should not the logback handler be non-invasive in that it should put the data back on the InputStream, or am I missing something here ?
On 25 January 2017 at 09:50, Jan-Olav Eide <janolaveide@gmail.com> wrote:
That worked out of the box, thanks a lot four your help. I had missed the fact that the RequestLogImpl was in fact the context.
On 25 January 2017 at 09:09, Ceki Gülcü <ceki@qos.ch> wrote:
LoggerContext is the context for logback-classic whereas RequestLogImpl *is* the context for logback-access+Jetty. You need to set requestLog (of type RequestLogImpl) as the context for components such as RollingFileAppender and TimeBasedRollingPolicy. By the way, all logback components must be started. Otherwise, they will not work.
As such, here a revised version which should work better. Beware, I have not tested this code and it may still contain some wrinkles. Without further ado here is the code:
RequestLogImpl requestLog = new RequestLogImpl(); // implements Context
ch.qos.logback.access.PatternLayoutEncoder encoder = new ch.qos.logback.access.PatternLayoutEncoder(); encoder.setContext(requestLog); encoder.setPattern("combined"); encoder.start(); // // components must be started
RollingFileAppender<IAccessEvent> appender = new RollingFileAppender<IAccessEvent>(); appender.setContext(requestLog); // requestLog is the context appender.setName("REQUESTLOG"); appender.setFile("/bps/log/request/myrequest.log"); appender.setEncoder(encoder);
TimeBasedRollingPolicy<IAccessEvent> timePolicy = new TimeBasedRollingPolicy<IAccessEvent>();
timePolicy.setFileNamePattern("/bps/log/archive/request/my_r equest_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip"); timePolicy.setContext(requestLog); // requestLog is the context timePolicy.setMaxHistory(30); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(new StartupTimeBasedTriggeringPolicy<IAccessEvent>()); timePolicy.setParent(appender); timePolicy.start(); // components must be started
appender.setRollingPolicy(timePolicy); appender.setTriggeringPolicy(timePolicy);
appender.start(); // // components must be started requestLog.addAppender(appender);
Let us know how it goes.
-- Ceki
On 1/25/2017 8:20, Jan-Olav Eide wrote:
[snip]
This does not work (it archives etc, but never any contents in the file)
:
LoggerContext loggerContext = LoggerContext.class.cast(LoggerFactory.getILoggerFactory());
RollingFileAppender<IAccessEvent> appender = new
RollingFileAppender<>(); appender.setName("REQUESTLOG"); appender.setFile("/bps/log/request/myrequest.log"); TimeBasedRollingPolicy<IAccessEvent> timePolicy = new TimeBasedRollingPolicy<>();
timePolicy.setFileNamePattern("/bps/log/archive/request/my_r equest_%d{yyyy-MM-dd}_%d{HH_mm_ss,aux}.log.zip"); timePolicy.setContext(loggerContext); timePolicy.setMaxHistory(30); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(new StartupTimeBasedTriggeringPolicy<IAccessEvent>()); timePolicy.setParent(appender); appender.setRollingPolicy(timePolicy); appender.setTriggeringPolicy(timePolicy); PatternLayoutEncoder encoder = new PatternLayoutEncoder(); encoder.setPattern("combined"); appender.setEncoder(encoder); RequestLogImpl requestLog = new RequestLogImpl(); requestLog.addAppender(appender);
On 24 January 2017 at 22:04, Ceki Gülcü <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Hi Jan-Olav,
It's not possible to tell without seeing the code in question. Would you want to post it here?
-- Ceki
On 1/24/2017 19:43, Jan-Olav Eide wrote:
> Well, things worked much better with a logback-access.xml file rather > than a programmatic construction of the same configuration. Strange, > since the latter code works fine elsewhere.
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
participants (2)
-
Ceki Gülcü -
Jan-Olav Eide