We do this for all of our services. What I recommend is having some bootstrap code that gets that information and sets it as a System.properties. The bootstrap code *needs to run before any logging code* which for some frameworks can be nontrivial due to the static initialization of SLF4J (and SLF4J should really have some way to intercept the initial binding but that would probably hurt startup performance). If you have control of the entry point (e.g. static main(args)) you can put the code in there. Again it needs to be done before any call to LoggingFactory.getLogger() If you have a servlet container you can use a context listener and register that listener before all other listeners (otherwise logging code might be executed before bootstrap). However this only works if your servlet container does not use SLF4J or Logback (most of them have their own logging framework but if you configure them to use Logback you won't be able to set the properties apriori). Logback (and almost all logging frameworks for that matter) allow you to get access to the system properties for output but they won't be in the MDC. To inject the properties into the MDC for your entire application is extremely specific to the framework you are using. Basically you need to go find where threads are created or an entrypoint. You also need to cleanup your MDC once the thread is released. For Spring MVC this could be done by subclassing the DispatcherServlet. For other things you can make a custom ExecutorService and put the required MDC logic and wire your custom ExecutorService in. As you can see it is pretty nontrivial to do all of this but I will put a silver lining in that it is totally worth if you use something like the ELK stack (google it) or the commercial Splunk or the plethora of logging SaaS services. These days other than during development file based logging is completely dead to me. It is so powerful to search by MDC attributes in ELK and resolve issues. On Sat, Mar 11, 2017 at 2:59 PM, Andrew Feller <afeller@bandwidth.com> wrote:

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@bandwidth.com

_______________________________________________ logback-user mailing list logback-user@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