Inconsistent `@AliasFor` behavior

[creckord]

In one of our projects, we had an annotation declaration with meta-annotations that was missing an @AliasFor:

public abstract class CallbackListener {

    @Target({ ElementType.TYPE })
    @Retention(RetentionPolicy.RUNTIME)
    @KafkaListener(id = LISTENER_ID, idIsGroup = false)
    public @interface CallbackListenerDef {

        @AliasFor(annotation = KafkaListener.class)
        String[] topics() default {};

        // This was missing: @AliasFor(annotation = KafkaListener.class)
        String groupId() default "${spring.kafka.consumer.group-id}.callback";
    }

    @KafkaHandler(isDefault = true)
    public void executeCallback(CallbackEvent event) {
        // ...
    }

    @Service
    @Profile("!mock")
    @CallbackListenerDef(topics = TOPIC)
    public static class ProdCallbackListener extends CallbackListener {
    }

    @Service
    @Profile("mock")
    @CallbackListenerDef(topics = TOPIC_MOCK, groupId = "${spring.kafka.consumer.group-id}.callback-mock")
    public static class MockCallbackListener extends CallbackListener {
    }
}

Note the missing @AliasFor on groupId.

In Spring Boot 3.5 / Spring Core 6.2, this magically worked anyway, and we got listeners with group.id app.callback and app.callback-mock depending on the deployment's active profile.

In Spring Boot 4 / Spring Core 7.0.6, this broke in a fun and unexpected way: The ProdCallbackListener got its group.id set to app.callback via the default value of our annotation, whereas the explicit groupId on MockCallbackListener caused the whole thing to be ignored and it ended up with the global default group.id of just app.

I would have expected that this behaved consistently, i.e. either disregarding the non-aliased groupId entirely, or applying it in both cases.

[sbrannen]

Hi @creckord,

Congratulations on submitting your first issue for the Spring Framework! 👍

Support for convention-based annotation attribute overrides was officially deprecated in Spring Framework 6.0 in favor of @AliasFor.

And that support was completely removed in Spring Framework 7.0.

• Deprecate convention-based annotation attribute overrides in favor of @AliasFor #28760
• Remove convention-based annotation attribute override support #28761

Since 6.0, you should have seen WARN messages in your log output (see commit a68f5b1).

Thus, it would appear that your team somehow overlooked those warnings.

In light of the above, I am closing this issue.

However, if you determine that something behaves in a manner inconsistent with #28760 and #28761, please post back here with further details and examples.

Thanks

[creckord]

@sbrannen sorry for being unclear. I am all for removing convention-based overrides. What this issue was about is that it wasn't removed consistently, but that the convention-based override still happened in one case and not in the other.

[sbrannen]

Hi @creckord,

If you would like me to look into this further, please provide a simplified example that demonstrates the issue (something that I can download and run locally), including the exact mechanisms you use to look up the annotations (e.g., exact use of the MergedAnnotations API, use of AnnotetedElementUtils, etc.).

If you can reproduce all of that within a single test class, even better!