-
Notifications
You must be signed in to change notification settings - Fork 306
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
Payara Micro: Enable support for other logging libraries #4546
Comments
Hi, this isn't possible just by adding logging libraries as custom JARs as logging is initialized before those libraries are loaded. However, there's a solution how to use alternative logging libraries. You need to run Payara Micro in a different way. If you put it on the classpath and run the Payara Micro main class directly, you can put custom logging libraries on the classpath too and they will be picked up at boot time, before logging is initialized:
You can pass the same arguments to the PayaraMicro class which are accepted by the Payara Micro JAR. Would this be enough to solve this issue? If not, how would you solve the problem that the logging system is initialized before the custom libraries are loaded? One solution is to disable logging until custom JARs are on the classpath, possibly ignoring some important log messages. Another solution would be to use the default logging configuration of JUL until custom JARs are available and then reinitialize logging using the custom logging.properties file. This would mean that the beginning of the logging output would use a different configuration and thus different logging format. Which one do you prefer? Or do you have another idea how to do it? |
The problem is that I am sticked to ueberjars / bundled jars, but setting the classpath like you suggested doesn't seem to work with that approach. On the other side, I could live with a pre-installed logging framework if it wasn't jul. Main problem is, that I can't set it up with daily rollover etc. which would conflict with our general housekeeping processes. I see the dilemma though, it's correct that logging needs to be setup quite early. From what I get, it would - theoretically - work if the logging jars would be under MICRO-INF/runtime within the bundled jar as that path is part of the classpath from the beginning on - is that correct? If so, all we'd need is a way to tell the maven plugin to add the jars to that directory rather than to MICRO-INF/lib (in addition to the current customjar functionality). Another option would be, if Payara Micro would come in flavours and one could configure which one to use in Maven. But I can see that the possible combinations of flavoured aspects would be endless. I mean, it would be only a matter of time till someone else would request a totally different part to be flavoured... |
Hi @TheTrueDentist, Sadly, we currently have no plans to implement your proposed enhancements due to our priorities being elsewhere. However, we encourage you to contribute to the project yourself if you believe the feature to be worthwhile. Ondrej has shared some solutions with you, but if they are not tailored to what you require exactly, please feel free to enquire about Payara Enterprise with our sales team, this will allow you to raise a feature request as a customer. Payara Server Full distributions have support for using your own logging libraries. It is also possible to write your own adapter for JUL. Thank you for your understanding - I will be closing this issue, |
Description
Payara Micro should support more logging libraries than only jul, preferably through slf4j.
Expected Outcome
Adding slf4j, log4j2 and the youl-to-slf4j bridge as customjars and using org.slf4j.bridge.SLF4JBridgeHandler should reroute the logging output of Payara Micro to slf4j. From there, it could be logged by any other logging framework compatible with slf4j.
Current Outcome
Adding logging dependencies as customjars to the bundled ueberjar and using org.slf4j.bridge.SLF4JBridgeHandler leads to ClassNotFoundExceptions and Payara Micros own logging output is not rerouted to slf4j.
The advantage of implementing this feature would be, that users are not sticked to java.util.logging.
Samples
See https://stackoverflow.com/questions/60421839/payara-micro-how-to-log-with-slf4j-or-log4j2
Environment
The text was updated successfully, but these errors were encountered: