Two question about LogManager and LoggingContext in JavaEE/JakartaEE apps

[Bukama]

Hallo everyone,
I would like to ask two questions about the LogManager / LoggingContext in JavaEE/JakartaEE applications. I alraedy tried to answer them by the docs, but could not found anything that made me sure about my thoughts.

We use such StartUpService-Beans in most of our artefacts to read up an configured URL with the path to the log4j2.xml and set up the LoggingContext (Log4J2 2.20).

@Singleton
@Startup
@LocalBean
public class StartUpService {

  @Resource(name = "url/bean/loggerRef", type = URL.class)
  private URL loggingUrl;

  @Inject
  private Logger logger;

 
  @PostConstruct
  void postConstruct() {
    configLogger();
  }

  void configLogger() {
    logger.traceEntry();
    try {
      LoggerContext loggerContext = (LoggerContext) LogManager.getContext(false);
      loggerContext.setConfigLocation(loggingUrl.toURI());
      loggerContext.updateLoggers();
      String message = String.format("Logging configuration succeded [%s].", loggingUrl);
      logger.info(message);
    } catch (URISyntaxException e) {
      String message = String.format("Logging configuration failed [%s].", loggingUrl);
      logger.error(message, e);
      throw new MyBeanRuntimeException(message, e);
    }
    logger.traceExit();
  }
}

After upgrading the PMD analyser tools it now shows a warning that the LoggerContext should be closed after usage. This brings me to the question if we can savely do this, without loosing the set URL. For my understanding the line

LoggerContext loggerContext = (LoggerContext) LogManager.getContext(false);

gets a reference and not a copy of the context and therefore if I would close the context after I set the URL of the config file it would be lost?

Similar question after someone of my team noticed that (at least on his maschine) the configuration setting monitorInterval spawns endless threads to update the setting, but does not remove the java thread after the application is shut down. His solution was to add the following @PreDestroy method which should work as long as the StartUpService is a @Singleton bean which lives as long as the application lives, but I doubt it woul work if the class is not an @Singleton and gets destroyed after it has configured the logger.

@PreDestroy
  void preDestroy() {
    LogManager.shutdown();
  }

What are your thoughts about this shutdown() call?

[Bukama]

I can at least answer this part:
LoggerContext loggerContext = (LoggerContext) LogManager.getContext(false);

As expected: If you close it, your logger will be closed as well and the app no longer logs.

[ppkarwasz]

@Bukama,

After upgrading the PMD analyser tools it now shows a warning that the LoggerContext should be closed after usage. This brings me to the question if we can savely do this, without loosing the set URL. For my understanding the line

LoggerContext loggerContext = (LoggerContext) LogManager.getContext(false);

gets a reference and not a copy of the context and therefore if I would close the context after I set the URL of the config file it would be lost?

Yes, loggerContext is a reference to the logger context and if you close it, it shuts down. I am not sure why the AutoCloseable interface was added to LoggerContext, since in most situation you don't want to use it in a try with resources expression.

What are your thoughts about this shutdown() call?

I would rather save the LoggerContext instance used in the configLogger call and call LoggerContext#stop on it. This way you are 100% sure to close the correct logger context.

Every (explicit or implicit) call to LogManager.getContext uses the ContextSelector to return the most appropriate logger context. The default context selector associates a logger context to the classloader of the caller, but context selectors are pluggable, so there is not guarantee that the logger context you configured is the one you are shutting down.

[jvz]

I am not sure why the AutoCloseable interface was added to LoggerContext, since in most situation you don't want to use it in a try with resources expression.

Back when Java 7 came out and we could finally start using it in this library, we were overly excited about this feature. Plus, we tended to try to reuse standard Java interfaces for concepts where possible. Considering we eventually added stop(long, TimeUnit) variants of close(), it's no longer as useful an interface to implement, but we do have some tests (mostly written by me I think) which use try-with-resources to construct a LoggerContext for a brief test.