baggage delegate to IncludeExcludePredicate and allow wildcards in auto-configuration

[SylvainJuge]

Baggage processor already delegates to IncludeExcludePredicate.

When using declarative configuration:

• include and exclude configuration attributes can be used to include/exclude and directly delegate to IncludeExcludePredicate

When using auto-configuration

• baggage attributes are only opt-in, equivalent to only having include set in declarative configuration
• exact matching is being used
• the * value can be used as "include-all"
• no other form of wildcard matching is supported

This PR:

• makes the delegation to IncludeExcludePredicate applied in both configuration types
• adds the ability to use wildcards when not using declarative configuration (not limited anymore to *)
• refactor implementation and tests following this change
• deprecates the following constructors to push using the include/exclude variants.
  • BaggageSpanProcessor(Predicate<String> baggageKeyPredicate)
  • BaggageLogRecordProcessor(Predicate<String> baggageKeyPredicate)

[Copilot]

Pull request overview

Updates the baggage span/log processors to consistently use IncludeExcludePredicate across declarative config and auto-configuration, enabling wildcard pattern matching in auto-config include lists.

Changes:

• Refactors BaggageSpanProcessor / BaggageLogRecordProcessor to construct their key-filter predicate via IncludeExcludePredicate.createPatternMatching(included, excluded).
• Updates auto-configuration and declarative component providers to pass include/exclude pattern lists into the processors.
• Refactors/extends tests and updates README auto-config docs to mention wildcard pattern matching.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
baggage-processor/src/main/java/io/opentelemetry/contrib/baggage/processor/BaggageSpanProcessor.java	Switches processor construction to include/exclude pattern matching via IncludeExcludePredicate.
baggage-processor/src/main/java/io/opentelemetry/contrib/baggage/processor/BaggageLogRecordProcessor.java	Same include/exclude pattern matching refactor for logs processor.
baggage-processor/src/main/java/io/opentelemetry/contrib/baggage/processor/BaggageProcessorCustomizer.java	Auto-config now instantiates processors with include patterns (wildcards supported).
baggage-processor/src/main/java/io/opentelemetry/contrib/baggage/processor/BaggageSpanComponentProvider.java	Declarative config provider now passes included/excluded lists to the processor.
baggage-processor/src/main/java/io/opentelemetry/contrib/baggage/processor/BaggageLogRecordComponentProvider.java	Declarative config provider now passes included/excluded lists to the processor.
baggage-processor/src/test/java/io/opentelemetry/contrib/baggage/processor/BaggageSpanProcessorTest.java	Updates tests to use include/exclude pattern lists (wildcards + exclude).
baggage-processor/src/test/java/io/opentelemetry/contrib/baggage/processor/BaggageProcessorCustomizerTest.java	Refactors tests for new constructor signature; adds include/exclude test for logs processor.
baggage-processor/README.md	Updates auto-config docs to reference wildcard pattern matching support.

[SylvainJuge]

[for reviewer] this optimization is not really necessary as an equivalent is implemented in GlobUtils, we could however do this in IncludeExcludePredicate as a follow-up improvement.

[SylvainJuge]

[for reviewer] this optimization is not really necessary as an equivalent is implemented in GlobUtils, we could however do this in IncludeExcludePredicate as a follow-up improvement.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 7 comments.

[Copilot]

In the Java snippet, import io.opentelemetry.contrib.baggage.processor; is not a valid Java import (it imports a package, not a type). Update the example to import the concrete classes used (e.g., BaggageSpanProcessor, BaggageLogRecordProcessor, and any SDK types).

[MikeGoldsmith]

Over all looks good, thanks @SylvainJuge 👍🏻

Some docs notes:

The switch from exact matching (keys::contains) to a glob pattern match via IncludeExcludePredicate is a behavioural change for auto-configuration users. Config values containing glob-special characters (?, [, ]) would now be interpreted as patterns instead of literal key names. I think it's unlikely to affect anyone but worth noting it.

Deprecating the Predicate<String> constructor removes the ability to express some filtering logic options (eg startsWith). The glob pattern constructor covers common cases but isn't a full replacement. I think we should document the trade-off in the deprecation notice.

[breedx-splk]

Looks good to me. I'm not sure if this was previously covered, but if both the include and exclude are provided, and an entry matches both, which one wins out? Is there a test that shows/covers that?

[SylvainJuge]

I'm not sure if this was previously covered, but if both the include and exclude are provided, and an entry matches both, which one wins out? Is there a test that shows/covers that?

I've opened open-telemetry/opentelemetry-java#8371 to add a dedicated test for the case where both include and exclude match the provided value, the spec is quite clear in this case: when both match then the exclusion has priority and thus the value is excluded.

[jaydeluca]

@MikeGoldsmith just wanted to check in to see if you had any other concerns or if this is now good to go? thanks!

[MikeGoldsmith]

I think only thing I'd like to see is a deprecation notice for Predicate<String> to describe how it's different from the new one. They don't work the same, so we should let people know.

[SylvainJuge]

I think only thing I'd like to see is a deprecation notice for Predicate<String> to describe how it's different from the new one. They don't work the same, so we should let people know.

@MikeGoldsmith, can you clarify what and where would you like to see this added ?

• in the code examples in the readme
• in this PR description
• in the release notes
• somewhere in the javadoc comments that isn't yet covered
• all of the above

[MikeGoldsmith]

This looks good to me, thanks @SylvainJuge.

Sorry the ask for docs wasn't clear. I've left a note for where I think it would be useful. In the changelog / PR desc would also be good for easier discoverability.

[MikeGoldsmith]

Thanks @SylvainJuge 👍🏻