Skip to content

Debug mode should not be triggered only by the presence of a "debug" env property #16545

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

Closed
jiahut opened this issue Apr 12, 2019 · 3 comments
Closed
Assignees
Labels
status: duplicate A duplicate of another issue

Comments

@jiahut
Copy link

jiahut commented Apr 12, 2019

As soon as system environment exist the debug variable, the spring boot will set springBootLogging to debug

It is so freedom

in my case, oneday, someone executed some program like shell, it had been set environment variable debug = 1 or trace careless. when restart, it set the springBootLogging to debug.

We can't restrict others from doing so.

I think set springBootLogging to debug so freedom , it should be added some prefix

look at LoggingApplicationListener.java

private void initializeEarlyLoggingLevel(ConfigurableEnvironment environment) {
	if (this.parseArgs && this.springBootLogging == null) {
		if (isSet(environment, "debug")) {
			this.springBootLogging = LogLevel.DEBUG;
		}
		if (isSet(environment, "trace")) {
			this.springBootLogging = LogLevel.TRACE;
		}
	}
}
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 12, 2019
@snicoll snicoll changed the title [bug] SpringApplicationRunner.java set springBootLogging to debug so freedom debug mode should not be triggered only by the presence of a "debug" env property Apr 12, 2019
@philwebb philwebb changed the title debug mode should not be triggered only by the presence of a "debug" env property Debug mode should not be triggered only by the presence of a "debug" env property Apr 12, 2019
@philwebb
Copy link
Member

This is one part of a broader problem that's discussed in #3450 and I don't think we can change the existing behavior without breaking existing apps. If would be nice if we could offer a quick way to opt-out of picking up those flags from the system environment.

@philwebb philwebb added type: enhancement A general enhancement for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged and removed status: waiting-for-triage An issue we've not yet triaged for: team-attention An issue we'd like other members of the team to review labels Apr 12, 2019
@philwebb philwebb self-assigned this Apr 17, 2019
@philwebb philwebb removed for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement labels Apr 17, 2019
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 17, 2019
@philwebb
Copy link
Member

I think we should consider this a duplicate of #3450.

@jiahut If you want a work-around until #3450 is fixed you can do something like the following:

SpringApplication springApplication = new SpringApplication(MyApp.class);
for(ApplicationListener<?> listener: springApplication.getListeners()) {
  if (listener instanceof LoggingApplicationListener) {
    ((LoggingApplicationListener) listener).setParseArgs(false);
  }
}

@philwebb philwebb added status: duplicate A duplicate of another issue and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 17, 2019
@jiahut
Copy link
Author

jiahut commented Apr 18, 2019

@philwebb thinks. +1 for #3450

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

3 participants