-
Notifications
You must be signed in to change notification settings - Fork 37.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alias resolution in SimpleAliasRegistry
depends on hash codes of alias values
#32024
Comments
SimpleAliasRegistry
depends on hash codes of alias String
valuesSimpleAliasRegistry
depends on hash codes of alias values
Current proposal for a fix can be viewed in the following feature branch. |
For anyone reading this issue and wondering how that can happen, the simplest analogy I can come up with is the standard @Test
void swap() {
String aliasX = "bean1";
String aliasY = "bean2";
String temp = aliasX;
aliasX = aliasY;
aliasY = temp;
assertThat(aliasX).isEqualTo("bean2");
assertThat(aliasY).isEqualTo("bean1");
} The swap works if And that's effectively what can happen currently in |
SimpleAliasRegistry
depends on hash codes of alias valuesSimpleAliasRegistry
depends on hash codes of alias values
Overview
As discussed in commit 5d309d5, alias resolution in
SimpleAliasRegistry.resolveAliases()
currently depends on the iteration order of map entries in thealiasMap
which is aConcurrentHashMap
.In other words, the order in which aliases are processed depends on their hash code values.
This results in different behavior for the same set of logical alias pairs if the names of some of the aliases are changed in such a way that their hash codes result in a different iteration order for the
aliasMap
.For example, given an existing, working application that relies on aliases and placeholder replacement for such aliases, simply changing the name of one of those aliases may result in failure to start the application.
Possible Solutions
Using a
LinkedHashMap
foraliasMap
andaliasCopy
ensures alias processing in the order in which aliases were registered.However, we currently use a
ConcurrentHashMap
foraliasMap
, so we would need to wrap that inCollections.synchronizedMap()
. That works, but we may not want to use a synchronizedLinkedHashMap
for thealiasMap
in general.Thus, another possibility proposed by @jhoeller is to track the names of registered aliases separately:
Related Issues
SimpleAliasRegistryTests
#31353The text was updated successfully, but these errors were encountered: