[ 
https://issues.apache.org/jira/browse/VALIDATOR-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14487677#comment-14487677
 ] 

Sorin Postelnicu edited comment on VALIDATOR-361 at 4/9/15 5:12 PM:
--------------------------------------------------------------------

By inspecting the source code of DomainValidator (which is the common component 
for validating domain names, used by UrlValidator and EmailValidator), we can 
see the following possibilities for improvement:

1) The list of generic TLDs is hard-coded in the source, which is not very 
feasible: Every time the list of generic TLDs is updated by ICANN, the 
commons-validator library needs to be updated.

2) The class is defined as a singleton with a private constructor, so this 
makes it difficult for a programmer (encountering this problem) to subclass it 
and override the isValidGenericTld() to bypass the problem.

3) The first and most simple improvement is to replace the private constructor 
with a protected constructor (similar to the one in EmailValidator):
{code}
    /**
     * Protected constructor for subclasses to use.
     *
     * @param allowLocal Should local addresses be considered valid?
     */
    protected DomainValidator(boolean allowLocal) {
       this.allowLocal = allowLocal;
    }
{code}

4) The next step for improvement would be to extract the hard-coded list of 
domains to a separate class called DomainValidatorGenericTldsLoader. Preferably 
this would be an interface, with the most simple implementation 
(DomainValidatorGenericTldsLoaderHardCodedImpl) being the current hard-coded 
list of values.

5) The next step for improvement would be to extract the list of generic TLDs 
into a separate file (possibly a .txt file located in the classpath at 
/org/apache/commons/validator/routines/DomainValidatorGenericTLDs.txt), and 
then to load (and sort) the list of domains in another implementation of the 
DomainValidatorGenericTldsLoader interface, that will be called when 
DomainValidator is initialized.

6) And another possibility is also to replace the singleton pattern with a 
Dependency-Injection pattern, in which the DomainValidatorGenericTldsLoader is 
injected by the user of the DomainValidator, with the possibility to use any 
implementation (DomainValidatorGenericTldsLoaderHardCodedImpl, 
DomainValidatorGenericTldsLoaderTextFileImpl, or any custom implementation).



was (Author: sorin_postelnicu):
By inspecting the source code of DomainValidator (which is the common component 
for validating domain names, used by UrlValidator and EmailValidator), we can 
see the following possibilities for improvement:

1) The list of generic TLDs is hard-coded in the source, which is not very 
feasible: Every time the list of generic TLDs is updated by ICANN, the 
commons-validator library needs to be updated.

2) The class is defined as a singleton with a private constructor, so this 
makes it difficult for a programmer (encountering this problem) to subclass it 
and override the isValidGenericTld() to bypass the problem.

3) The first and most simple improvement is to replace the private constructor 
with a protected constructor (similar to the one in EmailValidator):
    /**
     * Protected constructor for subclasses to use.
     *
     * @param allowLocal Should local addresses be considered valid?
     */
    protected DomainValidator(boolean allowLocal) {
       this.allowLocal = allowLocal;
    }

4) The next step for improvement would be to extract the hard-coded list of 
domains to a separate class called DomainValidatorGenericTldsLoader. Preferably 
this would be an interface, with the most simple implementation 
(DomainValidatorGenericTldsLoaderHardCodedImpl) being the current hard-coded 
list of values.

5) The next step for improvement would be to extract the list of generic TLDs 
into a separate file (possibly a .txt file located in the classpath at 
/org/apache/commons/validator/routines/DomainValidatorGenericTLDs.txt), and 
then to load (and sort) the list of domains in another implementation of the 
DomainValidatorGenericTldsLoader interface, that will be called when 
DomainValidator is initialized.

6) And another possibility is also to replace the singleton pattern with a 
Dependency-Injection pattern, in which the DomainValidatorGenericTldsLoader is 
injected by the user of the DomainValidator, with the possibility to use any 
implementation (DomainValidatorGenericTldsLoaderHardCodedImpl, 
DomainValidatorGenericTldsLoaderTextFileImpl, or any custom implementation).


> UrlValidator rejects new gTLDs with more than 4 characters, 
> ------------------------------------------------------------
>
>                 Key: VALIDATOR-361
>                 URL: https://issues.apache.org/jira/browse/VALIDATOR-361
>             Project: Commons Validator
>          Issue Type: Bug
>    Affects Versions: 1.4.1 Release
>            Reporter: Hiroyuki, Ohnaka
>
> org.apache.commons.validator.UrlValidator#isValid rejects TLD more than 4 
> characters.(for example,  http://hello.tokyo/ )
> A lot of new gTLDs has more than 4 characters(  
> http://www.icann.org/registries/listing.html ), and these domains cannnot 
> pass URL validation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to