[jira] Resolved: (VALIDATOR-218) UrlValidator fail when path contains "(" / ")"
[
https://issues.apache.org/jira/browse/VALIDATOR-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Speakmon resolved VALIDATOR-218.
Resolution: Fixed
Fixed in the new UrlValidator:
$ svn ci
Sending
src/main/java/org/apache/commons/validator/routines/UrlValidator.java
Sending
src/test/java/org/apache/commons/validator/routines/UrlValidatorTest.java
Transmitting file data ..
Committed revision 590915.
> UrlValidator fail when path contains "(" / ")"
> --
>
> Key: VALIDATOR-218
> URL: https://issues.apache.org/jira/browse/VALIDATOR-218
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.3.1 Release
> Environment: JDK 1.5, Linux
>Reporter: Stephen Chu
>Assignee: Niall Pemberton
> Fix For: 1.4
>
>
> for validating the URL "http://somewhere.com/pathxyz/file(1).html", it
> returns false.
> According to the RFC,
> uric = reserved | unreserved | escaped
> reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
> "$" | ","
> unreserved= alphanum | mark
> mark = "-" | "_" | "." | "!" | "~" | "*" | "'" |
> "(" | ")"
> "(", ")" belongs to mark and is a valid part of uric.
> Test case:
> UrlValidator validator = new UrlValidator({"http","https"},
> UrlValidator.ALLOW_2_SLASHES);
> validator.isValid("http://somewhere.com/pathxyz/file(1).html");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-230) Enum validator
[ https://issues.apache.org/jira/browse/VALIDATOR-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539286 ] Ben Speakmon commented on VALIDATOR-230: Attachment still forthcoming? :) > Enum validator > -- > > Key: VALIDATOR-230 > URL: https://issues.apache.org/jira/browse/VALIDATOR-230 > Project: Commons Validator > Issue Type: New Feature >Reporter: Paul Benedict > Fix For: 1.4 > > > An "enum" validator which validates a value is member of an Commons Enum type > or JDK5 type. Attachment forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-242) Move EmailValidator to routines package
[ https://issues.apache.org/jira/browse/VALIDATOR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon resolved VALIDATOR-242. Resolution: Fixed Move completed, tests ready, and refactoring done, so this is done. > Move EmailValidator to routines package > --- > > Key: VALIDATOR-242 > URL: https://issues.apache.org/jira/browse/VALIDATOR-242 > Project: Commons Validator > Issue Type: Task > Components: Framework, Routines >Affects Versions: 1.3.1 Release >Reporter: Ben Speakmon >Assignee: Ben Speakmon > Fix For: 1.4 > > > Move EmailValidator and associated tests to the routines package as part of > its refactoring. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-243) Create standalone domain validator routine
[ https://issues.apache.org/jira/browse/VALIDATOR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon resolved VALIDATOR-243. Resolution: Fixed DomainValidator is complete and Email/UrlValidator are using it, so this is done. > Create standalone domain validator routine > -- > > Key: VALIDATOR-243 > URL: https://issues.apache.org/jira/browse/VALIDATOR-243 > Project: Commons Validator > Issue Type: Task > Components: Routines >Reporter: Ben Speakmon >Assignee: Ben Speakmon > Fix For: 1.4 > > > Since EmailValidator and UrlValidator both need domain name validation, and > since that logic is currently duplicated between them, that logic should be > factored out into a standalone routine for reuse by all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-216) UrlValidator rejects top-level domains (TLDs) with more than 4 characters
[ https://issues.apache.org/jira/browse/VALIDATOR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon resolved VALIDATOR-216. Resolution: Fixed This has been addressed in the new UrlValidator. I chose not to use the interface constant pattern as suggested, as that's frowned upon; rather, the domains are stored in private static final List fields inside UrlValidator for maximum flexibility. We will need to update UrlValidator as new domains comes out in any case, but since that happens only every couple of years, a configurable TLD mechanism seemed like overkill. > UrlValidator rejects top-level domains (TLDs) with more than 4 characters > - > > Key: VALIDATOR-216 > URL: https://issues.apache.org/jira/browse/VALIDATOR-216 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.3.1 Release >Reporter: Kenji Matsuoka >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: TLDConstants.java > > > org.apache.commons.validator.UrlValidator#isValidAuthority rejects top-level > domains (TLDs) with more than four characters. There are now at least two > TLDs with more characters, .museum and .travel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-220) EmailValidator fails with ArrayIndexOutOfBoundsException on domain names longer than 10 segments
[ https://issues.apache.org/jira/browse/VALIDATOR-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon resolved VALIDATOR-220. Resolution: Fixed Resolving since the new EmailValidator is complete and is verified not to suffer from this issue. > EmailValidator fails with ArrayIndexOutOfBoundsException on domain names > longer than 10 segments > > > Key: VALIDATOR-220 > URL: https://issues.apache.org/jira/browse/VALIDATOR-220 > Project: Commons Validator > Issue Type: Bug > Components: Framework >Affects Versions: 1.3.0 Release, 1.3.1 Release > Environment: $ uname -a > Linux frisky 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 > GNU/Linux >Reporter: Adam Gordon >Assignee: Niall Pemberton > Fix For: 1.4 > > > The EmailValidator class, specifically, the "protected boolean > isValidSymbolicDomain(String domain)" method makes an assumption on the PERL > RegEX rules, specifically, that no more than 10 domains/subdomains may be > specified in an email address. I.e. an email address of "[EMAIL PROTECTED]" > is valid according to the EmailValidator whereas an email address of "[EMAIL > PROTECTED]" causes isValidSymbolicDomain(String) to throw an > ArrayIndexOutOfBoundsException because the "domainSegment" local variable is > hard-coded to have a length of 10. > Whether or not this is due to a limitation in PERL w.r.t. the maximum number > of allowed groupings, I do not know, but the RFC for email addresses does not > appear to specify a maximum number. Additionally, although I couldn't find > it in the RFC, Wikipedia says that the maximum number of characters for the > domain name is 255 - though I am very hesitant to cite/use Wikipedia as an > official source... > Granted, I've never seen a domain name w/ more than 5 subdomain names, let > alone 10, but it seems like it should be supported regardless. > I'd submit a patch, but I wanted to discuss possible courses of action and > determine the "right" (or at least acceptable) one. Possible solutions are: > 1. check if the counter i in the for loop is > 10 and perform some action > that stops the iterative process. > 2. if the max number of groupings in PERL RegEX is 10, maybe we shouldn't > use RegEX to determine the groupings. > 3. if, per the RFC, the max number of domain name groupings is 10, then the > code should check for this. > Please let me know if you 1) have an alternative solution and 2) want me to > code a/the fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-241) New InetAdress Validator implementation
[ https://issues.apache.org/jira/browse/VALIDATOR-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon resolved VALIDATOR-241. Resolution: Fixed Fixed the svn props and completed the refactorings of other classes to use it, so this is ready to be resolved. > New InetAdress Validator implementation > --- > > Key: VALIDATOR-241 > URL: https://issues.apache.org/jira/browse/VALIDATOR-241 > Project: Commons Validator > Issue Type: New Feature > Components: Routines >Reporter: Niall Pemberton >Assignee: Ben Speakmon > Fix For: 1.4 > > > Create a new InetAdress validator implementation. The existing email and url > validators duplicate this functionality. Refactoring it into a separate > validator means that it can be re-used by both those implementations and also > provides another useful validator implementation to the users. > See http://svn.apache.org/viewvc?view=rev&revision=585762 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VALIDATOR-244) Validator post-processing
Validator post-processing
-
Key: VALIDATOR-244
URL: https://issues.apache.org/jira/browse/VALIDATOR-244
Project: Commons Validator
Issue Type: New Feature
Components: Framework
Reporter: Paul Benedict
Fix For: 1.4
A new feature in Struts 1.4 is the ability to post-process the configuration
before it is set. I believe the Validator Framework should allow the same. As a
benefit, a developer could code substitution variables -- ${variable-name} --
and then read them in from a property file or database. This would allow easy
aligning with data constraints that are already in place but in a remote
resource.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: unsubscribe
See this page for correct way to unsubscribe (issues list is towards the end): http://commons.apache.org/mail-lists.html -Rahul
[jira] Commented: (COLLECTIONS-251) Replace getInstance() and decorate() methods with get{ClassName}()
[
https://issues.apache.org/jira/browse/COLLECTIONS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539083
]
Stephen Colebourne commented on COLLECTIONS-251:
I would suggest not using the get prefix.
. getInstance()
would thus become
. truePredicate()
(This fits well with the current direction on JSR-310 and Joda-Time. I don't
think that the Sun APIs have an opinion on this yet.)
> Replace getInstance() and decorate() methods with get{ClassName}()
> --
>
> Key: COLLECTIONS-251
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-251
> Project: Commons Collections
> Issue Type: Improvement
> Components: Bag, BidiMap, Buffer, Collection, Comparator, Core,
> Functor, Iterator, KeyValue, List, Map, Set
>Affects Versions: Generics
>Reporter: Stephen Kestle
> Fix For: Generics
>
>
> Commons Collections uses the singleton "getInstance()" pattern and extends it
> to allow parameters etc to be passed in. decorate() serves a similar purpose.
> I propose replacing both of these with getClassName() for the following
> reasons:
> 1. Static imports would mean that TruePredicate.getInstance() would be
> replaced with getTruePredicate(). getInstance() cannot be statically
> imported, because it is reduced to one class' getInstance(), where we are
> likely using many.
> 2. It gives subclasses a way to avoid compiler issues - COLLECTIONS-243
> compile problems are generally because the compiler can't choose between
> Collection and Set. Doing this change completely avoids this issue -
> even if there is a workaround, this makes life a lot easier (different
> compilers - eclipse - will allow things that the Sun one won't).
> 2.1 Overridden and overloaded static methods are a really bad idea
> 2.2 No confusion about what class is being instantiated
> 2.3 As our methods become more useful in the generic sense, the compiler
> issues increase until you hit something that just won't work
> 3. Simple migration path - those using TruePredicate.getInstance() can switch
> to PredicateUtils.truePredicate() before updating to this version.
> 4. Allows a more consistent user environment. Following the current pattern
> means that most people will have MyTransformer.getInstance(), while using
> TransformerUtils.nopTransformer().
> Our work will be made a lot easier if we make this change.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-370) Document thread safety of classes
[ https://issues.apache.org/jira/browse/LANG-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539059 ] Sebb commented on LANG-370: --- Relevant article from Brian Goetz: Java theory and practice: Characterizing thread safety http://www.ibm.com/developerworks/java/library/j-jtp09263.html > Document thread safety of classes > - > > Key: LANG-370 > URL: https://issues.apache.org/jira/browse/LANG-370 > Project: Commons Lang > Issue Type: Wish >Reporter: Sebb > > Few if any of the LANG classes state whether they are intended to be > thread-safe or not. > As a library, such documentation is essential IMO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
