[ https://issues.apache.org/jira/browse/VALIDATOR-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steven Sheehy reopened VALIDATOR-427: ------------------------------------- I respectfully disagree and would appreciate some discussion on it before dismissing it out of hand. - This issue ended up causing a NoClassDefFoundError in production since we were initializing updateTLDOverride in a static initializer and some other code was calling getInstance() before that code was called. This is a serious issue that deserves some thought. - To your point about confusion after changing them, there would be no confusion since the developer is the one that changed that and would expect the result to change. - What about the use case where the end user would want to add some custom domains dynamically via a UI? We have large enterprise customers who pick non-standard local TLDs and right now we're having to hardcode them. - There are simply times when we cannot guarantee updateTLDOverride() is called first. Where would you suggest we call updateTLDOverride() to ensure that it is called first in a series of JUnit tests? The order JUnit runs tests is random and there is no concept of "execute this code before all tests" in JUnit. Or what about if a library I wrote depended upon updateTLDOverride() and had multiple classes that served as entry points, where would I initialize it there? - The inUse flag serves no synchronization purpose, only an arbitrary technical requirement that TLDs can never be set after getInstance(). > Race Condition in DomainValidator > --------------------------------- > > Key: VALIDATOR-427 > URL: https://issues.apache.org/jira/browse/VALIDATOR-427 > Project: Commons Validator > Issue Type: Bug > Affects Versions: 1.6 > Reporter: Steven Sheehy > > There's a race condition in DomainValidator which causes our application to > fail sometimes. The issue occurs when the DomainValidator.getInstance() is > called before we can call DomainValidator.updateTLDOverride() and we receive > a IllegalStateException("Can only invoke this method before calling > getInstance"). In a multi-threaded environment, DomainValidator.getInstance() > can be called at any time and it is difficult to find a location in > application startup which ensures DomainValidator.updateTLDOverride() is > called before to initialize it. I was able to workaround during application > runtime it by placing the initialization in a Spring @Configuration class, > but there is no proper location in JUnit tests which can be called before any > tests run. > Therefore, I think the proper approach to address this is to allow > DomainValidator.updateTLDOverride() to be updated at any time including after > calls to getInstance(). Examining the source, I see that the both methods are > synchronized and that the custom TLD arrays are all volatile. Therefore, > assuming Java 1.5 or greater and its guarantees about volatile assignments, > the code already guarantees proper synchronization for the TLD plus arrays > and the inUse flag is not needed and can be removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)