Implement SLF4Jm JUL, and Log4J2 providers for Java SDK#68725
Merged
Conversation
uranusjr
requested review from
amoghrajesh,
ashb,
bugraoz93,
gopidesupavan,
jason810496,
jscheffl and
potiuk
as code owners
uranusjr
added
the
AIP-108: java-sdk
uranusjr
force-pushed
the
java-sdk-logging-providers
branch
3 times, most recently
from
3ac5294 to
d48fe00
Compare
Member
Author
|
Don’t know if it makes sense… since Airflow uses structlog, and the log forwarder actually works best with structured arguments, trying out intentionally NOT rendering the message but put the arguments in the dict instead 
Is this too weird? |
phanikumv
reviewed
Jun 19, 2026
phanikumv
reviewed
Jun 19, 2026
jason810496
approved these changes
Jun 22, 2026
jason810496
left a comment
jason810496
left a comment
Member
There was a problem hiding this comment.
LGTM overall. Thanks for supporting different logging backend for Java-SDK, I have never thought about this part, really nice feature.
Here're some nits caught by claude with the local checked-out branch that make sense to me.
Member
I prefer the log format of previous version (though the log level was wrong) as it's quite difficult for human to interpret the 
|
uranusjr
force-pushed
the
java-sdk-logging-providers
branch
from
d48fe00 to
aa70845
Compare
Member
Author
|
I switched back to use “normal” rendered messages. |
A new airflow-sdk-slf4j artifact is added to allow SLF4J to be seamlessly forwarded to Airflow's task log infrastructure. Use 'org.apache.airflow:airflow-sdk-slf4j' to enable this.
This allows log4j users to write logs into Airflow directly. Note that this uses Java since the appender is registered with an annotation, and the annotation processor can only handle Java. (There's a Kotlin bridge, but the class is small enough it doesn't make much sense to pull it in.)
This is too fancy for the spell checker. Use Dumb English instead.
Systen.log annoyingly pass a null as an array to a vararg method implemented in Kotlin. This breaks Kotlin since it expects an empty array instead. Fortunately, there seems to be a way to work around this, according to Claude? Let's hope this works.
This implements an incremental NamespaceLevels parser that progressively split the input raw value, parse each entry, report any errors as it goes (to the regular Airflow logging channel), and keep parsed entries with best effort (instead of crashing out entirely).
The previous implementation incorrectly uses the marker's name to identify the logger. Switch to use the logger's name instead.
This matches the more familiar logging behavior, where the log message is a template, and the full message rendered with extra arguments. The JPL implementation has an extra feature. If rendering fails, the unrendered template is sent as-is with un-renderable arguments attached in extra metadata keys. This is possible since JPL surfaces the exception during rendering transparently. Other loggins platforms do not make the same easy, so we simply use whatever mechanism provided natively.
uranusjr
force-pushed
the
java-sdk-logging-providers
branch
from
d138bc1 to
20bc567
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Additional mechanism is added Logger in sdk.execution to support sending arbitrary log messages to LogSender. Once that's in place, we can implement various adapters to support common Java logging providers with a bit boilerplate code for each.
Those providers are implemented in separate artifacts since nobody needs all of them at once. The user can choose what they want. Documentation is added to describe how to do it.
I changed examples to prefer the Java Platform Logging interface instead of SLF4J too. This is built-in since Java 9. All the logging tools are more or less the same, so users should adapt pretty easily.