Improvements to logging (#3262) #3267
Conversation
ketan
force-pushed
the
improve/loggging
branch
9 times, most recently
from
297f733
to
452a8d8
Compare
|
|
Did not test it by bringing up an agent, but the code looks good to me..about the deletion of agent manifest file have you checked if the packaged agent MANIFEST file continues to include all the required info. This is what I see in the current version: |
All jars are packaged via the |
|
Then I guess its all good. |
|
the only thing is build hasn't run, so may be you would want to see that through, esp. the functional tests |
| @@ -39,8 +40,9 @@ | |||
|
|
|||
| public class DevelopmentServer { | |||
| public static void main(String[] args) throws Exception { | |||
| LogConfigurator logConfigurator = new LogConfigurator(DEFAULT_LOG4J_CONFIGURATION_FILE); | |||
| logConfigurator.initialize(); | |||
There was a problem hiding this comment.
No need for this. LoggingInitializer will take care of it. The statement Could not find file 'config/log4j.properties'. Attempting to load from classpath. appears twice otherwise
There was a problem hiding this comment.
This happens because the main program uses a different classloader than the webapp. So the logger is actually initialized twice. Side-effect of how logging is setup, unfortunately nothing (simple) that can be done about it.
| fi | ||
|
|
||
| mkdir -p "${LOG_DIR}" | ||
|
|
||
| STDOUT_LOG_FILE=$LOG_DIR/${SERVICE_NAME}-bootstrapper.out.log |
There was a problem hiding this comment.
There is a LOG_FILE variable that is exported unnecessarily and stop-agent.sh also sets it unnecessarily. I did a git grep -w "LOG_FILE" in the project and found no usages in the code, except for JavaApplicationStub64. I think we can remove it.
There was a problem hiding this comment.
@varshavaradarajan @jyotisingh — I think I'm done submitting additional changes to this PR. You probably want to see the last 5 commits —
- 30f2c13 - Remove declaration of unwanted
LOG_FILEenvironment variable. (6 minutes ago) - 45ff550 - Remove deprecated
AGENT_TRUST_FILEconstant. (6 minutes ago) - 4f6e8ef - Remove hard-coded
configdir and use the one defined inSystemEnvironmentinstead (6 minutes ago) - 5aa840c - Ignore the log dir (6 minutes ago)
- 35c8090 - Change log dir to
logs(6 minutes ago)
| @@ -39,8 +40,9 @@ | |||
|
|
|||
| public class DevelopmentServer { | |||
| public static void main(String[] args) throws Exception { | |||
| LogConfigurator logConfigurator = new LogConfigurator(DEFAULT_LOG4J_CONFIGURATION_FILE); | |||
| logConfigurator.initialize(); | |||
There was a problem hiding this comment.
This happens because the main program uses a different classloader than the webapp. So the logger is actually initialized twice. Side-effect of how logging is setup, unfortunately nothing (simple) that can be done about it.
agent/build.gradle
Outdated
| @@ -55,7 +55,6 @@ clean.doFirst { | |||
| delete 'agent-plugins.zip' | |||
| delete 'tfs-impl.jar' | |||
| delete 'go-agent.log' | |||
There was a problem hiding this comment.
Doesn't this have to be logs directory now?
|
@ketan, https://github.com/gocd/gocd/blob/master/agent-launcher/test/com/thoughtworks/go/agent/launcher/AgentLauncherImplTest.java#L64 needs to change lest it leaves behind a the logs directory during cleanup? |
ketan
force-pushed
the
improve/loggging
branch
2 times, most recently
from
af06677
to
d84b7f3
Compare
* this will look for a log file in the current working directory * in case the file is not found, will look for the same file in the classpath * in case of missing classpath resource, will fallback to configure logging to STDOUT at INFO level
Spring was initializing the logger, which might have been too late in case some component failed early.
…ronment` instead
Cleanup the `AGENT_TRUST_FILE` in bootstrapper so it will eventually happen on a bootstrapper upgrade. Avoid messing with that file in agent process
Leave declaration in `JavaApplicationStub64` which seems to use it locally.
No description provided.