[logback-user] Redirecting JDK 9's JVM logs to Logback?

[Osvaldo Pinali Doederlein]

Hi Martin,Someone shared this code already: (Some TODOs but I didn't finish
cleaning it up myself, but it;'s just some missing switch statements and
reading resource
bundles)http://www.logicbig.com/tutorials/core-java-tutorial/java-9-changes/platform-logging/Not
much code but it would be nice to have this built into logging libraries
this code can be compiled with -source/-target compatible with older JVM,
will be automatically ignored by older JVMs that do not recognize the new
service declaration in the manifest.A standard prefix to work around
recursion with stdout is one possible fix, but modern logging APIs make a
lot of effort to reduce per-call overhead so copying/splitting all message
strings can be significant... maybe I could make my app check the logging
config at startup, and only enable the stdout->logger redirection if the
logging API's stdout appender is not enabled. I guess Logback's
LoggerContextListener allows me to be notified if the configuration changes
to I can enable/disable that as needed. 
Martin Grajcar wrote
> On Mon, Dec 4, 2017 at 4:02 PM, Osvaldo Doederlein <

> opinali@

> >wrote:> Hi,>> I want to redirect the JVM's internal logs to Logback,
> is this possible?> More specifically, I have all my app logs going to a
> single appender and I> want JVM logs such as GC to be writing to the same
> appender, interleaved> with app logs.>> I have Logback configured with
> slf4j and jul-to-slf4j, also I wrote a> System.LoggerFinder>Could you
> share it?> service to redirect System.Logger to SLF4J->Logback, which I
> can see> working for core lib logs such as java.base /
> sun.net.www.protocol.http.HttpURLConnection.> (See
> http://openjdk.java.net/jeps/158) However, the GC logs are still> going to
> stdout. The documentation for JEP 158 seems to imply that the JVM> logs
> are something separate from java.util.logging, can only be sent to>
> stderr, stdout or a log file, but not to a JUL logger.>> I know that I can
> hook the System.out/err streams and redirect writes to a> logger, but this
> is not ideal, for one thing I cannot configure Logback to> send logs back
> to stdout (which I often do in test/interactive runs)> without risking a
> stack overflow.  I could write code that walks the stack> to decide if the
> call to System.err/out is coming from a logger, but this> is expensive.>>
> Anyone knows a magic trick here? :-)>A magic prefix maybe? Something like
> prefixing every message by "I'm comingfrom stdout. If you send me there
> again, your stack will overflow".Prefixing every line forwarded from
> stdout to the logger by "STDOUT "should do, though you'll miss all lines
> already starting by the prefix.Which can be made arbitrarily
> improbable.Assuming all lines are unique, you could use a
> (Concurrent?)HashSet storingall lines send to stdout by the logger and
> remove them when you see themcoming back. This is probably much faster
> than stack walking. Some periodiccleanup may be necessary in case
> something gets
> lost._______________________________________________logback-user mailing
> list

> logback-user@

> http://mailman.qos.ch/mailman/listinfo/logback-user





--
Sent from: http://logback.10977.n7.nabble.com/Users-f3.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20171204/5b222e70/attachment.html>