Enhance Consistency in resolveTopicArn() Method for Handling "arn:" Prefixes in SNS

[Seongju-Lee]

Type: Feature

Is your feature request related to a problem? Please describe.

I would like to suggest something related to Topic ARN processing on SNS. In the process of sending the Sns message, the flow of fetching the Arn object is as follows:

1. CachingTopicArnResolver.resolveTopicArn() is responsible for ARN caching, where if the topic string is not in the cache map or starts with "arn:", it create an ARN object through DefaultTopicArnResolver.

2. In DefaultTopicArnResolver.resolveTopicArn(), if the topic parameter starts with "arn:", it converts the string into an Arn object and returns it directly; otherwise, it creates a topic and returns Arn.

If "arn:" is not prefixed in this method(DefaultTopicArnResolver.resolveTopicArn()), no exception occurs because it automatically creates a topic or returns an existing Arn.
On the other hand, if it start with "arn:", it return Arn immediately, so if it input an ARN for a non-existent topic, an exception will occur.
I believe that the DefaultTopicArnResolver.resolveTopicArn() method is not being handled consistently.

Describe the solution you'd like

I would like to improvement the TopicArnResolver.resolveTopicArn() to ensure that the resolveTopicArn() method handles consistently, regardless of whether or not the prefix "arn:".

Additionally, the CachingTopicArnResolver.resolveTopicArn() method will also be modified to support this approach.
For example, CachingTopicArnResolver.resolveTopicArn() will be modified as follows.

@Override
public Arn resolveTopicArn(String topicName) {
    Assert.notNull(topicName, "topicName is required");

    if (topicName.toLowerCase().startsWith("arn:")) {
        Arn arn = delegate.resolveTopicArn(topicName);
        Arn startIndex = ...  // extract topicName start Index in ARN
        return cache.computeIfAbsent(topicName.substring(startIndex), delegate::resolveTopicArn);
    }

    return cache.computeIfAbsent(topicName, delegate::resolveTopicArn);
}

Additional context

This proposal is expected to contribute significantly to increasing functional consistency!! :)