MetadataStore Key is named '(inner bean)' [INT-3147]

[spring-operator]

Gunnar Hillert opened INT-3147 and commented

While working on a Redis-based MetadataStore (#7067), 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)modified text (testing) #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.

---

Affects: 3.0 M3

Issue Links:

• Allow the twitter adapter to support a variable search query in configuration through an SpEL expression. [INT-2789] #6740 Allow the twitter adapter to support a variable search query in configuration through an SpEL expression.
  ("is depended on by")

• Doc: Add dedicated MetadataStore Chapter [INT-3148] #7121 Doc: Add dedicated MetadataStore Chapter
  ("is depended on by")

• Make MetadataStores dynamically resettable on a per component bassis [INT-1941] #5922 Make MetadataStores dynamically resettable on a per component bassis
  ("is depended on by")

• Twitter: Make minimum wait between polls configurable [INT-3167] #7143 Twitter: Make minimum wait between polls configurable
  ("is depended on by")

• Inbound Channel Adapter Parser doesn't generate unique bean Id for MessageSources [INT-3240] #7153 Inbound Channel Adapter Parser doesn't generate unique bean Id for MessageSources

• Add a Redis-backed MetadataStore [INT-3085] #7067 Add a Redis-backed MetadataStore

• Add support explicit MetadataStore declarations instead of (or in addition to) a global one [INT-3173] #7150 Add support explicit MetadataStore declarations instead of (or in addition to) a global one

[spring-operator]

Artem Bilan commented

IMO its' not a bug: it's new feature, which we provide for end-users with presistent MetadaStore.
So, as far as we have a property metadataKey it may be posible simply set it within parse phase, based on provided adapter's 'id' and his type.
Another option: just introduce a metadata-key attribute, similar to message-store.

Regarding myadapter_id.source - also good idea: similar to handler's alias. But it is separate JIRA. However we can use it for metadataKey as well, of course, if end-user didn't provide his own metadata-key.

BTW, re. JPA: we have an issue with 'Dangling' Bean Definitions (#6984). So, I will insist on changing JPA parser to use BeanDefinitionHolder without registration JpaExecutor beans. The same to StoredProcExecutor.

[spring-operator]

Gunnar Hillert commented

Also add a note to the reference doc

[spring-operator]

Gunnar Hillert commented

Interestingly the Feedadapter is appending the feedUrl to the metadatastore key - that could be problematic if somebody wants to create a JDBC-backed MetadataStore.

e.g.:

feed:inbound-channel-adapter.(inner bean).file:src/test/java/org/springframework/integration/feed/sample.rss

[spring-operator]

Gunnar Hillert commented

As a solution, we will expose the source as a dedicated bean using the bean name myadapter_id.source. This will also help with exposing properties of the sources via JMX.

[spring-operator]

Gunnar Hillert commented

PR: #910

[spring-operator]

Artem Bilan commented

Fresh PR :#928