[jira] Commented: (LANG-360) Why does appendIdentityToString return null?
[ https://issues.apache.org/jira/browse/LANG-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539896 ] Henri Yandell commented on LANG-360: Brain kicks in Also, I wouldn't expect: ObjectUtils.appendIdentityToString(buffer, param1) .appendIdentityToString(buffer, param2) .appendIdentityToString(buffer, param3); to even compile. A StringBuffer is returned, not an ObjectUtils. Chaining isn't allowed here, the actual code would have been the very ugly and nested: ObjectUtils.appendIdentityToString( ObjectUtils.appendIdentityToString( ObjectUtils.appendIdentityToString(buffer, param1) , param2) , param3); However that doesn't end up with a NullPointerException. Instead you get a very nasty bug whereby if param2 is null, then you'll end up with a StringBuffer just containing the text of param3. Ideally the code should be: * public static String identityToString(Object) * public static void appendIdentityToString(StringBuffer, Object) Sod the StringBuffer creation - bet that was only there so the first method could reuse the second. The problem with that is that we don't have overloaded return types. So an alternative would be to deprecate both methods and have: * public static String identity(Object) * public static void appendIdentity(StringBuffer, Object) That would allow us to decide if we think a null Object passed in should return the String "null" or null in the first case; and result in "null" or "" in the second. Alternatively, we could go with an overload of the original name: * public static String identityToString(Object) * public static void identityToString(StringBuffer, Object) but that would make the "null" bit bad if we do it. Thoughts? > Why does appendIdentityToString return null? > > > Key: LANG-360 > URL: https://issues.apache.org/jira/browse/LANG-360 > Project: Commons Lang > Issue Type: Bug >Reporter: Jörg Gottschling > Fix For: 2.4 > > > ObjectUtils is designed to handle null imputs gracefully. But > ObjectUtils.appendIdentityToString does not. It returns null unnessecary if > you pass null als second parameter (the object to get the identity from). For > example appendIdentityToString(new StringBuffer(), null) will return null! > Which is an uncommen behaviour. Think about code like this: > ObjectUtils.appendIdentityToString(buffer, param1) > .appendIdentityToString(buffer, param2) > .appendIdentityToString(buffer, param3); > This will cause an NPE if param1 or param2 ist null. There may be other code > where a NPE will not happen, but the code is used for debugging and there > will be an unexpected or wrong output. > So you shoul return the StringBuffer which is passed in or a new one if null. > The harder question is what to do with the object. I think we should append > "null" to the StringBuffer, because this is what I would expect and what the > passed reference is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-360) Why does appendIdentityToString return null?
[ https://issues.apache.org/jira/browse/LANG-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539894 ] Henri Yandell commented on LANG-360: Prodding it more - it's "identityToString", meaning the identity toString() method; not the appending of the identity to java.lang.String. So the name makes syntactic sense - it's just confusing. > Why does appendIdentityToString return null? > > > Key: LANG-360 > URL: https://issues.apache.org/jira/browse/LANG-360 > Project: Commons Lang > Issue Type: Bug >Reporter: Jörg Gottschling > Fix For: 2.4 > > > ObjectUtils is designed to handle null imputs gracefully. But > ObjectUtils.appendIdentityToString does not. It returns null unnessecary if > you pass null als second parameter (the object to get the identity from). For > example appendIdentityToString(new StringBuffer(), null) will return null! > Which is an uncommen behaviour. Think about code like this: > ObjectUtils.appendIdentityToString(buffer, param1) > .appendIdentityToString(buffer, param2) > .appendIdentityToString(buffer, param3); > This will cause an NPE if param1 or param2 ist null. There may be other code > where a NPE will not happen, but the code is used for debugging and there > will be an unexpected or wrong output. > So you shoul return the StringBuffer which is passed in or a new one if null. > The harder question is what to do with the object. I think we should append > "null" to the StringBuffer, because this is what I would expect and what the > passed reference is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-367) FastDateFormat thread safety
[ https://issues.apache.org/jira/browse/LANG-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-367. -- Resolution: Fixed I don't think the SimpleDateFormat sharing is a problem. While it's shared between threads, only one method touches each instance of SimpleDateFormat (there are three separate pools), and each of those methods are synchronized. > FastDateFormat thread safety > > > Key: LANG-367 > URL: https://issues.apache.org/jira/browse/LANG-367 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Fix For: 2.4 > > Attachments: FastDateFormat.patch > > > FastDateFormat has several static HashMaps. These are currently not final, so > there is no guarantee that they will be visible to all threads. > Patch to follow. > Also, as far as I can make out, the class shares SimpleDateFormat instances > between threads. > It does not document why this is OK. > I'm guessing that it assumes that instances of the SimpleDateFormat class are > thread-safe provided that they have the same attributes, but this is not > documented. If this is the case, it's not clear that it is a valid assumption. -- 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_12539887 ] Niall Pemberton commented on VALIDATOR-230: --- My aim for the "routines" package was all the actual validation routines (i.e. no "framework") and with no dependencies outside the package. The thinking there was that we could possibly package up a "routines" jar with zero dependencies. I'm reluctant to go against that without a compelling case and IMO Apache Enums (presumably you mean Commons Lang's enum?) became yesterdays solution when JDK 1.5 arrived. On JDK 1.5 enums - Validator only just moved to a minimum dependency of JDK 1.4 (for Validator 1.4) - I'm OK with moving to JDK 1.5 for validator2, but I'd prefer Validator 1.4 was released based on JDK 1.4 (given that the last 1.3.1 release had a min. of JDK 1.3). > 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: Validator2 > > > 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] Commented: (JEXL-32) BigDecimal values are treated as Long values which results in loss of precision
[ https://issues.apache.org/jira/browse/JEXL-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539872 ] Kedar Dave commented on JEXL-32: Is this fix going to be in v1.1.1 and v2.0 or just in v2.0? Thanks, Kedar Dave > BigDecimal values are treated as Long values which results in loss of > precision > --- > > Key: JEXL-32 > URL: https://issues.apache.org/jira/browse/JEXL-32 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 2.0, 1.1 >Reporter: Kedar Dave > Fix For: 2.0, 1.1.1 > > Attachments: BigDecimal.patch_files.zip, > commons-jexl-1.1-BigDecimal.patch.jar > > > BigDecimal values are treated as Long values which results in loss of > precision. As a result, support for BigDecimal is added via this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SCXML-60) Possible race condition in AsyncTrigger
[
https://issues.apache.org/jira/browse/SCXML-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539860
]
Andy Bailey commented on SCXML-60:
--
I didnt actually observe the problem, I think you need a multiprocessor
machine for that to happen, but I thought it would be a good idea to fix
it as if it ever did happen it would be difficult to debug, and almost
impossible to reproduce.
> Possible race condition in AsyncTrigger
> ---
>
> Key: SCXML-60
> URL: https://issues.apache.org/jira/browse/SCXML-60
> Project: Commons SCXML
> Issue Type: Bug
>Affects Versions: 0.6
>Reporter: Andy Bailey
>Priority: Minor
> Fix For: 0.7
>
>
> In AsyncTrigger (used by SimpleSCXMLInvoker) a thread is started from inside
> the constuctor, because of the java memory model the fields arent guaranteed
> to be written until after the constructor ends, however the thread could
> start before this and so the values could be null.
> To be safe the class should have a start method that gets invoked after the
> constructor.
> AsyncTrigger(final SCXMLExecutor executor, final TriggerEvent event) {
> this.executor = executor;
> this.events = new TriggerEvent[1];
> this.events[0] = event;
> new Thread(this).start();
> }
> public void run() {
> try {
> synchronized (executor) {
> executor.triggerEvents(events);
> }
> } catch (ModelException me) {
> log.error(me.getMessage(), me);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBUTILS-42) Object with Long or Decimal got initial zero value while database field is null
[
https://issues.apache.org/jira/browse/DBUTILS-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539851
]
Matt Jiang commented on DBUTILS-42:
---
Hi Henri
I update the content on JIRA, please check it out.
Thanks a lot.
Matt
> Object with Long or Decimal got initial zero value while database field is
> null
> ---
>
> Key: DBUTILS-42
> URL: https://issues.apache.org/jira/browse/DBUTILS-42
> Project: Commons DbUtils
> Issue Type: Improvement
>Affects Versions: 1.1
> Environment: JDK 5.0, MSSQL 2000
>Reporter: Matt Jiang
>
> While I use dbutil1.1, I got a big different implementation betweeb 1.0 and
> 1.1.
> Given a Java object, it has a property with Long data type; mapping to
> database, its table field datatype is bigint.
> If it has a record and its value is null.
> In 1.0 implementation, if I load entity, then we can see the property in Java
> object is also null.
> But in 1.1 implementation, the Java object will got a Long object with 0
> inside.
> This behavior change does big impact if I upgrade from 1.0 to 1.1. It might
> make application logic fail because origional null status now become a
> Long(0) value to map to null value in database.
> I suggest to change it back. If null value in database, then mapped Java
> object should be null as well, not new a Long(0) to be a initial value.
> Below is the code snapshot I used to execute query, and I use jTDS 1.2 as
> JDBC driver
> public List executePreparedQuery(String sql, Object[] params, Class clazz)
> throws SQLException {
>
> Connection cnct = getConnection();
> QueryRunner qRunner = new QueryRunner();
> ResultSetHandler rsHandler = new BeanListHandler(clazz);
> List entities = null;
> try {
> convertDateIn(params);
> entities = (List) qRunner.query(cnct, sql, params, rsHandler);
> }
> catch (SQLException e) {
> e.printStackTrace();
> throw e;
> }
> finally {
> closeConnection();
> }
> return entities;
> }
> Hope this helps.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-171) Improve MVSFTPEntryParser.java
[ https://issues.apache.org/jira/browse/NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539830 ] henrik sorensen commented on NET-171: - where is it broken ? Which version of commons.net are you using. Henrik > Improve MVSFTPEntryParser.java > -- > > Key: NET-171 > URL: https://issues.apache.org/jira/browse/NET-171 > Project: Commons Net > Issue Type: Improvement > Environment: MVS FTP server >Reporter: Arno Unkrig > Attachments: FTPFileLoadlib.java, FTPFilePO.java, > FTPFilePOMember.java, MvsFTPUtil.java > > > Hi there, > the "MVSFTPEntryParser" who parses the output of an FTP LIST of an MVS FTP > server, is a sad view... it's totally broken. I developed a custom > FTPEntryParser, which I can hook into the FtpClient (thank you for the highly > customizable design). I'd like to donate it to COMMONS NET... who can I turn > to? > CU > Arno Unkrig -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCI-54) Some good example of using JCI APIs
[ https://issues.apache.org/jira/browse/JCI-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539840 ] Yuanle Cai commented on JCI-54: --- Hi Torsten, Thanks for your reply. Actually I checked all the examples you had. No doubt that they are good examples,:) My proposal is to have a simpler and easier example/tutorial. For example, what about having an example without considering cli API and servlet stuff? Just a Hello-world style example. You show the source code of the simple program, give a snapshot of your calling this program (e.g. "java Hello-World-JCI param1 param2...") and the result (e.g. "The compilation is completed. Please find the class files under..."). For your current examples, I don't exactly how to use the programs (what should I input to make the program running and what should I expect) Maybe I am accustomed to learn from simple operations to complex ones. Anyway, this is just a suggestion, so I put it in the WISH type,:) Regards, Eric (Yuanle) Cai | Software Engineer | Fast Search & Transfer ASA | Mob: +47 4801 1136 > Some good example of using JCI APIs > --- > > Key: JCI-54 > URL: https://issues.apache.org/jira/browse/JCI-54 > Project: Commons JCI > Issue Type: Wish > Components: examples >Affects Versions: 1.0 > Environment: All operating systems >Reporter: Yuanle Cai >Assignee: Torsten Curdt > Fix For: 1.0 > > > Hi guys, > I am just finding out that you have created such a good library for java > compilers. > However, I felt really frustrated since I could not find even a simple > example of really using the API. Of course, you show three examples there, > but there is no correct input and correct output... The worst thing is that > there is no tutorial/article about JCI publicly available so that I could > not follow a simple example to start using the API. > Would you please provide a starting example with expected input and expected > output, and showing possible pitfalls during the process? I think this would > ease beginners and help extend your user base. Thanks. > Regards, > Eric -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-172) NTP client should not bind to the local port when using UDP
[ https://issues.apache.org/jira/browse/NET-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539838 ] Bob Luse commented on NET-172: -- This is from the documentation: "To use the class, merely open a local datagram socket with open and call getTime to retrieve the time. Then call close to close the connection properly. Successive calls to getTime are permitted without re-establishing a connection. That is because UDP is a connectionless protocol and the Network Time Protocol is stateless." This is wrong.? There is no need to "establish a connection" at all since UDP is connectionless and NTP is stateless.? You do not need to set up a connection and then close it.? You only need to send the packets.? All this does is slow down the initial call and cause the client to completely fail when there is an NTP Server on the same system as the client since the server will already be bound to port 123.. > NTP client should not bind to the local port when using UDP > --- > > Key: NET-172 > URL: https://issues.apache.org/jira/browse/NET-172 > Project: Commons Net > Issue Type: Bug >Affects Versions: 1.4 > Environment: Windows and Linux >Reporter: Bob Luse >Priority: Critical > > NTP client when using UDP should not bind to port 123 on the local system. > This renders the software unusable for the very common case where you also > have an NTP server running on your system. It should send to port 123 on the > server, but the client should not bind to the local port 123. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-245) SharedPoolDataSource saves wrong password forever
[
https://issues.apache.org/jira/browse/DBCP-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539844
]
Michael Drechsel commented on DBCP-245:
---
Hello Phil Steitz,
thanks for your eMail. Here a have an test case that reproduces the bug.
test case
String serverName = "localhost";
String serverDB = "localweb";
String user1 = "doris";
String password1 = "doris";
String user2 = "cramer";
String password2 = "cramer";
Connection con = null;
PGConnectionPoolDataSource ConPoolDS = new
PGConnectionPoolDataSource();
ConPoolDS.setServerName(serverName);
ConPoolDS.setDatabaseName(serverDB);
ConPoolDS.setUser(user1);
ConPoolDS.setPassword(password1);
// --
// dbcp caching via SharedPoolDataSource
// --
SharedPoolDataSource SharedDS = new SharedPoolDataSource();
SharedDS.setConnectionPoolDataSource(ConPoolDS);
SharedDS.setMaxActive(10); // 0 = no limit
SharedDS.setMaxIdle(10);
SharedDS.setMinEvictableIdleTimeMillis(1000);
SharedDS.setMaxWait(1000); // -1 = no limit
SharedDS.setTimeBetweenEvictionRunsMillis(1000);
SharedDS.setTestWhileIdle(true);
try
{
con = SharedDS.getConnection(user1, password1);
}
catch (Exception e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
try
{
con = SharedDS.getConnection(user2, "wrongpassword");
}
catch (Exception e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
try
{
// connection will fail because the wrong password is
stored in the usersKey map.
con = SharedDS.getConnection(user2, password2);
}
catch (Exception e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
steps to reproduce
The SharedPoolDataSource saves wrong password forever
1. Get a connection for user1 (use username of user1 and password of user1)
---> connection ok
2. Get a connection for user2 (use username of user2 and a wrong password) -->
connection failed
3. Get a connection for user2 (use username of user2 and password of user2) -->
connection will be failed too because the wrong password is stored in the
usersKey map.
_
> SharedPoolDataSource saves wrong password forever
> -
>
> Key: DBCP-245
> URL: https://issues.apache.org/jira/browse/DBCP-245
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.1, 1.2, 1.2.1, 1.2.2
> Environment: Use of SharedPoolDataSource see sample code
> if (privSharedDS == null)
> {
> privConPoolDS = new PGConnectionPoolDataSource();
> privConPoolDS.setServerName(privServerName);
> privConPoolDS.setDatabaseName(privServerDB);
> privConPoolDS.setUser(privUser);
> privConPoolDS.setPassword(privPassword);
> // --
> // dbcp caching via SharedPoolDataSource
> // --
> privSharedDS = new SharedPoolDataSource();
> privSharedDS.setConnectionPoolDataSource(privConPoolDS);
> privSharedDS.setMaxActive(10); // 0 = no limit
> privSharedDS.setMaxIdle(10);
> privSharedDS.setMinEvictableIdleTimeMillis(1000);
> privSharedDS.setMaxWait(1000); // -1 = no limit
> privSharedDS.setTimeBetweenEvictionRunsMillis(1000);
> privSharedDS.setTestWhileIdle(true);
> }
> // --
> // dbcp caching via SharedPoolDataSource
> // --
> tmpCon = privSharedDS.getConnection(privUser, privPassword);
>Reporter: Michael Drechsel
>Priority: Minor
> Fix For: 1.3
>
>
> The SharedPoolDataSource saves wrong password forever
> 1. Get a connection for user1 (use username of user1 and password of user1)
> ---> connection ok
> 2. Get a connection for user2 (use username of user2 and a wrong password)
> --> connection failed
> 3. Get a connection for user2 (use username of user2 and password of user2)
> --> connection will be failed too because
[jira] Commented: (NET-168) NullPointerException in TelnetClient.disconnect() while being connected
[ https://issues.apache.org/jira/browse/NET-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539808 ] Kamil commented on NET-168: --- You mean, that i connot invoke disconnect() method from another thread?? It's a little bit strange since it is no problem for java Socket to invoke close() method in that way... Regards Wiadomość Oryginalna Od: "Nathan Beyer (JIRA)" <[EMAIL PROTECTED]> Do: [EMAIL PROTECTED] Data: 28 sierpnia 2007 5:55 Temat: [jira] Commented: (NET-168) NullPointerException in TelnetClient.disconnect() while being connected > NullPointerException in TelnetClient.disconnect() while being connected > --- > > Key: NET-168 > URL: https://issues.apache.org/jira/browse/NET-168 > Project: Commons Net > Issue Type: Bug >Affects Versions: 1.4 > Environment: Debian GNU/Linux, FedoraCore, RedHat >Reporter: Kamil > > java.lang.NullPointerException > org.apache.commons.net.telnet.TelnetClient.disconnect(TelnetClient.java:125) > org.apache.commons.net.ftp.FTP.disconnect(FTP.java:397) > org.apache.commons.net.ftp.FTPClient.disconnect(FTPClient.java:590) > This exception occurs when trying to invoke myFTPClient.disconnect() method, > when ftpclient hangs for a long time and dont want to connect... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-247) Move CreditCardValidator to routines package and refactor
[ https://issues.apache.org/jira/browse/VALIDATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539783 ] Ben Speakmon commented on VALIDATOR-247: It's simple, which I'm a big fan of. The only concern I have is whether anything important is lost by treating credit cards only as validators -- will we ever need to put them in collections, associate them with names, sort them, etc. -- all the crap you want to use a full-fledged object for. I can't say something like that will definitely be required, but I can't rule it out either. I'm also wondering how easy it'll be to put JSR 303 annotations on top of this, but if it's going to be redone again for Validator 2, then no problem. My gut is saying that this is good enough and covers what people need today, and that going too overboard with it is overengineering. This works, is easy to understand, and simple to use, so I think going with it makes sense. Can you throw together tests for it? > Move CreditCardValidator to routines package and refactor > - > > Key: VALIDATOR-247 > URL: https://issues.apache.org/jira/browse/VALIDATOR-247 > Project: Commons Validator > Issue Type: Task > Components: Routines >Reporter: Ben Speakmon >Assignee: Ben Speakmon > Fix For: 1.4 > > Attachments: CreditCardValidator.java > > > Having copied CreditCardValidator to routines, it now needs to be refactored > to use CodeValidator/LuhnCheckDigit/etc. It might also make sense to break > CreditCardType out into a separate 1.4-style typesafe enum so it can be > easily converted to a real enum for Validator 2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (VALIDATOR-247) Move CreditCardValidator to routines package and refactor
[ https://issues.apache.org/jira/browse/VALIDATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539772 ] niallp edited comment on VALIDATOR-247 at 11/2/07 7:29 PM: As you mention I was thinking that the new routines version could use the new "generic" code validator for individual cards and perhaps ditch the CreditCardType interface altogether. New cards types can simply be implemented by creating a new CodeValidator instance with an appropriate regular expression rather than having to define a new CreditCardType implementation. The main (IMO) advantage though is that if someone wanted to allow separators (spaces or dashes) they can define a regular expression with the separators as a "non-capturing group" which means they get "stripped" out before the check digit validation is done - and the valdiator can return a uniform card number without separators. Attaching an option for consideration. was (Author: niallp): As you mention I was thinking that the new routines version could use the new "generic" code validator for individual cards and perhaps ditch the CreditCardType interface altogether. New cards types can simply be implemented by creating a new CodeValidator instance with an appropriate regular expression rather than having to define a new CreditCardType implementation. The main (IMO) advantage though is that if someone wanted to allow separators (spaces or dashes) they can define a regular expression with the separators as a "non-capturing group" which means they get "stripped" out before the check digit validation is done - and the valdiator can return a uniform card number without validators. Attaching an option for consideration. > Move CreditCardValidator to routines package and refactor > - > > Key: VALIDATOR-247 > URL: https://issues.apache.org/jira/browse/VALIDATOR-247 > Project: Commons Validator > Issue Type: Task > Components: Routines >Reporter: Ben Speakmon >Assignee: Ben Speakmon > Fix For: 1.4 > > Attachments: CreditCardValidator.java > > > Having copied CreditCardValidator to routines, it now needs to be refactored > to use CodeValidator/LuhnCheckDigit/etc. It might also make sense to break > CreditCardType out into a separate 1.4-style typesafe enum so it can be > easily converted to a real enum for Validator 2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-247) Move CreditCardValidator to routines package and refactor
[ https://issues.apache.org/jira/browse/VALIDATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539773 ] Niall Pemberton commented on VALIDATOR-247: --- P.S. Haven't tested the regular expressions here so it may have some glitches - I'll write tests if its agreed > Move CreditCardValidator to routines package and refactor > - > > Key: VALIDATOR-247 > URL: https://issues.apache.org/jira/browse/VALIDATOR-247 > Project: Commons Validator > Issue Type: Task > Components: Routines >Reporter: Ben Speakmon >Assignee: Ben Speakmon > Fix For: 1.4 > > Attachments: CreditCardValidator.java > > > Having copied CreditCardValidator to routines, it now needs to be refactored > to use CodeValidator/LuhnCheckDigit/etc. It might also make sense to break > CreditCardType out into a separate 1.4-style typesafe enum so it can be > easily converted to a real enum for Validator 2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (VALIDATOR-247) Move CreditCardValidator to routines package and refactor
[ https://issues.apache.org/jira/browse/VALIDATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-247: -- Attachment: CreditCardValidator.java As you mention I was thinking that the new routines version could use the new "generic" code validator for individual cards and perhaps ditch the CreditCardType interface altogether. New cards types can simply be implemented by creating a new CodeValidator instance with an appropriate regular expression rather than having to define a new CreditCardType implementation. The main (IMO) advantage though is that if someone wanted to allow separators (spaces or dashes) they can define a regular expression with the separators as a "non-capturing group" which means they get "stripped" out before the check digit validation is done - and the valdiator can return a uniform card number without validators. Attaching an option for consideration. > Move CreditCardValidator to routines package and refactor > - > > Key: VALIDATOR-247 > URL: https://issues.apache.org/jira/browse/VALIDATOR-247 > Project: Commons Validator > Issue Type: Task > Components: Routines >Reporter: Ben Speakmon >Assignee: Ben Speakmon > Fix For: 1.4 > > Attachments: CreditCardValidator.java > > > Having copied CreditCardValidator to routines, it now needs to be refactored > to use CodeValidator/LuhnCheckDigit/etc. It might also make sense to break > CreditCardType out into a separate 1.4-style typesafe enum so it can be > easily converted to a real enum for Validator 2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (VALIDATOR-247) Move CreditCardValidator to routines package and refactor
[ https://issues.apache.org/jira/browse/VALIDATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon updated VALIDATOR-247: --- Component/s: Routines > Move CreditCardValidator to routines package and refactor > - > > Key: VALIDATOR-247 > URL: https://issues.apache.org/jira/browse/VALIDATOR-247 > Project: Commons Validator > Issue Type: Task > Components: Routines >Reporter: Ben Speakmon >Assignee: Ben Speakmon > Fix For: 1.4 > > > Having copied CreditCardValidator to routines, it now needs to be refactored > to use CodeValidator/LuhnCheckDigit/etc. It might also make sense to break > CreditCardType out into a separate 1.4-style typesafe enum so it can be > easily converted to a real enum for Validator 2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VALIDATOR-247) Move CreditCardValidator to routines package and refactor
Move CreditCardValidator to routines package and refactor - Key: VALIDATOR-247 URL: https://issues.apache.org/jira/browse/VALIDATOR-247 Project: Commons Validator Issue Type: Task Reporter: Ben Speakmon Assignee: Ben Speakmon Fix For: 1.4 Having copied CreditCardValidator to routines, it now needs to be refactored to use CodeValidator/LuhnCheckDigit/etc. It might also make sense to break CreditCardType out into a separate 1.4-style typesafe enum so it can be easily converted to a real enum for Validator 2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-215) New generic CodeValidator that validates format, length and Check Digit for a code
[ https://issues.apache.org/jira/browse/VALIDATOR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539735 ] Niall Pemberton commented on VALIDATOR-215: --- I've changed this to be immutable and thread safe > New generic CodeValidator that validates format, length and Check Digit for a > code > -- > > Key: VALIDATOR-215 > URL: https://issues.apache.org/jira/browse/VALIDATOR-215 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > > Add a new generic CodeValidator that validates format, length and Check Digit > for a code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VALIDATOR-246) EmailValidator should be able to recognize and remove comments
EmailValidator should be able to recognize and remove comments -- Key: VALIDATOR-246 URL: https://issues.apache.org/jira/browse/VALIDATOR-246 Project: Commons Validator Issue Type: Improvement Components: Routines Affects Versions: 1.4 Reporter: Ben Speakmon Priority: Minor When EmailValidator was moved to routines and refactored, the functionality for removing comments from emails was also removed due to its dependence on oro and its lack of tests. It would be nice to have this redone with Java 1.4 regexps (if it's needed at all). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-242) Move EmailValidator to routines package
[ https://issues.apache.org/jira/browse/VALIDATOR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539728 ] Ben Speakmon commented on VALIDATOR-242: VALIDATOR-246 created to address the comment issue. > 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] Commented: (VALIDATOR-242) Move EmailValidator to routines package
[ https://issues.apache.org/jira/browse/VALIDATOR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539727 ] Ben Speakmon commented on VALIDATOR-242: I'd probably wind up throwing it out and starting over anyway, so getting rid of it now is fine with me. I'll do another issue for its eventual return if someone (not me) really wants to have it in there. > 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-193) Removing ORO dep. from GenericValidator
[ https://issues.apache.org/jira/browse/VALIDATOR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon resolved VALIDATOR-193. Resolution: Fixed Assignee: Ben Speakmon Resolving as discussed. > Removing ORO dep. from GenericValidator > --- > > Key: VALIDATOR-193 > URL: https://issues.apache.org/jira/browse/VALIDATOR-193 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Reporter: Matthias Weßendorf >Assignee: Ben Speakmon > Fix For: 1.4 > > Attachments: generic_validator_java_regExpr.patch > > > Introducing Java 1.4 dep instead of Jakarta ORO for GenericValidator > Patch comes > (based on the patched verion (for adding the ISBNValidator to Generic) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-193) Removing ORO dep. from GenericValidator
[ https://issues.apache.org/jira/browse/VALIDATOR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539718 ] Niall Pemberton commented on VALIDATOR-193: --- Fine by me > Removing ORO dep. from GenericValidator > --- > > Key: VALIDATOR-193 > URL: https://issues.apache.org/jira/browse/VALIDATOR-193 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Reporter: Matthias Weßendorf > Fix For: 1.4 > > Attachments: generic_validator_java_regExpr.patch > > > Introducing Java 1.4 dep instead of Jakarta ORO for GenericValidator > Patch comes > (based on the patched verion (for adding the ISBNValidator to Generic) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-242) Move EmailValidator to routines package
[ https://issues.apache.org/jira/browse/VALIDATOR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539716 ] Niall Pemberton commented on VALIDATOR-242: --- I agree stripComments() is a PITA. If you have the time and will to implement it then great, otherwise I suggest we just remove that logic unitl someone comes along with code and tests (perhaps open a separate Jira ticket as a reminder). Until I saw the code in that validator I wasn't even aware that you could comment an email address in that way and I suspect its rarely used. Anyway since this is a new implementation (and the old one will still be available in the next release) then compatibility isn't an issue IMO. > 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] Commented: (VALIDATOR-193) Removing ORO dep. from GenericValidator
[ https://issues.apache.org/jira/browse/VALIDATOR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539698 ] Ben Speakmon commented on VALIDATOR-193: Niall, since oro has now been removed from GenericValidator and the refactoring of Email/UrlValidator to not use oro is in progress in other bugs, are you okay with resolving this issue? > Removing ORO dep. from GenericValidator > --- > > Key: VALIDATOR-193 > URL: https://issues.apache.org/jira/browse/VALIDATOR-193 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Reporter: Matthias Weßendorf > Fix For: 1.4 > > Attachments: generic_validator_java_regExpr.patch > > > Introducing Java 1.4 dep instead of Jakarta ORO for GenericValidator > Patch comes > (based on the patched verion (for adding the ISBNValidator to Generic) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-203) Refactor UrlValidator - especially the line 370-ish TODO.
[ https://issues.apache.org/jira/browse/VALIDATOR-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539692 ] Ben Speakmon commented on VALIDATOR-203: Yep -- like I said in VALIDATOR-242, no problem turning the Patterns into static fields. I'll get that when I have a minute. > Refactor UrlValidator - especially the line 370-ish TODO. > - > > Key: VALIDATOR-203 > URL: https://issues.apache.org/jira/browse/VALIDATOR-203 > Project: Commons Validator > Issue Type: Task > Components: Routines >Reporter: Henri Yandell >Assignee: Ben Speakmon > Fix For: 1.4 > > > The UrlValidator class needs some cleanup. Just looking at VALIDATOR-202 > there were some obvious places where things could be cleaned up and the > solution for VALIDATOR-202 could use improvement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-242) Move EmailValidator to routines package
[ https://issues.apache.org/jira/browse/VALIDATOR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539691 ] Ben Speakmon commented on VALIDATOR-242: The stripComments() is going to be hard to deal with. That regexp makes me want to cry -- and it doesn't have any tests either. I suppose the right thing to do is add some dedicated tests for it and then try to untangle the regexp into smaller parts. Pain in the butt :) As for compiling patterns ahead of time, I agree that it's threadsafe; I held off on it just to minimize the scope of the change I was making. No problem to do it now though. I'll do the same thing for UrlValidator. > 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] Commented: (DBCP-4) [dbcp] Use commons-logging for debugging instead of System.out.println
[ https://issues.apache.org/jira/browse/DBCP-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539666 ] Madhusudan Pagadala commented on DBCP-4: This is very very important to change to commons-logging, also I prefer to add some more debug or info statements like, creating new connections and closing old connections, and properties used by the pooling, this type of logging should be there to optimize DB connections in pools, and debug the production problems, this package is causing vey annoying because of there is no logging, EVEN I AM THINKING OF OWNING COPY OF DBCP SOURCE and ADD LOGGING, finally Decided to raise this as an issue, with fouram, I also created a JIRA, but this seems already sheduled to 1.3, It will be very nice, THIS MESSAGE NOT ONLY MINE, IN MY OFFICE NEARLY 100 DEVELOPERS VOTED FOR THIS CHANGE, I AM SENDING YOU THIS MESSAGE BEHALF ALL OF THEM. I AM STRONGLY SUPPORT THIS CHANGE WITH 100/100 PREIORITY. Thanks, Madhu. > [dbcp] Use commons-logging for debugging instead of System.out.println > -- > > Key: DBCP-4 > URL: https://issues.apache.org/jira/browse/DBCP-4 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Operating System: All > Platform: All >Reporter: Alan Tam >Priority: Minor > Fix For: 1.3 > > Attachments: dbcp-commons-logging-2.patch, dbcp-commons-logging.patch > > > At the source code of commons-dbcp, some System.out.println() and > System.err.println() statements can be found, noticeably in the constructor > of > "java.org.apache.commons.dbcp.AbandonedObjectPool". > These statements are annoying, because none of the developers want to see > these > messages but they occuplied the precious space in the log files. > I think it is still appropriate to use this method to emit errors, but for > normal behavior, we should have an option never seeing them. -- 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_12539618 ] Paul Benedict commented on VALIDATOR-230: - Yes. I really would like to get this in Validator 1.4. It is possible to use reflection when wanting to deal with JDK 5 generics. This would be great along with Apache Enums > 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: Validator2 > > > 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-234) Create 1.4 DTD
[ https://issues.apache.org/jira/browse/VALIDATOR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved VALIDATOR-234. --- Resolution: Fixed Assignee: Niall Pemberton Done - http://svn.apache.org/viewvc?view=rev&revision=562117 > Create 1.4 DTD > -- > > Key: VALIDATOR-234 > URL: https://issues.apache.org/jira/browse/VALIDATOR-234 > Project: Commons Validator > Issue Type: Task > Components: Framework >Affects Versions: 1.4 >Reporter: Paul Benedict >Assignee: Niall Pemberton > Fix For: 1.4 > > > Create 1.4 DTD -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (VALIDATOR-138) Url Validation Error Codes
[ https://issues.apache.org/jira/browse/VALIDATOR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-138: -- Fix Version/s: (was: 1.4) Summary: Url Validation Error Codes (was: [validator] Url Validation Error Codes) > Url Validation Error Codes > -- > > Key: VALIDATOR-138 > URL: https://issues.apache.org/jira/browse/VALIDATOR-138 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: Nightly Builds > Environment: Operating System: other > Platform: Other >Reporter: Niall Pemberton >Priority: Minor > Attachments: UrlValidatorCodes.txt > > > I am attaching a patch which adds the ability for the UrlValidator to return > an > error code indicating what part of the url validation failed (following a > discussion on struts developers list). > The existing isValid(value) method still works returning true/false. > I have added isValid(Object value, boolean expandedCode) method which returns > an integer code. > If expandedCode is false it returns a code indicating which part of the url > is > invalid (general format, scheme, authority, path, query or fragment). > If expandedCode is true it returns a more detailled code indicating a more > specific error with the url. > I have run the existing validator tests which all passed. If your happy with > this change, I will submit a patch to the tests which check the specific code > returned. > Niall -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-215) New generic CodeValidator that validates format, length and Check Digit for a code
[ https://issues.apache.org/jira/browse/VALIDATOR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved VALIDATOR-215. --- Resolution: Fixed > New generic CodeValidator that validates format, length and Check Digit for a > code > -- > > Key: VALIDATOR-215 > URL: https://issues.apache.org/jira/browse/VALIDATOR-215 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > > Add a new generic CodeValidator that validates format, length and Check Digit > for a code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (VALIDATOR-230) Enum validator
[ https://issues.apache.org/jira/browse/VALIDATOR-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-230: -- Fix Version/s: (was: 1.4) Validator2 > 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: Validator2 > > > 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-138) [validator] Url Validation Error Codes
[ https://issues.apache.org/jira/browse/VALIDATOR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved VALIDATOR-138. --- Resolution: Won't Fix > [validator] Url Validation Error Codes > -- > > Key: VALIDATOR-138 > URL: https://issues.apache.org/jira/browse/VALIDATOR-138 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: Nightly Builds > Environment: Operating System: other > Platform: Other >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: UrlValidatorCodes.txt > > > I am attaching a patch which adds the ability for the UrlValidator to return > an > error code indicating what part of the url validation failed (following a > discussion on struts developers list). > The existing isValid(value) method still works returning true/false. > I have added isValid(Object value, boolean expandedCode) method which returns > an integer code. > If expandedCode is false it returns a code indicating which part of the url > is > invalid (general format, scheme, authority, path, query or fragment). > If expandedCode is true it returns a more detailled code indicating a more > specific error with the url. > I have run the existing validator tests which all passed. If your happy with > this change, I will submit a patch to the tests which check the specific code > returned. > Niall -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-214) New Regular Expression validator using JDK 1.4's Regex
[ https://issues.apache.org/jira/browse/VALIDATOR-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved VALIDATOR-214. --- Resolution: Fixed > New Regular Expression validator using JDK 1.4's Regex > -- > > Key: VALIDATOR-214 > URL: https://issues.apache.org/jira/browse/VALIDATOR-214 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > > Add a new Regular Expression validator using JDK 1.4's Regex support -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-213) Factor out Check Digit logic into separate implementations
[ https://issues.apache.org/jira/browse/VALIDATOR-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved VALIDATOR-213. --- Resolution: Fixed > Factor out Check Digit logic into separate implementations > -- > > Key: VALIDATOR-213 > URL: https://issues.apache.org/jira/browse/VALIDATOR-213 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > > Check digit validation is embedded in the specific code validations - which > also includes other validations such as format or length. This proposal is to > factor out the specific check digit calculation/valdiation logic into > separate implementations - making them more easily tested and re-usable. > This will include a new CheckDigit type and intially implementations for > ISBN-10, EAN-13 and Luhn check digit calculation/validation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (VALIDATOR-203) Refactor UrlValidator - especially the line 370-ish TODO.
[ https://issues.apache.org/jira/browse/VALIDATOR-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-203: -- Assignee: Ben Speakmon (was: Henri Yandell) Thanks for doing this Ben, same comment as per Email valdiator IMO it should improve performance if the regular expressions are not compiled for each URL validated. The JavaDoc for java.util.regex.Pattern[1] indicates that patterns are thread safe - so would be better to just compile the regular expression once: "All of the state involved in performing a match resides in the matcher, so many matchers can share the same pattern." [1] http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html > Refactor UrlValidator - especially the line 370-ish TODO. > - > > Key: VALIDATOR-203 > URL: https://issues.apache.org/jira/browse/VALIDATOR-203 > Project: Commons Validator > Issue Type: Task > Components: Routines >Reporter: Henri Yandell >Assignee: Ben Speakmon > Fix For: 1.4 > > > The UrlValidator class needs some cleanup. Just looking at VALIDATOR-202 > there were some obvious places where things could be cleaned up and the > solution for VALIDATOR-202 could use improvement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (VALIDATOR-242) Move EmailValidator to routines package
[ https://issues.apache.org/jira/browse/VALIDATOR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened VALIDATOR-242: --- Ben, Firstly, great work on re-factoring both URL and Email validators - including extracting out the new IntetAddress and domain validators :) thanks! I'm re-opening this because Email validator still has a dependency on Jakarta ORO with its use of Perl5Util in the Strip comments. Also IMO it should improve performance if the regular expressions are not compiled for each email address validated. The JavaDoc for java.util.regex.Pattern[1] indicates that patterns are thread safe - so would be better to just compile the regular expression once: "All of the state involved in performing a match resides in the matcher, so many matchers can share the same pattern." [1] http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html > 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] Created: (VALIDATOR-245) Not all of the indexedListProperty collection elements are validated
Not all of the indexedListProperty collection elements are validated
Key: VALIDATOR-245
URL: https://issues.apache.org/jira/browse/VALIDATOR-245
Project: Commons Validator
Issue Type: Improvement
Components: Framework
Affects Versions: 1.3.1 Release, 1.3.0 Release
Reporter: Edmund Ward
Priority: Minor
When the Field class method "validate(Map params, Map actions)" validates an
indexedListProperty it will return as soon as it finds an element in the
collection that fails validation. If other fields in the collection are invalid
too the user will only find out once they have corrected the first invalid
field. If the method were to validate all the fields in the collection (which
it will do anyway when all the elements are valid) the user would find all the
invalid fields the first time the bean is validated.
My proposed modification involves simply commenting out a couple of lines in
the Field class method "validate(Map params, Map actions)"
eg.
public ValidatorResults validate(Map params, Map actions)
throws ValidatorException {
if (this.getDepends() == null) {
return new ValidatorResults();
}
ValidatorResults allResults = new ValidatorResults();
Object bean = params.get(Validator.BEAN_PARAM);
int numberOfFieldsToValidate =
this.isIndexed() ? this.getIndexedPropertySize(bean) : 1;
for (int fieldNumber = 0; fieldNumber < numberOfFieldsToValidate;
fieldNumber++) {
Iterator dependencies = this.dependencyList.iterator();
ValidatorResults results = new ValidatorResults();
while (dependencies.hasNext()) {
String depend = (String) dependencies.next();
ValidatorAction action = (ValidatorAction) actions.get(depend);
if (action == null) {
this.handleMissingAction(depend);
}
boolean good =
validateForRule(action, results, actions, params, fieldNumber);
if (!good) {
allResults.merge(results);
//return allResults;
}
}
//allResults.merge(results);
}
return allResults;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
