Replies: 3 comments 2 replies
-
@ziomill Thank you for this detailed description. Are the CONTAINER_NAMESPACE, CONTAINER_NAME and CONTAINER_IMAGE_VERSION mutually exclusive or mostly independent? For example, can they all be defined simultaneously? |
Beta Was this translation helpful? Give feedback.
-
Hi @ceki , The properties are independent. Anyway, I could avoid using nested IF in the appender if the logback library would allow me to evaluate ENV variables to null (or to an empty string) when they are not provided, so that I can configure something this: ....
....
<pattern>
<omitEmptyFields>true</omitEmptyFields>
<pattern>
{
"Resource": {"container-namespace":"${CONTAINER_NAMESPACE:-}"}
}
</pattern>
</pattern>
....
.... However logback evaluates not provided ENV variables to "_IS_UNDEFINED" and I can't rely on the The problem, which is related to this logback issue, has been explained with details here Any help would be appreciated |
Beta Was this translation helpful? Give feedback.
-
I think the following should do the trick:
|
Beta Was this translation helpful? Give feedback.
-
Hi all,
I'm upgrading from logback 1.2 to 1.4.
Our logback config has some IF nested into the APPENDER and, as described here, it seems that from the logback 1.3 version, this configuration is disallowed:
As you can see, we have to add some JSON properties to a log's record, only if some ENV variables have been provided.
I tried using the "surrounding-if form" as suggested, but the original appender is completely overwritten by the last IF which evaluates to TRUE:
For example, if I provide the CONTAINER_NAME env property, the printed log is:
How to reach the same result according to the new rules?
Thank you
Beta Was this translation helpful? Give feedback.
All reactions