Skip to content

AnnotationFormatterFactory should support @AliasFor [SPR-14844] #19410

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Oct 25, 2016 · 1 comment
Closed
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Oct 25, 2016

Sebastian Davids opened SPR-14844 and commented

Pseudo code:

public @interface MyAnnotation {
   @AliasFor("alias")
   String value() default "";

   @AliasFor("value")
   String alias() default "not aliased";
}
public class Bean {
   @MyAnnotation("aliased")
   private String toBeAliased;
//...
}
public class MyAnnotationFormatterFactory implements AnnotationFormatterFactory<MyAnnotation> {

  public Printer<?> getPrinter(MyAnnotation annotation, Class<?> fieldType) {
      String alias = annotation.alias();
//...
}

Expectation would be alias to be "aliased" and not "not aliased".


Affects: 4.3.3

Issue Links:

Referenced from: commits 62918ca, bf9083d

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Thanks for raising this! Indeed: an unfortunate limitation, originating from the legacy annotation support in TypeDescriptor. I've revised this towards our modern-day 4.3 facilities now, with formatting annotations now being equally capable (and following the same rules) as the general composable annotation model in Spring.

As a side note, there was a backwards compatibility concern with TypeDescriptor's legacy algorithm preferring inherited annotations over locally declared composed annotations. It turns out that this would only affect lookups on a Class whereas TypeDescriptor is only designed to work against fields and method parameters, so there was no reason to hold on to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants