Uploaded image for project: 'Spring Integration'
  1. Spring Integration
  2. INT-3147

MetadataStore Key is named '(inner bean)'

    XMLWordPrintable

    Details

      Description

      While working on a Redis-based MetadataStore (INT-3085), I hit what I think is buggy behavior.

      The key for the value to be stored in the MetadataStore is in my case:

      twitter:search-inbound-channel-adapter.(inner bean).23871909
      

      The key is calculated in AbstractTwitterMessageSource#onInit(). There we create the key with (simplified):

      getComponentType() + this.getComponentName() + twitterProfileId

      This looks good but the result sucks. Users end up with getComponentName() == "(inner bean)", even though they may have declared:

      <int-twitter:search-inbound-channel-adapter id="myadapter"
      

      The id, however, is used for the SourcePollingChannelAdapter and thus unavailable for the source which ends up being named (inner bean).

      Ultimately, we end up with brittle unintuitive behavior. For example, when using 2 Twitter Searches, resulting keys may look like:

      • twitter:search-inbound-channel-adapter.(inner bean).23871909
      • twitter:search-inbound-channel-adapter.(inner bean)#2.23871909

      I see potentially 2 solutions:

      1) Name the inner bean more appropriately. We do something similar with the JPA Adapter's JPA executor bean. Maybe something along the lines of: myadapter_id.source, but this seems to be a bit more invasive.

      2) Expose a new property metadataKey, possibly even exposing it via the XML namespace.

      This issue may also affect the Feed Adapter.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              abilan Artem Bilan
              Reporter:
              hillert Gunnar Hillert
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: