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

LoggerConfig - make LoggerConfig#clearAppenders() public? #3157

Open
JWT007 opened this issue Nov 3, 2024 · 0 comments
Open

LoggerConfig - make LoggerConfig#clearAppenders() public? #3157

JWT007 opened this issue Nov 3, 2024 · 0 comments

Comments

@JWT007
Copy link
Contributor

JWT007 commented Nov 3, 2024

LoggerConfig (Log4j 2.24.1)

I am not sure if this would be considered a bug or works-as-designed.

I am currently implementing a custom Configuration which does not inherit from AbstractConfiguration- but I am borrowing a lot of the behaviour from AbstractConfiguration.

In the 'AbstractConfiguration#stop()' method, the appenders are cleared from all LoggerConfigs after stopping the appenders.

This uses the package-protected LoggerConfig#clearAppenders() method.

LoggerConfig

protected void clearAppenders() {
    do {
        final AppenderControl[] original = appenders.clear();
        for (final AppenderControl ctl : original) {
            cleanupFilter(ctl);
        }
    } while (!appenders.isEmpty());
}

Since this is package-protected; I cannot provide the same functionality with a custom Configuration implementation.

NOTE: Why am I doing this? My implementation is not Node based. I am capturing all configuration from the configuration XML so that I will be able to write a new XML at runtime with changes added from an Admin-Client UI (i.e. new/updated Loggers/Appenders).

My workaround is a static utility method in a custom-class pushed into the LoggerConfig package - which will only work as long as we are not using Java module-system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant