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

Payara Micro: Enable support for other logging libraries #4546

Closed
TheTrueDentist opened this issue Mar 3, 2020 · 3 comments
Closed

Payara Micro: Enable support for other logging libraries #4546

TheTrueDentist opened this issue Mar 3, 2020 · 3 comments
Assignees
Labels
Status: Open Issue has been triaged by the front-line engineers and is being worked on verification Type: Enhancement Label issue as an enhancement request

Comments

@TheTrueDentist
Copy link

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

  • Payara Version: 5.194
  • Edition: Micro
  • JDK Version: OpenJDK 11 (should affect any)
  • Operating System: tested on Windows and Linux
  • Database: none / any
@OndroMih
Copy link
Contributor

OndroMih commented Mar 5, 2020

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:

java -cp ./payara-micro.jar:slf4j.jar:log4j2.jar:jul-to-slf4j.jar fish.payara.micro.PayaraMicro some.war

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?

@OndroMih OndroMih added the Status: Pending Waiting on the issue requester to give more details or share a reproducer label Mar 5, 2020
@TheTrueDentist
Copy link
Author

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...

@OndroMih OndroMih removed the Status: Pending Waiting on the issue requester to give more details or share a reproducer label Mar 24, 2020
@fturizo fturizo added Status: Open Issue has been triaged by the front-line engineers and is being worked on verification Type: Enhancement Label issue as an enhancement request labels Nov 11, 2020
@AlanRoth AlanRoth assigned AlanRoth and unassigned OndroMih Nov 18, 2020
@AlanRoth
Copy link

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,
Alan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Open Issue has been triaged by the front-line engineers and is being worked on verification Type: Enhancement Label issue as an enhancement request
Projects
None yet
Development

No branches or pull requests

4 participants