March 2017 - logback-user - mailman3.qos.ch

Release of logback version 1.2.2
by Ceki Gülcü 16 Mar '17

16 Mar '17

Hello all, I am happy to announce the release of logback version 1.2.2. It contains bug fixes with no major changes. Note that the 1.2.x series offers significant performance improvements over the 1.1.x series. The 1.2.x series also fixes a rather severe serialization vulnerability in SocketServer and ServerSocketReceiver. Users running these components should upgrade immediately. Please refer to the news page for precise details. http://logback.qos.ch/news.html For review of performance figures, see: http://tinyurl.com/logbackPerf You can receive logback related announcements by subscribing to the QOS.ch announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce You may also receive announcements via twitter by following: https://twitter.com/qos_ch Enjoy, -- Ceki Gülcü

1 0

Lilith 8.1.0 has been released!
by Jörn Huxhorn 15 Mar '17

15 Mar '17

See http://lilithapp.com/releases/8.1.0.xhtml for detailed list of changes. Cheers, Huxi.

1 0

Does Logback v1.1.11 fix CVE-2017-5929?
by Alexander von Buchholtz 15 Mar '17

15 Mar '17

Hi, as I couldn't find any release notes/information about the logback release v1.1.11: does this release include the fix for CVE-2017-5929? Thanks, Alexander

2 2

Config doesn't work
by Donald McLean 15 Mar '17

15 Mar '17

The config shown below is creating the file, but nothing is writing to it, and some classes are not logging at all. Those that do log, it's all going to stdout. Obviously, I've done something stupid, but I can't figure out what. Here is some output from stdout that looks like it's from logback: Got 12 errors. INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set INFO in ch.qos.logback.core.joran.action.TimestampAction - Using current interpretation time, i.e. now, as time reference. INFO in ch.qos.logback.core.joran.action.TimestampAction - Adding property to the context with key="bySecond" and value="20170314T113135" to the LOCAL scope INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.FileAppender] INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [FILE] ERROR in ch.qos.logback.core.joran.spi.Interpreter@7:33 - no applicable action for [immediateFlush], current ElementPath is [[configuration][appender][immediateFlush]] INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property INFO in ch.qos.logback.core.FileAppender[FILE] - File property is set to [GraphDBTest-20170314T113135.log] INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to TRACE INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [FILE] to Logger[ROOT] INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration. INFO in ch.qos.logback.classic.joran.JoranConfigurator@13b6aecc - Registering current configuration as safe fallback point I would really appreciate a suggestion as to what I'm doing wrong. Thank you, Donald <configuration> <timestamp datePattern="yyyyMMdd'T'HHmmss" key="bySecond"/> <appender class="ch.qos.logback.core.FileAppender" name="FILE"> <file>GraphDBTest-${bySecond}.log</file> <immediateFlush>true</immediateFlush> <encoder> <pattern>%date %level [%thread] %logger{10} [%file:%line] %msg%n</pattern> </encoder> </appender> <root level="TRACE"> <appender-ref ref="FILE"/> </root> </configuration>

2 8

Re: [logback-user] Manifest Question
by Andrew Feller 13 Mar '17

13 Mar '17

Thanks for the feedback David, Adam! I actually am outfitting a variety of Java apps with the logstash-logback-encoder for storing logs in ELK / Elasticstack and was aiming to store implementation info in MDC so it would be available. Aside from the suggestions both of you offered, I had only 2 other ideas: 1. Have logback read maven-generated pom.properties under META-INF for version, artifactId, groupId 2. Create a custom context listener as described in StackOverflow question <http://stackoverflow.com/questions/1975939/read-environment-variables-from-…> that would figure out the main class and lookup it's implementation info Customizing the appender seems weird since it's concern is persisting log events to an external system (ELK, file, syslog, etc). On Sun, Mar 12, 2017 at 11:05 AM, <logback-user-request(a)qos.ch> wrote: > > Date: Sun, 12 Mar 2017 11:04:39 -0400 > From: Adam Gent <adam.gent(a)snaphop.com> > To: logback users list <logback-user(a)qos.ch> > Subject: Re: [logback-user] Manifest Question > Message-ID: > <CAG4f71u9ye=Uog0n5wUY-J3tDjdg6Tw67LoOVN8A6ODMxMy7eA@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > The appender way is the easiest way but there are bunch of caveats to that > method. We used to do it this way but needed more flexibility. > > If you are going to do it the custom Appender way I recommend not using the > MDC. You also can really only have pretty static attributes. > > For example for Spring MVC we actually add the routing path to the MDC and > thus the Appender would not be helpful. > > Yeah you could make a unified thread local context that your custom > appender uses but that is basically what the MDC is. > > There is also the tricky biz of handing of dynamic MDC information to child > threads. Again for example for every request we generate a uuid so that we > can track that request and everything it executes. > > But if your attributes are mainly static I agree that the custom appender > is the route to go.... I feel stupid for not mentioning it first. > > On Sun, Mar 12, 2017 at 8:51 AM, David Tkaczyk <davidtkaczyk69(a)gmail.com> > wrote: > > > Extend your preferred appender. > > > > On Mar 12, 2017 6:59 AM, <logback-user-request(a)qos.ch> wrote: > > > >> Send logback-user mailing list submissions to > >> logback-user(a)qos.ch > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> http://mailman.qos.ch/mailman/listinfo/logback-user > >> or, via email, send a message with subject or body 'help' to > >> logback-user-request(a)qos.ch > >> > >> You can reach the person managing the list at > >> logback-user-owner(a)qos.ch > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of logback-user digest..." > >> > >> Today's Topics: > >> > >> 1. Recommendations on including manifest implementation > >> information into logging events (Andrew Feller) > >> > >> > >> ---------- Forwarded message ---------- > >> From: Andrew Feller <afeller(a)bandwidth.com> > >> To: logback-user(a)qos.ch > >> Cc: > >> Bcc: > >> Date: Sat, 11 Mar 2017 14:59:35 -0500 > >> Subject: [logback-user] Recommendations on including manifest > >> implementation information into logging events > >> Does anyone have recommendations on how to best to add manifest > >> implementation information (Implementation-Title, > Implementation-Version, > >> etc) to logback MDC trivially? > >> > >> I know this information can retrieved programmatically from a package ( > >> Package.getImplementationTitle() > >> <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html# > getImplementationTitle-->, > >> Package.getImplementationVersion() > >> <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html# > getImplementationVersion-->, > >> etc), but I'd rather avoid having every application hardcode logic on > >> startup to determine this and stash it in MDC for later use. I would > also > >> like to avoid hard coding this information within logback.xml / > >> logback-spring.xml as the manifest is the source of truth. > >> > >> Any recommendations would be greatly appreciated! > >> -- > >> > >> [image: email-signature-logo.jpg] > >> > >> *Andy Feller* > >> > >> Sr. DevOps Engineer > >> 900 Main Campus Drive, Suite 500 > >> > >> Raleigh, NC 27606 > >> > >> Bandwidth <http://www.bandwidth.com/> > >> <http://www.bandwidth.com/>e afeller(a)bandwidth.com > >> > >> _______________________________________________ > >> logback-user mailing list > >> logback-user(a)qos.ch > >> http://mailman.qos.ch/mailman/listinfo/logback-user > >> > > > > _______________________________________________ > > logback-user mailing list > > logback-user(a)qos.ch > > http://mailman.qos.ch/mailman/listinfo/logback-user > > > > > > -- > CTO > SnapHop (snaphop.com) > (twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt (cell) > 781-883-5182 >

2 1

Manifest Question
by David Tkaczyk 12 Mar '17

12 Mar '17

Extend your preferred appender. On Mar 12, 2017 6:59 AM, <logback-user-request(a)qos.ch> wrote: > Send logback-user mailing list submissions to > logback-user(a)qos.ch > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.qos.ch/mailman/listinfo/logback-user > or, via email, send a message with subject or body 'help' to > logback-user-request(a)qos.ch > > You can reach the person managing the list at > logback-user-owner(a)qos.ch > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of logback-user digest..." > > Today's Topics: > > 1. Recommendations on including manifest implementation > information into logging events (Andrew Feller) > > > ---------- Forwarded message ---------- > From: Andrew Feller <afeller(a)bandwidth.com> > To: logback-user(a)qos.ch > Cc: > Bcc: > Date: Sat, 11 Mar 2017 14:59:35 -0500 > Subject: [logback-user] Recommendations on including manifest > implementation information into logging events > Does anyone have recommendations on how to best to add manifest > implementation information (Implementation-Title, Implementation-Version, > etc) to logback MDC trivially? > > I know this information can retrieved programmatically from a package ( > Package.getImplementationTitle() > <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html#getImpleme…>, > Package.getImplementationVersion() > <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html#getImpleme…>, > etc), but I'd rather avoid having every application hardcode logic on > startup to determine this and stash it in MDC for later use. I would also > like to avoid hard coding this information within logback.xml / > logback-spring.xml as the manifest is the source of truth. > > Any recommendations would be greatly appreciated! > -- > > [image: email-signature-logo.jpg] > > *Andy Feller* > > Sr. DevOps Engineer > 900 Main Campus Drive, Suite 500 > > Raleigh, NC 27606 > > Bandwidth <http://www.bandwidth.com/> > <http://www.bandwidth.com/>e afeller(a)bandwidth.com > > _______________________________________________ > logback-user mailing list > logback-user(a)qos.ch > http://mailman.qos.ch/mailman/listinfo/logback-user >

2 1

Recommendations on including manifest implementation information into logging events
by Andrew Feller 12 Mar '17

12 Mar '17

Does anyone have recommendations on how to best to add manifest implementation information (Implementation-Title, Implementation-Version, etc) to logback MDC trivially? I know this information can retrieved programmatically from a package ( Package.getImplementationTitle() <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html#getImpleme…>, Package.getImplementationVersion() <https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html#getImpleme…>, etc), but I'd rather avoid having every application hardcode logic on startup to determine this and stash it in MDC for later use. I would also like to avoid hard coding this information within logback.xml / logback-spring.xml as the manifest is the source of truth. Any recommendations would be greatly appreciated! -- [image: email-signature-logo.jpg] *Andy Feller* Sr. DevOps Engineer 900 Main Campus Drive, Suite 500 Raleigh, NC 27606 Bandwidth <http://www.bandwidth.com/> <http://www.bandwidth.com/>e afeller(a)bandwidth.com

2 1