Previously

• Annotation configuration objects were looked up via AnnotationMetadata#getAnnotationAttributes and converted to AnnotationAttributes which helps to get attributes in a type-safe fashion (e.g., annotationAttributes.getString("baseUrl"))
• This is not ideal from a maintenance perspective since the attribute names and types need to be specified at multiple places:
  • when defining the annotation attribute
  • when retrieving the value of the attribute from the annotation configuration object (hardcoded)
  • when passing the property to the bean definition (hardcoded)

Solution Idea

• The annotation configuration is mapped to the respective annotation type (see AnnotationUtil)
• There exists a ClientConfiguration and SubscriptionConfiguration type the annotation configuration objects are mapped to
• The client configuration object is passed to the bean definition instead of each single property

Pros

Maintenance of the client is improved significantly, e.g., when exposing a new configuration property to the Spring Boot Client.

Cons

When constructing the bean definition out of every single property, property placeholders are automatically resolved. This allows storing the client configuration in a *.properties file. This does not work out of the box when passing an object holding all properties. However, I reintroduced the resolution in the ClientFactory for all string-based properties.

Decision

• Hardcoded attribute names at multiple places are error-prone when introducing new configuration options
• Only for the client configuration: with the solution idea, a developer might miss adding the resolve method to a string-based client configuration option
• Compared with the risk that a property does not work at all (previous situation), I think it is acceptable if a new string-based property cannot be resolved via *.properties file; the user can still define the property in the annotation
  • Also, this problem only exists for spring-only users and not for spring boot users => works for both spring boot as well as spring-only users
• Weighting the implications, I would go for the proposed solution idea to make the spring client more robust when it comes to extending it