Hi Ralph, Thanks for the information, I was also thinking about writing some custom code to insert the value in the MDC myself, but I was hoping this might be supported out-of-the-box :) Since the value really is application-wide, it makes more sense to me as something to be configured in logback.xml... I was thinking of writing a custom filter that does nothing but set this value in the MDC, but that seems a little wasteful. Regards, -- Hauke D rgoers wrote:

In my organization we use a mechanism very similar to that shown in http://www.slf4j.org/extensions.html#event_logger . SLF4J doesn't provide standard key names or methods for common fields, but you can easily create a wrapper of the MDC to do this. We have a class called RequestContext that does exactly that. All our applications use that class to access the data in the MDC.

Ralph

-- View this message in context: http://www.nabble.com/SocketAppender-application-property-tp25009895p2502852... Sent from the Logback User mailing list archive at Nabble.com.

Hello Hauke, For application-wide values, you don't need to use MDC. Logback offers a better suited alternative in the form of context properties. Every logger is attached to a context, you can obtain it as: LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); you can then write: lc.putProperty("key", "val"); Context properties can also be set via configuration files. See http://logback.qos.ch/manual/configuration.html#variableSubstitution Moreover, every logging event generated by logback will contain the properties contained in the context, i.e. they are available to all appenders. Context information is also serialized with each outgoing logging event. If you are only interested in setting the name of the application, you can set the name of the context in the configuration file. See http://logback.qos.ch/manual/configuration.html#contextName The %contextName conversion word in PatternLayout will output the name of the logger context. I think the above meets the requirements you mentioned, doesn't it? HTH, haukex wrote:

Hi Ralph,

Thanks for the information, I was also thinking about writing some custom code to insert the value in the MDC myself, but I was hoping this might be supported out-of-the-box :) Since the value really is application-wide, it makes more sense to me as something to be configured in logback.xml... I was thinking of writing a custom filter that does nothing but set this value in the MDC, but that seems a little wasteful.

Regards, -- Hauke D

rgoers wrote:

...

In my organization we use a mechanism very similar to that shown in http://www.slf4j.org/extensions.html#event_logger . SLF4J doesn't provide standard key names or methods for common fields, but you can easily create a wrapper of the MDC to do this. We have a class called RequestContext that does exactly that. All our applications use that class to access the data in the MDC.

Ralph

-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

Ralph Goers wrote:

Out of curiosity, why does ILoggingEvent reference LoggerContextVO? I would have thought you would have created an interface named ILoggerContext and had the ILoggingEvent interface reference that instead of a concrete implementation.

LoggerContextVO is a value only version of LoggerContext. These two classes do not share a common interface nor ancestry. (They are just too different.) -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

Hi Ceki, Thanks for this information! I just tested things out and am having some problems. I added "<contextName>TestClient</contextName>" to the client's logback.xml and "<contextName>LoggingServer</contextName>" to the server's logback.xml. However, when I used %contextName in the PatternLayout on the server, I am seeing "LoggingServer" being output in the log file instead of "TestClient", so it seems this information is not serialized? Also, I tried setting <property name="LOGGING_CLIENT" value="TestClient" /> on the client (is this the right way to set LoggerContext properties?), and then using ${LOGGING_CLIENT} in the PatternLayout on the server, but I am getting "LOGGING_CLIENT_IS_UNDEFINED" output in the server log. When I set the same property on the server, the value is output. What am I doing wrong? :) Thanks, -- Hauke D Ceki Gulcu wrote:

Hello Hauke,

For application-wide values, you don't need to use MDC. Logback offers a better suited alternative in the form of context properties. Every logger is attached to a context, you can obtain it as:

LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();

you can then write:

lc.putProperty("key", "val");

Context properties can also be set via configuration files. See http://logback.qos.ch/manual/configuration.html#variableSubstitution

Moreover, every logging event generated by logback will contain the properties contained in the context, i.e. they are available to all appenders. Context information is also serialized with each outgoing logging event.

If you are only interested in setting the name of the application, you can set the name of the context in the configuration file. See http://logback.qos.ch/manual/configuration.html#contextName

The %contextName conversion word in PatternLayout will output the name of the logger context.

I think the above meets the requirements you mentioned, doesn't it?

HTH,

-- View this message in context: http://www.nabble.com/SocketAppender-application-property-tp25009895p2506005... Sent from the Logback User mailing list archive at Nabble.com.

Hi Ceki, Thanks for opening the issue! Do you have an estimate to when this could be fixed? Thanks also for the ContextPropertyConverter, I will test that now. Will this be included in the next release? Regards, -- Hauke D Ceki Gulcu wrote:

haukex wrote:

...

Hi Ceki,

Thanks for this information! I just tested things out and am having some problems.

I added "<contextName>TestClient</contextName>" to the client's logback.xml and "<contextName>LoggingServer</contextName>" to the server's logback.xml. However, when I used %contextName in the PatternLayout on the server, I am seeing "LoggingServer" being output in the log file instead of "TestClient", so it seems this information is not serialized?

It's a bug in ContextNameConverter. Instead of reading the context name found in the event passed as parameter, it used the context to which it (the ContextNameConverter instance) is attached to. Usually, the context found in the event and the context the ContextNameConverter instance is attached to are the same. One exception occurs when the event is sent to a remote system. Anyway, I entered a jira issue for this: http://jira.qos.ch/browse/LBCLASSIC-149

...

Also, I tried setting <property name="LOGGING_CLIENT" value="TestClient" /> on the client (is this the right way to set LoggerContext properties?), and then using ${LOGGING_CLIENT} in the PatternLayout on the server, but I am getting "LOGGING_CLIENT_IS_UNDEFINED" output in the server log. When I set the same property on the server, the value is output.

There is no converter to display the value of a context parameter. However, it should be fairly easy to write one. Here is a possible implementation:

package apackage.of.yr.choice;

import java.util.Map;

import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.classic.spi.LoggerContextVO;

public final class ContextPropertyConverter extends ClassicConverter {

String propertyName;

public void start() { String optStr = getFirstOption(); if (optStr != null) { propertyName = optStr; super.start(); } }

public String convert(ILoggingEvent event) { if(propertyName == null) { return "ContextProperty_HAS_NO_NAME"; } else { LoggerContextVO lcvo = event.getLoggerContextVO(); Map<String, String> map = lcvo.getPropertyMap(); return map.get(propertyName); } } }

Since ContextPropertyConverter does not exist in the current logback release (0.9.17), you need to inform logback of its existence. See the http://logback.qos.ch/manual/layouts.html and the section entitled "Creating a custom conversion specifier". You would need to add a conversion rule element similar to the following in your configuration file:

<conversionRule conversionWord="property"

converterClass="apackage.of.yr.choice.ContextPropertyConverter" />

I hope this helps. By the way, you would need to add ContextPropertyConverter.class onto your class path.

-- View this message in context: http://www.nabble.com/SocketAppender-application-property-tp25009895p2506559... Sent from the Logback User mailing list archive at Nabble.com.

Okay, thanks for the information. -- Hauke D Ceki Gulcu wrote:

haukex wrote:

...

Hi Ceki,

Thanks for opening the issue! Do you have an estimate to when this could be fixed?

Not really.

...

Thanks also for the ContextPropertyConverter, I will test that now. Will this be included in the next release?

It is already included in the master branch on git.

-- View this message in context: http://www.nabble.com/SocketAppender-application-property-tp25009895p2507612... Sent from the Logback User mailing list archive at Nabble.com.