[jira] [Comment Edited] (VALIDATOR-361) UrlValidator rejects new gTLDs with more than 4 characters,

["Sorin Postelnicu (JIRA)" <ji...@apache.org>]

    [ 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)