Fix Java-SDK logging level

[jason810496]

Why

A Java task's SLF4J logs (e.g. logger.info(...)) fell through to stderr, which the supervisor tags as ERROR, so every application log showed up as ERROR in the UI regardless of its real level.

Java-Task code:

@Task(
    id = "extract"
)
public long extractValue(Client client) throws InterruptedException {
    logger.info("Hello from task");
    Object pythonXcom = client.getXCom("python_task_1");
    logger.info("Got XCom from Python Task 'python_task_1' {}", pythonXcom);
    Connection connection = client.getConnection("test_http");
    logger.info("Got con {}", connection);

    for(int i = 0; i < 3; ++i) {
        logger.info("Beep {}, next time will be {}", i, new Date());
        Thread.sleep(2000L);
    }

    logger.info("Goodbye from task");
    return (new Date()).getTime();
}

What Airflow UI got:

What

• Ship an SLF4J binding inside the SDK (AirflowSlf4jServiceProvider) registered via META-INF/services, so LoggerFactory.getLogger(...) routes through the Airflow logs socket carrying each message's real level instead of writing to stderr.
• Map SLF4J levels to the strings the supervisor (structlog NAME_TO_LEVEL) understands; TRACE maps to debug since there is no TRACE level on the Python side.

---

Was generative AI tooling used to co-author this PR?

• Yes, with help of Claude Code (Opus 4.8) following the guidelines

[jason810496]

Actually, I felt we should provide the log_level in StartupDetails.

I prefer to respect the Airflow side logging level, which means user might setup custom secret backend for the conf. So we need to send the [logging/log_level] info from supervisor.

[uranusjr]

I agree, let’s do this. The Python implementation should probably also be changed to respect this log_level value (and fall back to various configurations).

Since this requires Python side changes, I would say for 3.3 let’s just default to INFO in SDKs and add support for Airflow configuration later.

[jason810496]

Sure, then I will go with this direction. This should solve Phani's review comment as well.

[uranusjr]

I think TRACE should be mapped to NOTSET (0).

[uranusjr]

Actually, why do we need to reinvent level? This enum can simply map 1:1 to Python levels, and we just resolve SLF4J levels to Python levels directly.

[phanikumv]

Can you test this scenario with this PR, I think it breaks.

In airflow.cfg
[logging]
logging_level = WARNING

Since it wont be in os.environ: no AIRFLOW__LOGGING__LOGGING_LEVEL set . Hence Java resolves to INFO.

Overall Result: Java WARNING logs will be silently dropped. A Python task in the same deployment with the same cfg would show WARNING logs.

I think it is identical config, divergent behavior by task language .

[uranusjr]

Moved to #68725