Details
-
Fix
-
Status: Released (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
-
None
Description
Current Situation
- JobScheduler (Master and Agent) come with log4j adapter JobSchedulerLog4JAppender
- The distributed log4j.properties file uses this adapter for all log4j-based logging
- The purpose of the adapter is to enable JITL jobs to use log4j and have the output written to spooler_log and to whatever else is configured in log4j
- Problem: The JobScheduler Universal Agent uses log4j (or logback) as well for it's own logging
- In certain combinations of configured and used log level, the Agent's own logging will log something for remote api calls (of the job)
- such a remote api call could be a call to spooler_log.log(...)
- As there is only one log4j root logger in the jvm and this logger is configured to use JobSchedulerLog4JAppender, the appender will call spooler_log.log for everything that is logged by
- jobs
- 3rd party classes
- the agent itself
- so, a log4j log call (from a job) creates a spooler_log call (from the appender) creates a log4j log (from the agent) creates a spooler_log call (from the appender) ... -> endless recursion
Desired Behaviour
- JobScheduler (Master and Agent) come with log4j adapter JobSchedulerLog4JAppender
- The distributed log4j.properties file uses this adapter for the log4j-based logging of the JITL jobs
- The distributed log4j.properties file does not use this adapter for non-sos classes or the agent