-
Notifications
You must be signed in to change notification settings - Fork 266
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
FR: Allow for other slf4j-api implementations #366
Comments
Hi @john2home - thanks for pointing this issue out. It's a fair request and makes sense. I filed this in our feature request database. If I hear anything back, I'll make sure to update this issue. |
I totally agree about this issue. Solving this issue will also solve #319, which I think was inappropriately closed. Using slf4j-api, there's no reason to not support other logging frameworks. Both this issue and #319 has the same solution: Use slf4j-api. Additionally, I have found that using
with the error: Changing the implementation of |
I have an issue embedding HiveMQ into a Quarkus app, related to this.
|
Problem or use case
the broker does not allow the use of any other implementation of the slf4j-api. normally an application uses only the slf4j-api and leaves it up to the user to decide which slf4j-api-implementation to use.
but if you exclude logback-classic the embedded broker hangs up in HiveMQServer.bootstrap() by calling LoggingBootstrap.prepareLogging();
Preferred solution or suggestions
the embedded broker should only use the slf4j-api and leave it up to the user to decide which implementation he wants/can/must use.
The text was updated successfully, but these errors were encountered: