[jira] [Updated] (JEXL-153) javadoc fails with 1.8.0
[ https://issues.apache.org/jira/browse/JEXL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Orion Poplawski updated JEXL-153: - Attachment: apache-commons-jexl-javadoc.patch This is against the 2.0 branch. > javadoc fails with 1.8.0 > > > Key: JEXL-153 > URL: https://issues.apache.org/jira/browse/JEXL-153 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Fedora w/ OpenJDK 1.8.0 >Reporter: Orion Poplawski >Priority: Minor > Labels: javadoc > Attachments: apache-commons-jexl-javadoc.patch > > > OpenJDK 1.8.0's javadoc is much more strict about HTML usage in javadoc. The > attached patch fixes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JEXL-153) javadoc fails with 1.8.0
Orion Poplawski created JEXL-153: Summary: javadoc fails with 1.8.0 Key: JEXL-153 URL: https://issues.apache.org/jira/browse/JEXL-153 Project: Commons JEXL Issue Type: Bug Affects Versions: 2.1.1 Environment: Fedora w/ OpenJDK 1.8.0 Reporter: Orion Poplawski Priority: Minor OpenJDK 1.8.0's javadoc is much more strict about HTML usage in javadoc. The attached patch fixes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-476) FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date
[ https://issues.apache.org/jira/browse/IO-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilguiz Latypov updated IO-476: -- Description: The test "FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date" failed in a nightly run of our tests that needed an arbitrary project such as Apache's Commons IO to work against. I suspect that the failure resulted from a system time adjustment taking place between the instantiation of the Date() object and creating a "new" file where its time stamp has to differ from one of a "reference" file, https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987 Since system time lacks guaranteed continuity, the tests could stabilize by dropping the use of the current time and stopping the assumption that any unequal time stamp as the code progresses turns larger than the one we compare against. (a) The tests against the current time stamps created with Date() could stabilize by making sure that these time stamps grew larger than the reference stamp and by making sure that every subsequent file stamp and system time reading has a value larger than before. (b) The wait for unequal time stamps could stabilize by waiting for the stamp value that outgrows the reference one. This will make the tests all the more trivial and less useful. Having a guaranteed continuous time source could make them substantial. Not sure if JVM's re-ordering the instructions could de-stabilize tests that connect to the file system and the desired continuous time source. was: The test "FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date" failed in a nightly run of our tests that needed an arbitrary project such as Apache's Commons IO to work against. I suspect that the failure resulted from a system time adjustment taking place between the instantiation of the Date() object and creating a "new" file where its time stamp has to differ from one of a "reference" file, https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987 Since system time lacks guaranteed continuity, the tests could stabilize by dropping the use of the current time and stopping the assumption that any unequal time stamp as the code progresses turns larger than the one we compare against. (a) The tests against the current time stamps created with Date() could stabilize by making sure that these time stamps grew larger than the reference stamp and by making sure that every subsequent file stamp and system time reading has a value larger than before. (b) The wait for unequal time stamps could stabilize by waiting for the stamp value that outgrows the reference one. This will make the tests all the more trivial and less useful. Having a guaranteed continuous time source could make them substantial. > FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date > -- > > Key: IO-476 > URL: https://issues.apache.org/jira/browse/IO-476 > Project: Commons IO > Issue Type: Test >Reporter: Ilguiz Latypov >Priority: Minor > Labels: test > > The test "FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date" > failed in a nightly run of our tests that needed an arbitrary project such as > Apache's Commons IO to work against. > I suspect that the failure resulted from a system time adjustment taking > place between the instantiation of the Date() object and creating a "new" > file where its time stamp has to differ from one of a "reference" file, > https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987 > Since system time lacks guaranteed continuity, the tests could stabilize by > dropping the use of the current time and stopping the assumption that any > unequal time stamp as the code progresses turns larger than the one we > compare against. > (a) The tests against the current time stamps created with Date() could > stabilize by making sure that these time stamps grew larger than the > reference stamp and by making sure that every subsequent file stamp and > system time reading has a value larger than before. > (b) The wait for unequal time stamps could stabilize by waiting for the stamp > value that outgrows the reference one. > This will make the tests all the more trivial and less useful. Having a > guaranteed continuous time source could make them substantial. Not sure if > JVM's re-ordering the instructions could de-stabilize tests that connect to > the file system and the desired continuous time source. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IO-476) FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date
Ilguiz Latypov created IO-476: - Summary: FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date Key: IO-476 URL: https://issues.apache.org/jira/browse/IO-476 Project: Commons IO Issue Type: Test Reporter: Ilguiz Latypov Priority: Minor The test "FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date" failed in a nightly run of our tests that needed an arbitrary project such as Apache's Commons IO to work against. I suspect that the failure resulted from a system time adjustment taking place between the instantiation of the Date() object and creating a "new" file where its time stamp has to differ from one of a "reference" file, https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987 Since system time lacks guaranteed continuity, the tests could stabilize by dropping the use of the current time and stopping the assumption that any unequal time stamp as the code progresses turns larger than the one we compare against. (a) The tests against the current time stamps created with Date() could stabilize by making sure that these time stamps grew larger than the reference stamp and by making sure that every subsequent file stamp and system time reading has a value larger than before. (b) The wait for unequal time stamps could stabilize by waiting for the stamp value that outgrows the reference one. This will make the tests all the more trivial and less useful. Having a guaranteed continuous time source could make them substantial. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VALIDATOR-365) An arbitrarily large email string causes stackoverflowerror in EmailValidator.isValid()
Jon Steege created VALIDATOR-365:
Summary: An arbitrarily large email string causes
stackoverflowerror in EmailValidator.isValid()
Key: VALIDATOR-365
URL: https://issues.apache.org/jira/browse/VALIDATOR-365
Project: Commons Validator
Issue Type: Bug
Reporter: Jon Steege
RFC-3696 defines a limit to the length of an email address. The local part is
limited to 64 characters.
Providing an arbitrarily long local segment to a string that is passed to
EmailValidator.isValid() can cause the function to overflow the stack.
{code}
groovy:000> test = new EmailValidator(false)
===> org.apache.commons.validator.routines.EmailValidator@2256a2bd
groovy:000>
test.isValid("loremipsumdolorsitametconsecteturadipiscingelit.nullavitaeligulamattisrhoncusnuncegestasmattisleo.donecnonsapieninmagnatristiquedictumaacturpis.fusceorciduifacilisisutsapieneuconsequatpharetralectus.quisqueenimestpulvinarutquamvitaeportamattisex.nullamquismaurisplaceratconvallisjustoquisportamauris.innullalacusconvalliseufringillautvenenatissitametdiam.maecenasluctusligulascelerisquepulvinarfeugiat.sedmolestienullaaliquetorciluctusidpharetranislfinibus.suspendissemalesuadatinciduntduisitametportaarcusollicitudinnec.donecetmassamagna.curabitururnadiampretiumveldignissimporttitorfringillaeuneque.duisantetelluspharetraidtinciduntinterdummolestiesitametfelis.utquisquamsitametantesagittisdapibusacnonodio.namrutrummolestiediamidmattis.cumsociisnatoquepenatibusetmagnisdisparturientmontesnasceturridiculusmus.morbiposueresedmetusacconsectetur.etiamquisipsumvitaejustotempusmaximus.sedultriciesplaceratvolutpat.integerlacuslectusmaximusacornarequissagittissitametjusto.cumsociisnatoquepenatibusetmagnisdisparturientmontesnasceturridiculusmus.maecenasindictumpurussedrutrumex.nullafacilisi.integerfinibusfinibusmietpharetranislfaucibusvel.maecenasegetdolorlacinialobortisjustovelullamcorpersem.vivamusaliquetpurusidvariusornaresapienrisusrutrumnisitinciduntmollissemnequeidmetus.etiamquiseleifendpurus.nuncfelisnuncscelerisqueiddignissimnecfinibusalibero.nuncsemperenimnequesitamethendreritpurusfacilisisac.maurisdapibussemperfelisdignissimgravida.aeneanultricesblanditnequealiquamfinibusodioscelerisqueac.aliquamnecmassaeumaurisfaucibusfringilla.etiamconsequatligulanisisitametaliquamnibhtemporquis.nuncinterdumdignissimnullaatsodalesarcusagittiseu.proinpharetrametusneclacuspulvinarsedvolutpatliberoornare.sedligulanislpulvinarnonlectuseublanditfacilisisante.sedmollisnislalacusauctorsuscipit.inhachabitasseplateadictumst.phasellussitametvelittemporvenenatisfeliseuegestasrisus.aliquameteratsitametnibhcommodofinibus.morbiefficiturodiovelpulvinariaculis.aeneantemporipsummassaaconsecteturturpisfaucibusultrices.praesentsodalesmaurisquisportafermentum.etiamnisinislvenenatisvelauctorutullamcorperinjusto.proinvelligulaerat.phasellusvestibulumgravidamassanonfeugiat.maecenaspharetraeuismodmetusegetefficitur.suspendissea...@gmail.com");
ERROR java.lang.StackOverflowError:
null
{code}
This is using commons-validator 1.4.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LANG-1058) StringUtils.uncapitalize performance improvement
[ https://issues.apache.org/jira/browse/LANG-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones resolved LANG-1058. Resolution: Implemented Fix Version/s: (was: Review Patch) 3.5 Author: djones Date: Wed Apr 15 19:59:50 2015 New Revision: 1673944 URL: http://svn.apache.org/r1673944 Log: Updates for LANG-1058: StringUtils.uncapitalize performance improvement. Similar fix also applied to StringUtils.capitalize (as mentioned in issue). Thanks to Leo Wang. Modified: commons/proper/lang/trunk/src/changes/changes.xml commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringUtils.java > StringUtils.uncapitalize performance improvement > > > Key: LANG-1058 > URL: https://issues.apache.org/jira/browse/LANG-1058 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Leo Wang >Assignee: Duncan Jones > Fix For: 3.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBUTILS-104) Add support for calling stored procs with return values
[ https://issues.apache.org/jira/browse/DBUTILS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496795#comment-14496795 ] William Speirs commented on DBUTILS-104: Yup, it's a duplicate... marked mine as such. Thanks! Bill- > Add support for calling stored procs with return values > --- > > Key: DBUTILS-104 > URL: https://issues.apache.org/jira/browse/DBUTILS-104 > Project: Commons DbUtils > Issue Type: Improvement >Affects Versions: 1.6, 2.0 >Reporter: William R. Speirs >Assignee: William R. Speirs > > Calling stored procs can have both return values (usually only an integer) > and out parameters. Currently QueryRunner doesn't handle return values making > it impossible to call these types of stored procs. > Add functionality for handling sotred procs that return values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DBUTILS-104) Add support for calling stored procs with return values
[ https://issues.apache.org/jira/browse/DBUTILS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-104. --- Resolution: Duplicate This is getting resolved in DBUTILS-50 > Add support for calling stored procs with return values > --- > > Key: DBUTILS-104 > URL: https://issues.apache.org/jira/browse/DBUTILS-104 > Project: Commons DbUtils > Issue Type: Improvement >Affects Versions: 1.6, 2.0 >Reporter: William R. Speirs >Assignee: William R. Speirs > > Calling stored procs can have both return values (usually only an integer) > and out parameters. Currently QueryRunner doesn't handle return values making > it impossible to call these types of stored procs. > Add functionality for handling sotred procs that return values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBUTILS-104) Add support for calling stored procs with return values
[ https://issues.apache.org/jira/browse/DBUTILS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496772#comment-14496772 ] Carl Hall commented on DBUTILS-104: --- Hey [~wspeirs], it looks like the patch in DBUTILS-50 would resolve this ticket. I'm reading through the patch now and am pretty close to committing it. Would you mind taking a look to see if this issue duplicates DBUTILS-50? > Add support for calling stored procs with return values > --- > > Key: DBUTILS-104 > URL: https://issues.apache.org/jira/browse/DBUTILS-104 > Project: Commons DbUtils > Issue Type: Improvement >Affects Versions: 1.6, 2.0 >Reporter: William R. Speirs >Assignee: William R. Speirs > > Calling stored procs can have both return values (usually only an integer) > and out parameters. Currently QueryRunner doesn't handle return values making > it impossible to call these types of stored procs. > Add functionality for handling sotred procs that return values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1058) StringUtils.uncapitalize performance improvement
[
https://issues.apache.org/jira/browse/LANG-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1058:
---
Assignee: Duncan Jones
Looks good to me, thanks for the suggestion. Just to verify, I created a simple
Google Caliper test to ensure your version is faster (I didn't test memory).
The results are clear:
{noformat}
benchmarkns linear runtime
OriginalCode 193.9 ==
NewCode 90.2 =
vm: java
trial: 0
{noformat}
I'll also look to apply the same fixes to {{capitalize}} too. Watch this
space...
> StringUtils.uncapitalize performance improvement
>
>
> Key: LANG-1058
> URL: https://issues.apache.org/jira/browse/LANG-1058
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Leo Wang
>Assignee: Duncan Jones
> Fix For: Review Patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBUTILS-50) Support CallableStatement "out" parameters
[
https://issues.apache.org/jira/browse/DBUTILS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496494#comment-14496494
]
Carl Hall commented on DBUTILS-50:
--
Hey [~RayDeCampo], thanks for the extensive patch. I'm looking through it now
and hope to get back to you soon.
> Support CallableStatement "out" parameters
> --
>
> Key: DBUTILS-50
> URL: https://issues.apache.org/jira/browse/DBUTILS-50
> Project: Commons DbUtils
> Issue Type: New Feature
>Reporter: Dan Fabulich
> Attachments: DBUTILS-50.patch
>
>
> Using fillStatement and the new fillStatementWithBean, you can use a
> CallableStatement like a PreparedStatement, retrieve its ResultSet and handle
> it with a ResultSetHandler. But we don't yet support registering "out"
> parameters on the CallableStatement in a convenient way and retrieving them
> back into an object.
> DBUTILS-28 requests stored procedure support and provides a patch, but I
> don't like the patch. Regardless, we really should support a few helpers
> like:
> {code}
> void registerOutParameters(CallableStatement stmt, int... sqlTypes)
> Object[] getOutParameters(CallableStatement stmt)
> void registerOutParameters(CallableStatement stmt, Class beanClass)
> T getOutParameters(CallableStatement stmt, Class beanClass)
> {code}
> You should be able to write code like this:
> {code}
> CallableStatement stmt = runner.prepareCall(myString);
> helper.registerOutParameters(stmt, MyBean.class);
> queryRunner.fillStatement(stmt, foo, bar, baz);
> stmt.executeUpdate();
> MyBean bean = helper.getOutParameters(stmt, MyBean.class);
> {code}
> Or like this:
> {code}
> CallableStatement stmt = runner.prepareCall(myString);
> helper.registerOutParameters(stmt, TINYINT, DECIMAL);
> queryRunner.fillStatement(stmt, foo, bar, baz);
> stmt.executeUpdate();
> Object[] result = helper.getOutParameters(stmt);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DBUTILS-70) add setQueryTimeout support to QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Hall resolved DBUTILS-70. -- Resolution: Fixed > add setQueryTimeout support to QueryRunner > -- > > Key: DBUTILS-70 > URL: https://issues.apache.org/jira/browse/DBUTILS-70 > Project: Commons DbUtils > Issue Type: Improvement >Reporter: Michael Akerman >Assignee: Carl Hall >Priority: Minor > Fix For: 1.7 > > Attachments: commons-dbutils-1.1.1.zip > > Original Estimate: 1h > Remaining Estimate: 1h > > java.sql.Statement and java.sql.PrepareStatement support a method called > setQueryTimeout. > It would be nice to add a public setQueryTimeout method to QueryRunner that > would pass this parameter through to the underlying Statements or > PreparedStatements. > For most of my applications if a query runs longer than a few seconds, > there's something wrong, and I'd like a SQLException in that scenario so I > can know there's an issue. > I'd be happy to submit some code as a proposal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBUTILS-70) add setQueryTimeout support to QueryRunner
[
https://issues.apache.org/jira/browse/DBUTILS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496234#comment-14496234
]
Carl Hall commented on DBUTILS-70:
--
Committed {{StatementConfiguration}} and tests in revision r1673781.
> add setQueryTimeout support to QueryRunner
> --
>
> Key: DBUTILS-70
> URL: https://issues.apache.org/jira/browse/DBUTILS-70
> Project: Commons DbUtils
> Issue Type: Improvement
>Reporter: Michael Akerman
>Assignee: Carl Hall
>Priority: Minor
> Fix For: 1.7
>
> Attachments: commons-dbutils-1.1.1.zip
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> java.sql.Statement and java.sql.PrepareStatement support a method called
> setQueryTimeout.
> It would be nice to add a public setQueryTimeout method to QueryRunner that
> would pass this parameter through to the underlying Statements or
> PreparedStatements.
> For most of my applications if a query runs longer than a few seconds,
> there's something wrong, and I'd like a SQLException in that scenario so I
> can know there's an issue.
> I'd be happy to submit some code as a proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SANDBOX-487) Human name parser
[ https://issues.apache.org/jira/browse/SANDBOX-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved SANDBOX-487. Resolution: Fixed Committed in git-wip-us.apache.org/repos/asf/commons-text/commit/411e81f8 With the following changes: * it accepts names with only the first name * nicknames/getNicknames was renamed to nickname/getNickname * the dependency to [lang] has been kept and shaded * the main class HumanNameParserParser was renamed to HumanNameParser This is the initial version of the human names parser. We can work on the remaining suggestions in separate issues or in the mailing list. Cheers Bruno > Human name parser > - > > Key: SANDBOX-487 > URL: https://issues.apache.org/jira/browse/SANDBOX-487 > Project: Commons Sandbox > Issue Type: Improvement > Components: Commons Text >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: name, parser, text > > The project > [HumanNameParser.java|http://tupilabs.github.io/HumanNameParser.java/] is a > port to Java of the > [HumanNameParser.php|http://jasonpriem.org/human-name-parse/], both licensed > under the MIT License. > This issue was created to discuss a similar parser, based on the Java > version, to the [text] component. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-933) Request to support custom DateFormatSymbols in FastDateFormat
[ https://issues.apache.org/jira/browse/LANG-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495873#comment-14495873 ] Oleg commented on LANG-933: --- Yes, it would be great. > Request to support custom DateFormatSymbols in FastDateFormat > - > > Key: LANG-933 > URL: https://issues.apache.org/jira/browse/LANG-933 > Project: Commons Lang > Issue Type: Wish > Components: General >Affects Versions: 3.1 >Reporter: Egidijus Vaisnora >Priority: Minor > Fix For: Patch Needed > > > FastDateFormat do not have possibility to accept custom DateFormatSymbols -- This message was sent by Atlassian JIRA (v6.3.4#6332)
