Shouldn't this be rather getWildcardValue? It's a value of the <wildcard>, not name (which may imply a key), no?

Works to me. It's up to our consensus.

Updated

Iterating through all options is not ideal. Though I don't have a better idea to do this. Maybe @shawkins will.

Unforuntately I don't think there's a better way to do this currently. As long as this is only getting resolved when the tracing-headers quarkus property is requested, it shouldn't be too bad. @mabartos how many time do you see this method hit? Is it erroneously being validated for example.

I double-checked it and I can confirm it's evaluated only once per startup - when the quarkus.otel.exporter.otlp.traces.headers is requested (on the Quarkus side).

The only other approach I could imagine would be to add an aggregation routine to validation. That is for propertymappers marked as aggregates, call them with each key value pair during the validation routine, and then some final compute / save method. To have that survive the cutover to the quarkus classloader would probably mean storing it as a system property.

That would keep the iterations down to a single time, but adds a good bit of complexity. So we'll hold off on doing that until there seems to be an actual performance hit.

I'd be maybe more explicit in the naming here. Maybe isKcOrQuarkusWildcardOption? "External" would suggest we're looking for Quarkus options only.

Good point. I updated the code and now using isWildcardOption() and isKcWildcardOption() that should be sufficient for the required use cases.

If a method is used exclusively internally to WildcardPropertyMapper, could we start with it there? As much as possible I'd like to encapsulate the wildcard logic.

@shawkins Unfortunatelly, it's not used only internally in the WildcardPropertyMapper. I'd like to have some unified approach on how to do the basic ops with wildcard options. So, the util class seems fine to me as it'd be needed in the config-api module. I'd like to also use some parts in the #43542

@shawkins Unfortunatelly, it's not used only internally in the WildcardPropertyMapper.

It just looked like some of the methods weren't used in other places yet. If there are other plans to expand the usage a util class seems fine, but I'd still vote for keeping it to the minimum number of methods.

Ok, works for me. I'll try to minimize util methods

@shawkins I tried to find some reasonable balance on what will be part of the wildcard options util class and I think all these methods belongs together as it's suggested that you first ask whether it's a wildcard option and then do some operations on the wildcard option.

Is it ok for you to leave it as is, or do you suggest any better approach?

Are you sure we can make this assumption in general?

@shawkins Why not? We've said the proper KC wildcard option needs to have the wildcard (variable segment) at the end. And the described method shows how is it evaluated as it's only for cases without the resolved name; only for properties with the < and > chars.

Do you have any concern?

My concern was specifically with "quarkus..end" as that seems to be mixing both qualified and unqualified keys - if we expect quarkus., shouldn't all of them something like kc. or smallrye.?

Then are we sure that quarkus options cannot end with a wildcard, and will always have ".end"?

I kept only the isWildcardOption method that only check if the property contains the variable segment (< and >)

@shawkins WDYT?