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

[LOGMGR-350] Avoid TCCL when configuring the log manager #469

Merged
merged 1 commit into from
Apr 23, 2024

Conversation

dmlloyd
Copy link
Member

@dmlloyd dmlloyd commented Apr 15, 2024

The services were previously located by looking at the TCCL rather than class loader which loaded the log manager itself. This is normally the system (i.e. application) class loader, but it could be an agent class loader or the bootstrap class loader in certain circumstances.

One result of this behavior is that when the TCCL is not the same as the system class loader, logging can be configured twice: once by Quarkus and once using the default configuration (see elastic/apm-agent-java#3563). Changing to avoid the TCCL causes the behavior to become stable and predictable.

@jamezp
Copy link
Member

jamezp commented Apr 23, 2024

Sorry for the delay on this. I need to think how this will work in WildFly. For the integration work I created a new JBoss Module which would somehow need to be exposed on the same class path to pick up the services.

@jamezp jamezp merged commit a248939 into jboss-logging:main Apr 23, 2024
3 checks passed
@dmlloyd dmlloyd deleted the logmgr-350 branch April 23, 2024 20:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants