Configuring properties via XML

The Layout chapter indicates it supports property value retrieval via %property{key} and states that the logging context is where one might put a property (along w/ System properties). I believe log4j did this w/ the <param name="key_name" value="some_value"> element in the <appender> and referenced it via %properties{key_name}. I'm not seeing how to do this in Logback in XML. Would it go in the <logger> element? What's the syntax? Could someone please point me to the relevant section in the appropriate chapter of the manual? Thanks, --adam http://gordonizer.com

Please see [1] in the docs. For your use case, you need to define the property in the context scope [2]. [1] http://logback.qos.ch/manual/configuration.html#variableSubstitution [2] http://logback.qos.ch/manual/configuration.html#scopes On 08.11.2012 18:54, Adam Gordon wrote:
The Layout chapter indicates it supports property value retrieval via %property{key} and states that the logging context is where one might put a property (along w/ System properties). I believe log4j did this w/ the <param name="key_name" value="some_value"> element in the <appender> and referenced it via %properties{key_name}.
I'm not seeing how to do this in Logback in XML. Would it go in the <logger> element? What's the syntax? Could someone please point me to the relevant section in the appropriate chapter of the manual?
Thanks,
--adam
-- Ceki http://twitter.com/#!/ceki

Ok, I really should have thought about what I really needed before posting. We have a "parent" GWT web application and we have children applications that are plugged into it. The children can run as standalone web applications but this is really only for development. Since each child can run independently, each has its own logback.xml file. Unfortunately, when the parent is built, the children are just JAR file dependencies and the parent also has it's own logback.xml file. Using only the parent's logback.xml file, we can configure different appenders (and thus different log files) for each of the children, but this only works because of the child namespacing (the Java package name). The parent's logback.xml defines the root logger to use the parent's appender. What this means is that if the children are using a common framework, say Spring, all the Spring logging doesn't go into the correct child's logfile, but rather the parent's. What we need is a way to either allow each child it's own, completely separate logging configuration or we need to "tag" the logging statement in the parent's log file with some name that indicates which child the message came from. I was looking at the concept of a context selector, but it wasn't clear how I'd be able to configure this to return the correct LoggingContext depending on which child issued the logging statement. Alternatively, I suppose I could add a filter which "sets" the current logging context based on the request URI - the children's request URIs are also namespaced so that each child's request URI always starts with /child_name/... Was this clear? Do anyone have any thoughts on how best to approach this problem? Thanks, --adam http://gordonizer.com On Thu, Nov 8, 2012 at 11:01 AM, ceki <ceki@qos.ch> wrote:
Please see [1] in the docs. For your use case, you need to define the property in the context scope [2].
[1] http://logback.qos.ch/manual/**configuration.html#** variableSubstitution<http://logback.qos.ch/manual/configuration.html#variableSubstitution> [2] http://logback.qos.ch/manual/**configuration.html#scopes<http://logback.qos.ch/manual/configuration.html#scopes>
On 08.11.2012 18:54, Adam Gordon wrote:
The Layout chapter indicates it supports property value retrieval via %property{key} and states that the logging context is where one might put a property (along w/ System properties). I believe log4j did this w/ the <param name="key_name" value="some_value"> element in the <appender> and referenced it via %properties{key_name}.
I'm not seeing how to do this in Logback in XML. Would it go in the <logger> element? What's the syntax? Could someone please point me to the relevant section in the appropriate chapter of the manual?
Thanks,
--adam
-- Ceki http://twitter.com/#!/ceki ______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>

Have you looked at SiftingAppender [1]? If you can set an MDC variable at the beginning of a request served by each child app, the results should be rather close to what you are aiming. Give it a try. [1] http://logback.qos.ch/manual/appenders.html#SiftingAppender On 08.11.2012 19:54, Adam Gordon wrote:
Ok, I really should have thought about what I really needed before posting.
We have a "parent" GWT web application and we have children applications that are plugged into it. The children can run as standalone web applications but this is really only for development. Since each child can run independently, each has its own logback.xml file.
Unfortunately, when the parent is built, the children are just JAR file dependencies and the parent also has it's own logback.xml file.
Using only the parent's logback.xml file, we can configure different appenders (and thus different log files) for each of the children, but this only works because of the child namespacing (the Java package name). The parent's logback.xml defines the root logger to use the parent's appender. What this means is that if the children are using a common framework, say Spring, all the Spring logging doesn't go into the correct child's logfile, but rather the parent's.
What we need is a way to either allow each child it's own, completely separate logging configuration or we need to "tag" the logging statement in the parent's log file with some name that indicates which child the message came from.
I was looking at the concept of a context selector, but it wasn't clear how I'd be able to configure this to return the correct LoggingContext depending on which child issued the logging statement.
Alternatively, I suppose I could add a filter which "sets" the current logging context based on the request URI - the children's request URIs are also namespaced so that each child's request URI always starts with /child_name/...
Was this clear? Do anyone have any thoughts on how best to approach this problem?
Thanks,
--adam
On Thu, Nov 8, 2012 at 11:01 AM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Please see [1] in the docs. For your use case, you need to define the property in the context scope [2].
[1] http://logback.qos.ch/manual/__configuration.html#__variableSubstitution <http://logback.qos.ch/manual/configuration.html#variableSubstitution> [2] http://logback.qos.ch/manual/__configuration.html#scopes <http://logback.qos.ch/manual/configuration.html#scopes>
On 08.11.2012 18:54, Adam Gordon wrote:
The Layout chapter indicates it supports property value retrieval via %property{key} and states that the logging context is where one might put a property (along w/ System properties). I believe log4j did this w/ the <param name="key_name" value="some_value"> element in the <appender> and referenced it via %properties{key_name}.
I'm not seeing how to do this in Logback in XML. Would it go in the <logger> element? What's the syntax? Could someone please point me to the relevant section in the appropriate chapter of the manual?
Thanks,
--adam
-- Ceki 65% of statistics are made up on the spot

I was able to get this working using the SiftingAppender. Thanks! My request filter pulls the child app name from the URI and sets the MDC variable which yields the appropriate behavior of Spring logging to the correct log files. One final question: is this going to be subject to race conditions? If user A is using child app A at the same time as user B is using child app B, they're going to go through the same request filter so it's feasible that A's value gets set and that thread goes to do some intensive business logic (which let's say has a bunch of logging), B's thread comes in and changes the value, will A's thread suddenly switch log files? I guess the real question is when does the SiftingAppender query MDC for the value and when does it update it for the nested <appender>? --adam http://gordonizer.com On Thu, Nov 8, 2012 at 2:27 PM, ceki <ceki@qos.ch> wrote:
Have you looked at SiftingAppender [1]? If you can set an MDC variable at the beginning of a request served by each child app, the results should be rather close to what you are aiming. Give it a try.
On 08.11.2012 19:54, Adam Gordon wrote:
Ok, I really should have thought about what I really needed before posting.
We have a "parent" GWT web application and we have children applications that are plugged into it. The children can run as standalone web applications but this is really only for development. Since each child can run independently, each has its own logback.xml file.
Unfortunately, when the parent is built, the children are just JAR file dependencies and the parent also has it's own logback.xml file.
Using only the parent's logback.xml file, we can configure different appenders (and thus different log files) for each of the children, but this only works because of the child namespacing (the Java package name). The parent's logback.xml defines the root logger to use the parent's appender. What this means is that if the children are using a common framework, say Spring, all the Spring logging doesn't go into the correct child's logfile, but rather the parent's.
What we need is a way to either allow each child it's own, completely separate logging configuration or we need to "tag" the logging statement in the parent's log file with some name that indicates which child the message came from.
I was looking at the concept of a context selector, but it wasn't clear how I'd be able to configure this to return the correct LoggingContext depending on which child issued the logging statement.
Alternatively, I suppose I could add a filter which "sets" the current logging context based on the request URI - the children's request URIs are also namespaced so that each child's request URI always starts with /child_name/...
Was this clear? Do anyone have any thoughts on how best to approach this problem?
Thanks,
--adam
On Thu, Nov 8, 2012 at 11:01 AM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>>
wrote:
Please see [1] in the docs. For your use case, you need to define the property in the context scope [2].
[1] http://logback.qos.ch/manual/_**_configuration.html#__** variableSubstitution<http://logback.qos.ch/manual/__configuration.html#__variableSubstitution> <http://logback.qos.ch/manual/**configuration.html#** variableSubstitution<http://logback.qos.ch/manual/configuration.html#variableSubstitution>
On 08.11.2012 18:54, Adam Gordon wrote:
The Layout chapter indicates it supports property value retrieval via %property{key} and states that the logging context is where one might put a property (along w/ System properties). I believe log4j did this w/ the <param name="key_name" value="some_value"> element in the <appender> and referenced it via %properties{key_name}.
I'm not seeing how to do this in Logback in XML. Would it go in the <logger> element? What's the syntax? Could someone please point me to the relevant section in the appropriate chapter of the manual?
Thanks,
--adam
-- Ceki 65% of statistics are made up on the spot
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>

Regarding race conditions, note that the MDC manages contextual information on a per thread basis [1]. [1] http://logback.qos.ch/manual/mdc.html On 09.11.2012 01:42, Adam Gordon wrote:
I was able to get this working using the SiftingAppender. Thanks! My request filter pulls the child app name from the URI and sets the MDC variable which yields the appropriate behavior of Spring logging to the correct log files.
One final question: is this going to be subject to race conditions? If user A is using child app A at the same time as user B is using child app B, they're going to go through the same request filter so it's feasible that A's value gets set and that thread goes to do some intensive business logic (which let's say has a bunch of logging), B's thread comes in and changes the value, will A's thread suddenly switch log files?
I guess the real question is when does the SiftingAppender query MDC for the value and when does it update it for the nested <appender>?
--adam
On Thu, Nov 8, 2012 at 2:27 PM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Have you looked at SiftingAppender [1]? If you can set an MDC variable at the beginning of a request served by each child app, the results should be rather close to what you are aiming. Give it a try.
[1] http://logback.qos.ch/manual/__appenders.html#SiftingAppender <http://logback.qos.ch/manual/appenders.html#SiftingAppender>
On 08.11.2012 19:54, Adam Gordon wrote:
Ok, I really should have thought about what I really needed before posting.
We have a "parent" GWT web application and we have children applications that are plugged into it. The children can run as standalone web applications but this is really only for development. Since each child can run independently, each has its own logback.xml file.
Unfortunately, when the parent is built, the children are just JAR file dependencies and the parent also has it's own logback.xml file.
Using only the parent's logback.xml file, we can configure different appenders (and thus different log files) for each of the children, but this only works because of the child namespacing (the Java package name). The parent's logback.xml defines the root logger to use the parent's appender. What this means is that if the children are using a common framework, say Spring, all the Spring logging doesn't go into the correct child's logfile, but rather the parent's.
What we need is a way to either allow each child it's own, completely separate logging configuration or we need to "tag" the logging statement in the parent's log file with some name that indicates which child the message came from.
I was looking at the concept of a context selector, but it wasn't clear how I'd be able to configure this to return the correct LoggingContext depending on which child issued the logging statement.
Alternatively, I suppose I could add a filter which "sets" the current logging context based on the request URI - the children's request URIs are also namespaced so that each child's request URI always starts with /child_name/...
Was this clear? Do anyone have any thoughts on how best to approach this problem?
Thanks,
--adam
On Thu, Nov 8, 2012 at 11:01 AM, ceki <ceki@qos.ch <mailto:ceki@qos.ch> <mailto:ceki@qos.ch <mailto:ceki@qos.ch>>>
wrote:
Please see [1] in the docs. For your use case, you need to define the property in the context scope [2].
[1] http://logback.qos.ch/manual/____configuration.html#____variableSubstitution <http://logback.qos.ch/manual/__configuration.html#__variableSubstitution>
<http://logback.qos.ch/manual/__configuration.html#__variableSubstitution <http://logback.qos.ch/manual/configuration.html#variableSubstitution>> [2] http://logback.qos.ch/manual/____configuration.html#scopes <http://logback.qos.ch/manual/__configuration.html#scopes>
<http://logback.qos.ch/manual/__configuration.html#scopes <http://logback.qos.ch/manual/configuration.html#scopes>>
On 08.11.2012 18:54, Adam Gordon wrote:
The Layout chapter indicates it supports property value retrieval via %property{key} and states that the logging context is where one might put a property (along w/ System properties). I believe log4j did this w/ the <param name="key_name" value="some_value"> element in the <appender> and referenced it via %properties{key_name}.
I'm not seeing how to do this in Logback in XML. Would it go in the <logger> element? What's the syntax? Could someone please point me to the relevant section in the appropriate chapter of the manual?
Thanks,
--adam
-- Ceki 65% of statistics are made up on the spot
-- Ceki 65% of statistics are made up on the spot

Gah! Bitten by RTFM again...thanks for the assistance. --adam http://gordonizer.com On Fri, Nov 9, 2012 at 12:02 AM, ceki <ceki@qos.ch> wrote:
Regarding race conditions, note that the MDC manages contextual information on a per thread basis [1].
[1] http://logback.qos.ch/manual/**mdc.html<http://logback.qos.ch/manual/mdc.html>
On 09.11.2012 01:42, Adam Gordon wrote:
I was able to get this working using the SiftingAppender. Thanks! My request filter pulls the child app name from the URI and sets the MDC variable which yields the appropriate behavior of Spring logging to the correct log files.
One final question: is this going to be subject to race conditions? If user A is using child app A at the same time as user B is using child app B, they're going to go through the same request filter so it's feasible that A's value gets set and that thread goes to do some intensive business logic (which let's say has a bunch of logging), B's thread comes in and changes the value, will A's thread suddenly switch log files?
I guess the real question is when does the SiftingAppender query MDC for the value and when does it update it for the nested <appender>?
--adam
On Thu, Nov 8, 2012 at 2:27 PM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>>
wrote:
Have you looked at SiftingAppender [1]? If you can set an MDC variable at the beginning of a request served by each child app, the results should be rather close to what you are aiming. Give it a try.
On 08.11.2012 19:54, Adam Gordon wrote:
Ok, I really should have thought about what I really needed before posting.
We have a "parent" GWT web application and we have children applications that are plugged into it. The children can run as standalone web applications but this is really only for development. Since each child can run independently, each has its own logback.xml file.
Unfortunately, when the parent is built, the children are just JAR file dependencies and the parent also has it's own logback.xml file.
Using only the parent's logback.xml file, we can configure different appenders (and thus different log files) for each of the children, but this only works because of the child namespacing (the Java package name). The parent's logback.xml defines the root logger to use the parent's appender. What this means is that if the children are using a common framework, say Spring, all the Spring logging doesn't go into the correct child's logfile, but rather the parent's.
What we need is a way to either allow each child it's own, completely separate logging configuration or we need to "tag" the logging statement in the parent's log file with some name that indicates which child the message came from.
I was looking at the concept of a context selector, but it wasn't clear how I'd be able to configure this to return the correct LoggingContext depending on which child issued the logging statement.
Alternatively, I suppose I could add a filter which "sets" the current logging context based on the request URI - the children's request URIs are also namespaced so that each child's request URI always starts with /child_name/...
Was this clear? Do anyone have any thoughts on how best to approach this problem?
Thanks,
--adam
On Thu, Nov 8, 2012 at 11:01 AM, ceki <ceki@qos.ch <mailto:ceki@qos.ch> <mailto:ceki@qos.ch <mailto:ceki@qos.ch>>>
wrote:
Please see [1] in the docs. For your use case, you need to define the property in the context scope [2].
[1] http://logback.qos.ch/manual/_**___configuration.html#____** variableSubstitution<http://logback.qos.ch/manual/____configuration.html#____variableSubstitution> <http://logback.qos.ch/manual/**__configuration.html#__** variableSubstitution<http://logback.qos.ch/manual/__configuration.html#__variableSubstitution>
<http://logback.qos.ch/manual/**__configuration.html#__** variableSubstitution<http://logback.qos.ch/manual/__configuration.html#__variableSubstitution> <http://logback.qos.ch/manual/**configuration.html#** variableSubstitution<http://logback.qos.ch/manual/configuration.html#variableSubstitution>
[2] http://logback.qos.ch/manual/_**___configuration.html#scopes<http://logback.qos.ch/manual/____configuration.html#scopes> <http://logback.qos.ch/manual/**__configuration.html#scopes<http://logback.qos.ch/manual/__configuration.html#scopes>
<http://logback.qos.ch/manual/**__configuration.html#scopes<http://logback.qos.ch/manual/__configuration.html#scopes> <http://logback.qos.ch/manual/**configuration.html#scopes<http://logback.qos.ch/manual/configuration.html#scopes>
On 08.11.2012 18:54, Adam Gordon wrote:
The Layout chapter indicates it supports property value retrieval via %property{key} and states that the logging context is where one might put a property (along w/ System properties). I believe log4j did this w/ the <param name="key_name" value="some_value"> element in the <appender> and referenced it via %properties{key_name}.
I'm not seeing how to do this in Logback in XML. Would it go in the <logger> element? What's the syntax? Could someone please point me to the relevant section in the appropriate chapter of the manual?
Thanks,
--adam
-- Ceki 65% of statistics are made up on the spot
-- Ceki 65% of statistics are made up on the spot ______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
participants (2)
-
Adam Gordon
-
ceki