-
Bug
-
Resolution: Fixed
-
High
-
2.2.1
-
None
-
Confluence 3.5-beta2
See CONFDEV-3172 for details.
When migrating Confluence from 3.4 to 3.5, the Application object is created and cached as an ImmutableApplication. Later, atlassian-user.xml is processed and the Application object updated. The problem is that in CrowdDirectoryServiceImpl.setConnectionPoolProperties, the code attempts to modify the "attributes" property of the Application, and attributes is a com.google.common.collect.ImmutableMap.
The simple solution is to not refer to the original Application object in setConnectionPoolProperties after a mutable copy is made via ApplicationImpl.newInstance.
In fact, most code calling ApplicationImpl.newInstance has the potential for the same problem - the pattern is to retrieve an Application object for the sole purpose of passing it to ApplicationImpl.newInstance, but the reference is kept in the block waiting for someone to accidentally use it.
Might be handy to create a helper method that gets and clones the Application for you...
For now, this bug will be fixed by changing:
Application application = getApplication(); ApplicationImpl template = ApplicationImpl.newInstance(application); Map<String, String> attributes = application.getAttributes(); attributes.putAll(poolProperties.toPropertiesMap()); template.setAttributes(attributes);
to
ApplicationImpl template = ApplicationImpl.newInstance(getApplication()); template.getAttributes().putAll(poolProperties.toPropertiesMap());