Skip to content
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

Merged
merged 7 commits into from
Mar 7, 2018

Conversation

skabashnyuk
Copy link
Contributor

@skabashnyuk skabashnyuk commented Mar 3, 2018

What does this PR do?

Allow to configure logback logger with env variables
Example.

CHE_LOGGER_CONFIG=org.eclipse.che=DEBUG,org.eclipse.che.api.installer.server.impl.LocalInstallerRegistry=OFF 

To be able to configure ws-master - a user will have to add this variable to che.env
2018-03-03 09 42 00

In case of ws-agent - a user will have to add this variable to env configuration of the desired machine.
2018-03-02 15 36 28

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

@skabashnyuk skabashnyuk requested a review from riuvshin as a code owner March 3, 2018 07:39
@benoitf benoitf added status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. kind/task Internal things, technical debt, and to-do tasks to be performed. labels Mar 3, 2018

String config = System.getenv("CHE_LOGGER_CONFIG");
if (config != null && !config.isEmpty()) {
Arrays.stream(config.split(",")).map(String::trim).forEach(this::setLoggerLevel);
Copy link
Member

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 ...'

Copy link
Contributor Author

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
Copy link
Member

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) {
Copy link
Member

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>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it excluded?

Copy link
Contributor Author

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.

Copy link
Member

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.

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

@skabashnyuk skabashnyuk Mar 3, 2018

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.

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.

Copy link
Contributor Author

@skabashnyuk skabashnyuk Mar 3, 2018

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.

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;

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?

Copy link
Contributor Author

@skabashnyuk skabashnyuk Mar 3, 2018

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('=');

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) {
Copy link
Member

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);
Copy link
Member

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>
Copy link
Member

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() {

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?

Copy link
Contributor Author

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.

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

@skabashnyuk skabashnyuk changed the title [WP] Allow to configure logback logger with env variables Allow to configure logback logger with env variables Mar 3, 2018
}

private void setLoggerLevel(String loggerConfig) {
String[] parts = loggerConfig.split("=");
Copy link
Member

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) {
Copy link
Member

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?

Copy link
Member

@sleshchenko sleshchenko left a 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];
Copy link
Member

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

@skabashnyuk
Copy link
Contributor Author

ci-test

Copy link
Contributor

@gazarenkov gazarenkov left a 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.

gazarenkov
gazarenkov approved these changes Mar 3, 2018
@codenvy-ci
Copy link

ci-test build report:
Build details
Test report
selenium tests report data
docker image: eclipseche/che-server:8998
https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.

@skabashnyuk skabashnyuk merged commit e8750d6 into master Mar 7, 2018
@skabashnyuk skabashnyuk deleted the loggbackconfig branch March 7, 2018 11:32
hkolvenbach pushed a commit to hkolvenbach/che that referenced this pull request Mar 12, 2018
@benoitf benoitf removed the status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. label Mar 16, 2018
@benoitf benoitf added this to the 6.3.0 milestone Mar 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/task Internal things, technical debt, and to-do tasks to be performed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow to configure logback logger with env variables
7 participants