Change default Java Util Logging format

[pgomulka]

Currently Elasticsearch is not setting a JUL configuration, so JUL is defaulting a format to

static final String DEFAULT_FORMAT =
            "%1$tb %1$td, %1$tY %1$tl:%1$tM:%1$tS %1$Tp %2$s%n%4$s: %5$s%6$s%n";

https://github.com/AdoptOpenJDK/openjdk-jdk9u/blob/master/jdk/src/java.base/share/classes/jdk/internal/logger/SimpleConsoleLogger.java#L404

this means it contains a New Line in the middle. That results in log messages being split and interleaved.
This is also preventing the filtering messages with MMapDirectory in LogConfigurator to work correctly

This commit sets a simple default format [level][loggerName] message exceptionIfAny\n

Example of current behaviour:
log.info("Using MemorySegmentIndexInput with Java 19; to disable start with -Dorg.apache.lucene.store.MMapDirectory.enableMemorySegments=false");

will result in (when filtering removed):

[2023-06-01T14:32:20,944][WARN ][stderr                   ] [runTask-0] Jun 01, 2023 2:32:20 PM org.apache.lucene.store.MemorySegmentIndexInputProvider <init>
[2023-06-01T14:32:25,641][WARN ][stderr                   ] [runTask-0] INFO: Using MemorySegmentIndexInput with Java 20; to disable start with -Dorg.apache.lucene.store.MMapDirectory.enableMemorySegments=false

and with filtering we end up with just single line:

[2023-06-01T14:32:20,944][WARN ][stderr                   ] [runTask-0] Jun 01, 2023 2:32:20 PM org.apache.lucene.store.MemorySegmentIndexInputProvider <init>

with this change we will get the message fully filtered out or in single line (when filtering disabled):

[2023-06-02T11:49:38,172][WARN ][stderr                   ] [runTask-0] [INFO][org.apache.lucene.store.MemorySegmentIndexInputProvider] Using MemorySegmentIndexInput with Java 20; to disable start with -Dorg.apache.lucene.store.MMapDirectory.enableMemorySegments=false

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[pgomulka]

@elasticmachine run elasticsearch-ci/bwc

[ChrisHegarty]

I think that this is good. A few comments:

1. Can you please check the output of the vector message, e.g. "Java vector incubator API enabled; uses preferredBitSize". I want to ensure that we do not inadvertently do something "bad" to it. Just a sanity to check it.

2. Can the filter for stderr in LogConfiguration be simplified - I added two entries for the vector log message, we should only need one now, right? Also, can we make this filter a static final which I overlooked here Enable the Panama Vector module #96453 (comment)

[pgomulka]

I think that this is good. A few comments:

Can you please check the output of the vector message, e.g. "Java vector incubator API enabled; uses preferredBitSize". I want to ensure that we do not inadvertently do something "bad" to it. Just a sanity to check it.

I can still see the message

[2023-06-02T15:02:06,887][WARN ][stderr                   ] [yamlRestTest-0] [INFO][org.apache.lucene.util.VectorUtilPanamaProvider] Java vector incubator API enabled; uses preferredBitSize=128

Can the filter for stderr in LogConfiguration be simplified - I added two entries for the vector log message, we should only need one now, right? Also, can we make this filter a static final which I overlooked here #96453 (comment)

on main (with your commit) when I remove the two filters you added I still cannot see the warning with VectorUtilProvider
I am running:

 ./gradlew ':modules:lang-painless:yamlRestTest' --tests "org.elasticsearch.painless.LangPainlessClientYamlTestSuiteIT.test {yaml=painless/180_knn_and_binary_dv_fields_api/*}"  -Dtests.rest.cluster=localhost:9200 -Dtests.cluster=localhost:9300 -Dtests.clustername=elasticsearch

and a cluster is running with JDK20
perhaps those filters are not needed?

[rjernst]

While this may improve the situation with JUL messages, it still has the confusion of emitting all JUL as WARN because it is coming from stderr. I think we should focus on #94613 which will allow the log level to be translated, and then the format will not matter because the messages will be bridged to log4j. I experimented with the bridge before and can resume my work. WDYT?

[pgomulka]

agree, that #94613 would be a better choice. Can you leave your notes/thoughts on the #94613? Was exposing jul bridge the only concern?
I will happily take that task over and look into it at some point later.

[rjernst]

@pgomulka I think this can be closed now that #96683 is complete?

[pgomulka]

closing as #96683 is merged