Should log4j library-autoconfigure depend on library?

[trask]

Currently it does not, which is odd, since you would expect an autoconfigure component to depend (and automatically configure) the library component.

But in this case autoconfigure enables the context (mdc) data, but does not enable the appender, and the library only supplies the appender.

(from #4907 (comment))

[trask]

I'm thinking of splitting out "mdc" and "log emitting" instrumentations, e.g.

instrumentation/
  logback/
    logback-1.0/    <== emit log to otel logging pipeline
      javaagent/
      library/
      testing/
    logback-mdc-1.0/    <== inject trace_id/span_id into logback mdc
      javaagent/
      library/
      testing/
  log4j/
    log4j-2.16/    <== emit log to otel logging pipeline
      javaagent/
      library/
      testing/
    log4j-thread-context-2.16/    <== inject trace_id/span_id into log4j thread context
      javaagent/
      library/
      testing/

This should solve the log4j library-autoconfigure question in this issue.

A couple of questions:

• Should we name the log4j2 artifact log4j-mdc, or use log4j2 specific terminology, e.g. log4j-thread-context? (https://logging.apache.org/log4j/2.x/manual/thread-context.html)
• Should the instrumentation that emits logs be just logback-1.0, or have its own classifier, e.g. logback-emit-1.0?

[mateuszrzeszutek]

• Should we name the log4j2 artifact log4j-mdc, or use log4j2 specific terminology, e.g. log4j-thread-context?

👍 for specific terminology

• Should the instrumentation that emits logs be just logback-1.0, or have its own classifier, e.g. logback-emit-1.0?

Hmm, maybe logback-appender-1.0? Though I'd be fine with just logback-1.0 too