openmrs
TRUNK-6192: Fix bug related to continuous listener additions
Description of what I changed
Issue I worked on
see https://issues.openmrs.org/browse/TRUNK-6192
Checklist: I completed these to help reviewers :)
-
[x] My IDE is configured to follow the code style of this project.
-
[x] I have added tests to cover my changes. (If you refactored existing code that was well tested you do not have to add tests)
-
[x] I ran
mvn clean packageright before creating this pull request and added all formatting changes to my commit. -
[x] All new and existing tests passed.
-
[x] My pull request is based on the latest changes of the master branch.
Sorry I missed the notification here @mogoodrich. The challenge in that approach is, since the NameSupport.java is a Spring bean that's instantiated once, it would then miss an initialisation involving the custom configured template if one existed. This mean that the custom configured template would only come into effect only after its global property has been added/updated which, 99% won't happen.
An alternative approach was to make the list of listeners a Set.
Interesting @Ruhanga , you mean because the Name Support bean could be initialized before the Admin Service is ready? What makes this different from the AddressSupport template that appears to do the same thing?
The AddressSupport template is not a Spring bean actually. It gets instantiated if not at the first call to getInstance().
@Ruhanga If the issue is that it's a Spring bean, couldn't we take advantage of that to have it call init() as either a Spring initializer or @PostConstruct or similar and skip having to call init() in every call to getInstance()?
Closing this in favour of this commit here:
https://github.com/openmrs/openmrs-core/commit/e878c6389843cb052b4d158afac2582112312939