tersesystems / echopraxia Goto Github PK

Like https://github.com/tersesystems/terse-logback/blob/master/logback-classic/src/main/java/com/tersesystems/logback/classic/ChangeLogLevel.java but we can provide a public API for it that can work with Log4J2 as well.

Kind of scope creep :-/

https://netty.io/wiki/using-as-a-generic-library.html#thread-local-object-pool

It's worth the cost of evaluating a field builder function if the condition is explicitly on the statement. Running through fields isn't the same as actually logging it, and the implication is that the condition is important enough to carry through.

Should be able to pass in context and reference it from Tweakflow

We should be able to integrate with request interceptors and scheduled work that uses MDC as necessary.

https://reflectoring.io/structured-logging/

https://logging.apache.org/log4j/log4j-2.12.4/manual/thread-context.html

NDC / MDC is not strictly thread based, but has had difficulties with Finagle and other async frameworks

https://logging.apache.org/log4j/log4j-2.11.0/manual/extending.html

https://issues.apache.org/jira/browse/LOG4J2-1010

Need to ensure there's a way to get at the impl directly or override it.

Using Value<List<Field>> etc rather than using ArrayValue is obscure and doesn't really help anything.

Also, Field.Valuerather than just Value is a bit odd.

CoreLoggerProvider should stay the same, but find a list of filters and then wrap them around it.

Should be able to add conditions, add fields, etc by the time it even passes to a logger.

Filters can be global (around a logger factory call) or can be local to a logger.

Can implement sampling with filters?

https://www.structlog.org/en/stable/processors.html

Implemented by #85

Converting between Field.Value and an actual String | Number | Boolean is needlessly painful

See about using https://github.com/SYNAXON/logstash-util-formatter as a backend

https://community.oracle.com/tech/developers/discussion/4418045/understanding-java-jit-compilation-with-jitwatch

https://github.com/AdoptOpenJDK/jitwatch

Executing conditions could be arbitrarily expensive.

Especially for statement logging which is a side effect, there's no reason we can't make this async and take the load off the rendering thread.

Either use CompletionStage API:

AsyncCondition asyncCondition = (level, context) -> CompletableFuture.completedFuture(true);
logger.info(asyncCondition, "Message {}", fb -> ...);

or offload it using an executor:

logger.withExecutor(executor).withCondition(condition).info("Message {}", fb -> ...);

Obviously predicates wouldn't work in this model:

if (logger.isDebugEnabled(condition)) {
   ???
}

Instead you'd need to do something like:

logger.isDebugEnabled(condition).thenRun(() -> logger.debug("foo")); // rendering thread
logger.isDebugEnabled(condition).thenRunAsync(() -> logger.debug("foo")); // condition's thread

Might need a special logger to do this if we extend it to predicates and builders.

Obviously the logging statement itself would occur in a different thread at this point, as it would be post condition. Also anything involving thread-local storage / servlets would need special handling. This would require special-case MDC/NDC handling as well. :-(

Should default to current class's name if no argument passed in.

Let the store know we built it

https://blog.frankel.ch/system-logger/

Looking up a field name or value from context using a list is a bit painful.

Possible to integrate fields / values into https://github.com/json-path/JsonPath?

At least add a find API

Should have several threads all trying to execute conditions at once.

should be able to do:

String exMessage = ctx.findString("$.exception.message") 

using the object mapper.

Hey,

would it be possible to put structured arguments optionally into the MDC?

Maybe my use case is a bit special: I am using Quarkus and there you cannot easily replace jboss-logmanager with logstash, which makes everything a bit of a pain. Additionally, I want to post log entries via gelf/fluent to elastic and there is a gelf plugin for Quarkus, which includes everything put into the MDC.

I know I can write my own wrapper or interceptor, but really would like to keep the nice field builders from Echopraxia.

Don't really need a dependency on logstash-logback-encoder here.

https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle

If the find methods go through a script, something is making it much slower than if being called directly.

Benchmark                                      Mode  Cnt     Score     Error  Units
ScriptingBenchmarks.testFileConditionFail      avgt    5  4379.959 ± 579.831  ns/op
ScriptingBenchmarks.testFileConditionMatch     avgt    5  4610.075 ± 147.281  ns/op
ScriptingBenchmarks.testStringConditionFail    avgt    5  4649.784 ±  87.629  ns/op
ScriptingBenchmarks.testStringConditionMatch   avgt    5  4262.437 ± 191.742  ns/op
ScriptingBenchmarks.testWatchedConditionFail   avgt    5  5242.896 ±  93.665  ns/op
ScriptingBenchmarks.testWatchedConditionMatch  avgt    5  4700.055 ±  87.745  ns/op

See #129

Somehow a call can have a void return type, which means that calling call.bool() can fail. Need to check for the return type and not call bool() if it doesn't have the right return type.

str.starts_with?(fields[:request_remote_addr], "127")

Should mention https://failsafe.dev/ when talking about calls to remote systems, never want a stalled condition.

There was a problem when upgrading to version 2.3.0. Initially, version 2.2.4 was used and the system was working fine. However, after upgrading to version 2.3.0, the system could not start and an error message appeared stating "java.lang.ClassNotFoundException: org.slf4j.impl.StaticLoggerBinder". Upon investigation, it was discovered that version 1.4.6 of logback was being used in the system, and this version does not have the class "org.slf4j.impl.StaticLoggerBinder". Is this a compatibility issue introduced by version 2.3.0? Can it be fixed?

Caller info is a bit messed up because it comes from the Echopraxia intersection. Can change the caller info to rewrite the stacktrace.

For Logback, use https://logback.qos.ch/apidocs/ch/qos/logback/classic/LoggerContext.html#getFrameworkPackages()

For Log4J it's ExtendedLoggerWrapper with a FQCN.

Need to ensure that context fields are lazy so the function is only evaluated on statement.

Show how you can add Log4J Marker in README

• Account for NeverLogger, including defaults for null ops
• Provide better defaults for the with methods
• Provide a single constructor method for instantiating new MyLogger