XMLWordPrintable

    • Icon: Sub-task Sub-task
    • Resolution: Fixed
    • Icon: L3 - Default L3 - Default
    • 7.15.0-alpha5, 7.15.0
    • None
    • None
    • None

      Example

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

      As-Is

      • Handler bean
      • 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

      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

        This is the controller panel for Smart Panels app

              tassilo.weidner Tassilo Weidner
              tassilo.weidner Tassilo Weidner
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: