Improve handler bean and subscription bean naming conventions

Example

@ExternalTaskSubscription("topic-name")
@Bean
public ExternalTaskHandler handler() {
  return (externalTask, externalTaskService) -> {
  };
}

As-Is

• Handler bean
  • Spring's naming convention
  • Example: handler
• Subscription bean
  • Handler bean name + "Subscription"
  • Example: handlerSubscription

Pros

• Handler bean must be exposed explicitly by the user who would expect with pure spring knowledge that the bean name of the handler is defined according to Spring's naming convention

Cons

• If multiple subscription beans are available and the user wants to get one specific subscription, they must know the naming convention of the subscription bean
• The requirement to auto-wire the handler bean might be artificial

Change Proposal 1

• Handler bean
  • Spring's naming convention + "-handler"
  • Example: handler-handler

Pros

• We can reuse the handler bean name for the subscription bean (cf. "Change Proposal 3")
• The requirement that the handler bean is auto-wired is artificial, so it is okay if the bean name differs from Spring's naming convention

Cons

• We change Spring's naming convention, which could lead to confusion if a user wants to auto-wire the handler

Change Proposal 2

• Subscription bean
  • Topic Name
  • Example: topic-name

Pros

• A user wants to auto-wire the subscription bean to open a subscription or to read information about it, so it makes sense that the subscription bean has an easy to remember naming convention like the topic name

Cons

• When we introduce multi-client support later, there might be multiple subscription beans for different clients but the same topics which would then have the same names; this is technically not possible

Change Proposal 3

• Subscription bean
  • Handler bean name
  • Example: handler

This change proposal is only possible when the handler bean name is changed as well (cf. "Change Proposal 1").

Pros

• The user has full control of the subscription bean name
• When we add multiple client support, there is no bean name collision (cf. "Change Proposal 2")

Cons

• The handler bean name does not follow Spring's naming convention, which might be confusing for the user
• It might be confusing for the user that the handler bean name is assigned to the subscription bean