-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to configure logback logger with env variables #8998
Conversation
|
||
String config = System.getenv("CHE_LOGGER_CONFIG"); | ||
if (config != null && !config.isEmpty()) { | ||
Arrays.stream(config.split(",")).map(String::trim).forEach(this::setLoggerLevel); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I understand RuntimeException will be thrown in a case when CHE_LOGGER_CONFIG
value has the wrong format. Am I right? If yes, maybe it would be better to catch it and log pretty message like 'CHE_LOGGER_CONFIG
env variable has the wrong format. It should be ...'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, AFAIK it would be just silently ignored. In fact, the same way if you put not existed classes or packages in logback.xml
import ch.qos.logback.core.spi.LifeCycle; | ||
import java.util.Arrays; | ||
|
||
public class EnvironmentVariablesLogLevelPropagator extends ContextAwareBase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add java doc
|
||
private boolean isStarted; | ||
|
||
private void setLoggerLevel(String loggerConfig) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would a bit better if a private method is placed under that one who invokes it
<artifactId>che-core-commons-logback</artifactId> | ||
<exclusions> | ||
<exclusion> | ||
<artifactId>che-core-api-core</artifactId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it excluded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to make sure ide war doesn't contain che-core-api-core and all it unnecessary dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a bit strange. It means that you're using classes from this dependency which don't use api-core
classes.
But somebody can easily use it, and then Runtime exception will occur.
It's just thought. I'm OK to leave it as it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why we need logback in IDE war at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sleshchenko about exclusion.
We already have che-core-commons-logback module. To avoid exclusion we need another module with only one single class. When I selecting this approach I thought it would be less confusing then to have two modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why we need logback in IDE war at all?
@garagatyi
Some filters are using slf4j-> logback logging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it is more convenient right now, but we will have to remember that this exclusion is needed. And other projects that would extend Che also would need to know about this exclusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would not be a problem soon. Since that is not a case for Theia.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok with this approach, just thinking out loud
public class EnvironmentVariablesLogLevelPropagator extends ContextAwareBase | ||
implements LoggerContextListener, LifeCycle { | ||
|
||
private boolean isStarted; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate on how it is used and why it should not be thread safe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is implemented in similar to ch.qos.logback.classic.jul.LevelChangePropagator way
I guess life cycle of this component is not multi-threaded.
} | ||
|
||
private void setLoggerLevel(String loggerConfig) { | ||
int i = loggerConfig.indexOf('='); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that call of split() would be clearer.
} | ||
String loggerName = loggerConfig.substring(0, i); | ||
String levelStr = loggerConfig.substring(i + 1); | ||
if (loggerName == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
substring
method never returns null, these null checks look like redundant. After removing them you'll be able to inline String loggerName = loggerConfig.substring(0, i).trim();
loggerName = loggerName.trim(); | ||
levelStr = levelStr.trim(); | ||
|
||
addInfo("Trying to set level " + levelStr + " to logger " + loggerName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it makes sense to check levelStr and loggerName variable on empty here? Or at least wrap them into '
to make it clear that they are empty.
<artifactId>che-core-commons-logback</artifactId> | ||
<exclusions> | ||
<exclusion> | ||
<artifactId>che-core-api-core</artifactId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a bit strange. It means that you're using classes from this dependency which don't use api-core
classes.
But somebody can easily use it, and then Runtime exception will occur.
It's just thought. I'm OK to leave it as it is.
} | ||
} | ||
|
||
public void stop() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stop
and isStarted
methods are not used. Can we just delete them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They come from the interface. I'm going to restore Override annotations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, then it would be clearer
} | ||
|
||
private void setLoggerLevel(String loggerConfig) { | ||
String[] parts = loggerConfig.split("="); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better to specify limit here
} | ||
String loggerName = parts[0]; | ||
String levelStr = parts[1]; | ||
if (loggerName == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When is it possible that parts array contains null values?
…with env variables
…logger with env variables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for contributing such feature.
Previously setting the log level to DEBUG just enabled chaos mode for logs. 😃
When it is possible to set the log level for a particular component, debug logs become useful.
if (parts.length < 2) { | ||
return; | ||
} | ||
String loggerName = parts[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it makes sense to trim values here
ci-test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Useful, make sure we add this info to documentation.
ci-test build report: |
Allow to configure logback logger with env variables (eclipse-che#8998)
What does this PR do?
Allow to configure logback logger with env variables
Example.
To be able to configure ws-master - a user will have to add this variable to che.env
In case of ws-agent - a user will have to add this variable to env configuration of the desired machine.
What issues does this PR fix or reference?
Fixes #8997
Depend on eclipse-che/che-lib#79
Release Notes
CHE_LOGGER_CONFIG environment variable is used to configure logback logger
Docs PR
eclipse-che/che-docs#369