[jira] [Updated] (LANG-1435) ObjectUtils.defaultIfNull for slow default values
[ https://issues.apache.org/jira/browse/LANG-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dekel updated LANG-1435: Description: Currently, if the default value in defaultIfNull is computationally slow (for example, it requires a database call, or complex calculations), it's not worth using the util method. This feature is to implement a method that would only perform this computationally slow action if the object value is actually null. This can be done using a Supplier. In short, you'd call ObjectUtils.getDefaultIfNull(someNullableValue, DbUtil::doGet) instead of ObjectUtils.defaultIfNull(someNullableValue, DbUtil.doGet()) was: Currently, if the default value in defaultIfNull is computationally slow (for example, it requires a database call, or complex calculations), it's not worth using the util method. This feature is to implement a method that would only perform this computationally slow action if the object value is actually null. This can be done using a Supplier. In short, you'd call ObjectUtils.defaultIfNull(someNullableValue, DbUtil::doGet) instead of ObjectUtils.defaultIfNull(someNullableValue, DbUtil.doGet()) > ObjectUtils.defaultIfNull for slow default values > - > > Key: LANG-1435 > URL: https://issues.apache.org/jira/browse/LANG-1435 > Project: Commons Lang > Issue Type: New Feature >Reporter: Dekel >Priority: Minor > Original Estimate: 0.5h > Time Spent: 10m > Remaining Estimate: 20m > > Currently, if the default value in defaultIfNull is computationally slow (for > example, it requires a database call, or complex calculations), it's not > worth using the util method. This feature is to implement a method that would > only perform this computationally slow action if the object value is actually > null. This can be done using a Supplier. > In short, you'd call ObjectUtils.getDefaultIfNull(someNullableValue, > DbUtil::doGet) instead of ObjectUtils.defaultIfNull(someNullableValue, > DbUtil.doGet()) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (LANG-1435) ObjectUtils.defaultIfNull for slow default values
[ https://issues.apache.org/jira/browse/LANG-1435?focusedWorklogId=203145&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-203145 ] ASF GitHub Bot logged work on LANG-1435: Author: ASF GitHub Bot Created on: 24/Feb/19 01:22 Start Date: 24/Feb/19 01:22 Worklog Time Spent: 10m Work Description: dekelpilli commented on pull request #408: LANG-1435: Implemented defaultIfNull method that uses a supplier for default value URL: https://github.com/apache/commons-lang/pull/408 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 203145) Time Spent: 10m Remaining Estimate: 20m (was: 0.5h) > ObjectUtils.defaultIfNull for slow default values > - > > Key: LANG-1435 > URL: https://issues.apache.org/jira/browse/LANG-1435 > Project: Commons Lang > Issue Type: New Feature >Reporter: Dekel >Priority: Minor > Original Estimate: 0.5h > Time Spent: 10m > Remaining Estimate: 20m > > Currently, if the default value in defaultIfNull is computationally slow (for > example, it requires a database call, or complex calculations), it's not > worth using the util method. This feature is to implement a method that would > only perform this computationally slow action if the object value is actually > null. This can be done using a Supplier. > In short, you'd call ObjectUtils.defaultIfNull(someNullableValue, > DbUtil::doGet) instead of ObjectUtils.defaultIfNull(someNullableValue, > DbUtil.doGet()) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] dekelpilli opened a new pull request #408: LANG-1435: Implemented defaultIfNull method that uses a supplier for default value
dekelpilli opened a new pull request #408: LANG-1435: Implemented defaultIfNull method that uses a supplier for default value URL: https://github.com/apache/commons-lang/pull/408 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (LANG-1435) ObjectUtils.defaultIfNull for slow default values
Dekel created LANG-1435: --- Summary: ObjectUtils.defaultIfNull for slow default values Key: LANG-1435 URL: https://issues.apache.org/jira/browse/LANG-1435 Project: Commons Lang Issue Type: New Feature Reporter: Dekel Currently, if the default value in defaultIfNull is computationally slow (for example, it requires a database call, or complex calculations), it's not worth using the util method. This feature is to implement a method that would only perform this computationally slow action if the object value is actually null. This can be done using a Supplier. In short, you'd call ObjectUtils.defaultIfNull(someNullableValue, DbUtil::doGet) instead of ObjectUtils.defaultIfNull(someNullableValue, DbUtil.doGet()) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TEXT-104) Jaro Winkler Distance refers to similarity
[ https://issues.apache.org/jira/browse/TEXT-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved TEXT-104. - Resolution: Fixed Fixed for 1.7, with notes in TEXT-150 for 2.0. Once 2.0, we should still have the similarity score, as well as finally the fixed edit distance. Thanks! > Jaro Winkler Distance refers to similarity > -- > > Key: TEXT-104 > URL: https://issues.apache.org/jira/browse/TEXT-104 > Project: Commons Text > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Nikos Karagiannakis >Assignee: Bruno P. Kinoshita >Priority: Trivial > Fix For: 1.7 > > Attachments: image-2019-02-20-20-32-41-512.png > > Time Spent: 3h 10m > Remaining Estimate: 0h > > The 'apply' method returns the similarity score instead of the distance score > as implied from the class name. > It is stated in the javadoc, but it is not aligned with the approach of the > rest similarity scores in the same package (e.g LevenshteinDetailedDistance). > Maybe a rename of the class or the method to avoid confusion? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TEXT-150) Fix TODO's from TEXT-104 in 2.0 for Jaro Winkler distance and similarities
Bruno P. Kinoshita created TEXT-150: --- Summary: Fix TODO's from TEXT-104 in 2.0 for Jaro Winkler distance and similarities Key: TEXT-150 URL: https://issues.apache.org/jira/browse/TEXT-150 Project: Commons Text Issue Type: Task Reporter: Bruno P. Kinoshita Fix For: 2.0 In TEXT-104, we added a new class, JaroWinklerSimilarity, and also fixed the Edit Distance related class. Then after realizing the issue with backward compatibility, we reverted the change to JaroWinklerEditDistance, but left the similarity score class, and also TODO markers saying what needs to be done for 2.0. Should be fairly easy. There are TODO's in the main classes, but there is also one TODO in a test class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (TEXT-104) Jaro Winkler Distance refers to similarity
[ https://issues.apache.org/jira/browse/TEXT-104?focusedWorklogId=203130&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-203130 ] ASF GitHub Bot logged work on TEXT-104: --- Author: ASF GitHub Bot Created on: 23/Feb/19 23:29 Start Date: 23/Feb/19 23:29 Worklog Time Spent: 10m Work Description: kinow commented on pull request #102: TEXT-104: deprecate JaroWinkler methods for 2.0, and fix clirr report URL: https://github.com/apache/commons-text/pull/102 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 203130) Time Spent: 3h 10m (was: 3h) > Jaro Winkler Distance refers to similarity > -- > > Key: TEXT-104 > URL: https://issues.apache.org/jira/browse/TEXT-104 > Project: Commons Text > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Nikos Karagiannakis >Assignee: Bruno P. Kinoshita >Priority: Trivial > Fix For: 1.7 > > Attachments: image-2019-02-20-20-32-41-512.png > > Time Spent: 3h 10m > Remaining Estimate: 0h > > The 'apply' method returns the similarity score instead of the distance score > as implied from the class name. > It is stated in the javadoc, but it is not aligned with the approach of the > rest similarity scores in the same package (e.g LevenshteinDetailedDistance). > Maybe a rename of the class or the method to avoid confusion? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (RNG-72) Create a RandomSource.create benchmark
[
https://issues.apache.org/jira/browse/RNG-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775619#comment-16775619
]
Alex D Herbert edited comment on RNG-72 at 2/23/19 8:09 PM:
Initial benchmark to create 500 RNGs, seeds are pre-built where appropriate.
Test the following construction methods:
* Create using the native constructor with the {{new}} keyword
* Create using a cached {{Constructor}} with newInstance
* Create using a cached {{Class}}, lookup the {{Constructor}} and
use newInstance
* Create using {{RandomSource}} with the native seed
* Create using {{RandomSource}} with a {{null}} seed
* Create using {{RandomSource}} with a truncated native seed forcing self
seeding
* Create using {{RandomSource}} with a {{byte[]}} of the appropriate length
The table shows the average time for the {{new}} method and then the relative
time for each of the other methods. Table is sorted by the speed of the native
constructor (time in microseconds):
||RandomSource||new||newInstance||lookupNewInstance||createNativeSeed||createNullSeed||createSelfSeed||createByteArray||
|SPLIT_MIX_64|3.28|1.93|6.10|6.68|25.52|0.00|9.65|
|KISS|7.26|1.55|3.22|3.54|186.63|3.64|6.08|
|WELL_512_A|9.14|1.33|2.71|3.01|146.15|5.16|12.56|
|JDK|10.14|1.14|2.64|2.84|8.95|0.00|4.20|
|WELL_1024_A|14.45|1.11|2.06|2.23|92.51|5.62|14.19|
|XOR_SHIFT_1024_S|14.91|1.09|1.97|2.20|164.19|3.09|8.20|
|WELL_19937_A|157.55|1.00|1.04|1.37|10.74|8.32|23.58|
|WELL_19937_C|158.58|1.00|1.05|1.37|10.46|8.30|22.10|
|MWC_256|159.91|0.98|1.02|1.25|9.30|3.61|9.64|
|WELL_44497_B|358.09|1.00|1.03|1.22|5.70|8.05|22.80|
|WELL_44497_A|363.88|1.01|1.01|1.18|5.62|7.94|21.50|
|ISAAC|1055.40|1.00|1.06|1.11|2.30|1.52|2.38|
|MT_64|3290.11|1.02|1.03|1.06|1.21|0.44|0.92|
|MT|5327.08|1.00|1.01|1.04|0.93|0.68|1.35|
|TWO_CMRES|73908.06|1.03|1.03|1.06|1.07|0.00|1.08|
For reference here are the native seed types and length (for arrays):
||RandomSource||Type||Length||
|SPLIT_MIX_64|Long|-|
|KISS|int[]|4|
|WELL_512_A|int[]|16|
|JDK|Long|-|
|WELL_1024_A|int[]|32|
|XOR_SHIFT_1024_S|long[]|16|
|WELL_19937_A|int[]|624|
|MWC_256|int[]|257|
|WELL_44497_A|int[]|1391|
|ISAAC|int[]|256|
|MT_64|long[]|312|
|MT|int[]|624|
|TWO_CMRES|Integer|-|
Notes:
The following generators have a self-seeding routine:
* ISAAC
* MT
* MT_64
* TWO_CMRES
This self-seeding routine is the main overhead during construction. In the case
of the TWO_CMRES the self-seeding is very computationally intensive as it
involves on average 2^16 calls to advance the sub-cycle generators.
Construction of the SPLIT_MIX_64 and JDK just copies the long value as the seed
state.
Construction with a native seed for the other generators is basically an array
copy.
Analysis:
Using Reflection
The use of the {{new}} keyword is optimal. Using a cached constructor has a
performance improvement over using the class to find the constructor. This is a
large part of the construction cost for the fastest {{RandomSource}}, e.g.
SPLIT_MIX_64.
The factory method using the native seed (which uses the class to find the
constructor) is only about 10% slower than the hard coded benchmark code
without any seed validation. So the factory is not impacting the construction
speed over just using reflection when a native seed is available.
It would be possible to move the creation using reflection to the
{{RandomSourceInternal}} enum. The default implementation could be overidden
with a method using the {{new}} keyword to avoid reflection where this is a
performance benefit, e.g.
{code:java}
// Method added to RandomSourceInternal to be used when the seed has been
converted to the native seed.
// Default
RestorableUniformRandomProvider createInstance(Object seed, Object[] args) {
final List all = new ArrayList();
all.add(nativeSeed);
if (args != null) {
all.addAll(Arrays.asList(args));
}
return create(createConstructor(this), all.toArray())
}
// Optimised for performance
RestorableUniformRandomProvider createInstance(Object seed, Object[] args) {
return new SplitMix64((Long)seed);
}{code}
This would show the most benefit for the fast to construct RNGs at the cost of
extra code in the factory (and test methods to ensure that createInstance
returns a type matching the class returned by getRng()).
SPLIT_MIX_64 (single number seed)
Construction with a native seed shows the relative cost of instantiation using
reflection is 6x slower. This could be improved by removing the use of
ArrayList within the method that builds the {{Object[]}} to pass to the
constructor. In most cases the arguments are null and an {{Object[]}} of length
1 can be created directly using just the seed. This may explain part of the 10%
slowdown between the factory method and the benchmark using reflection.
If the seed must be generated then the construction is 22x slower. This is due
to
[jira] [Commented] (VALIDATOR-445) Inet6Address may also contain a scope id
[ https://issues.apache.org/jira/browse/VALIDATOR-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775982#comment-16775982 ] devson commented on VALIDATOR-445: -- Hi Tiago, You can suggest a patch here or perhaps make a pull request at the github repo ([https://github.com/apache/commons-validator).] However, I'm waiting for the developers to validate the issue as a bug/missing support. > Inet6Address may also contain a scope id > > > Key: VALIDATOR-445 > URL: https://issues.apache.org/jira/browse/VALIDATOR-445 > Project: Commons Validator > Issue Type: Bug >Reporter: devson >Priority: Major > > InetAddressValidator.isValidInet6Address incorrectly returns false for IPv6 > address that contains a scope id such as in this: > fe80:0:0:0:c1e1:54cf:68bc:9d5e%12 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-74) Make "Fraction" a ValJO
[
https://issues.apache.org/jira/browse/NUMBERS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775977#comment-16775977
]
Gilles commented on NUMBERS-74:
---
{quote}Is this project currently active?
{quote}
Yes.
This component is a dependency for [Commons
Geometry|http://commons.apache.org/geometry] (not released yet, but actively
worked on) and [Commons Math|http://commons.apache.org/math] (a legacy project,
but the upcoming new major version contains many bug fixes and enhancements).
Help welcome in order to come closer to a first official release.
> Make "Fraction" a ValJO
> ---
>
> Key: NUMBERS-74
> URL: https://issues.apache.org/jira/browse/NUMBERS-74
> Project: Commons Numbers
> Issue Type: Sub-task
> Components: fraction
>Reporter: Gilles
>Priority: Major
> Labels: API
> Fix For: 1.0
>
>
> [This ML post|https://markmail.org/message/fhrnyg3nfer7y2cy] makes
> suggestions and points to potential issues with that class.
> A.o. things,
> * there seems to be some code overlap between the constructors and the
> {{getReducedFraction}} method (and the latter should probably be private
> anyways),
> * method {{percentageValue}} is not very useful,
> * a lot of constants should be removed,
> * {{serialVersionUID}} should be updated, and moved to the top of the
> declaration list.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-295) DiskFileItem: getStoreLocation() may return non-existing file
[
https://issues.apache.org/jira/browse/FILEUPLOAD-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775950#comment-16775950
]
Stephan Markwalder commented on FILEUPLOAD-295:
---
Hi Jochen,
I'm ok if this bug is not fixed. It is indeed an edge case. We have been
running into it after upgrading from version 1.3.3 to version 1.4 (in which
FILEUPLOAD-258 has been fixed).
Before, we have been using a sizeThreshold of 0 for a very long time, assuming
that this would cause DiskFileItem to always store data on disk, never in
memory. This was our fault no 1. Unfortunately, the JavaDoc for DiskFileItem's
constructor is not very precise:
{quote}{{sizeThreshold}} - The threshold, in bytes, below which items will be
retained in memory and above which they will be stored as a file.
{quote}
But what happens when the item size is equal to the threshold? :)
Our fault no 2 then was that people have used the return value of
DiskFileItem.getStoreLocation() without a check of DiskFileItem.isInMemory()
upfront (because of the assumption made above).
Together, those two faults have lead to NullPointerExceptions in our code after
the upgrade to version 1.4.
When analyzing the issue, I though that it would be sufficient to set
sizeThreshold to -1. No matter what the actual file size will be, it is for
sure 0 or greater. According to JavaDoc, this then should guarantee that items
will be stored as files on disk. But when writing some tests for DiskFileItem
to explore how it deals with empty files, we noticed that it behaves
differently depending on whether/how data is written into the DiskFileItem's
OutputStream. In some cases, an empty file is created, in others not.
Unfortunately, DiskFileItem then somehow is in an inconsistent state.
isInMemory() returns false, getStoreLocation() returns a File object, but the
file does not exist. As a result, we have seen FileNotFoundExceptions in some
of our components, even the ones where people have thought about an upfront
check with isInMemory(). Our "fix" now is to not trust DiskFileItem and the
information it returns for isInMemory() or getStoreLocation(), but always go
for an extra check whether the file actually exists.
If this bug is not fixed, it has at least been filed once. If other people run
into the same or a similar issue when upgrading to 1.4, they at least now have
a chance to find this ticket and maybe get some insights in how to solve them
for themselves.
> DiskFileItem: getStoreLocation() may return non-existing file
> -
>
> Key: FILEUPLOAD-295
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-295
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Stephan Markwalder
>Priority: Minor
>
> *How to reproduce*
> # Create a DiskFileItem with threshold set to -1 (force save to disk).
> # Get OutputStream from DiskFileItem.
> # Close OutputStream without calling any write(...) method (e.g., because
> the uploaded file is empty).
> # Test the return value of the following methods:
> ** isInMemory() --> returns false (OK)
> ** getSize() --> returns 0 (OK)
> ** getStoreLocation() --> returns a File object (OK), but the file does not
> exist (FAILURE).
> I think this is an inconsistency. If isInMemory() returns false adn
> getStoreLocation() returns a File object, the file should also exist.
> Java code (run with -ea to enable assertions):
> {code:java}
> // create a DiskFileItem
> int sizeThreshold = -1; // always store to disk
> File repository = null; // use temporary folder
> DiskFileItem item = new DiskFileItem("file", "text/plain", false, "file.txt",
> sizeThreshold, repository);
> OutputStream outputStream = item.getOutputStream();
> // do not write to stream <-- IMPORTANT
> outputStream.close();
> // assert that data has been stored to disk
> assert !item.isInMemory(); // pass
> assert item.getSize() == 0; // pass
> assert item.getStoreLocation() != null; // pass
> assert item.getStoreLocation().isFile(); // fails
> {code}
> When adding a call to outputStream.write(new byte[0]), the behavior changes
> and the empty file is created on disk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-74) Make "Fraction" a ValJO
[
https://issues.apache.org/jira/browse/NUMBERS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775932#comment-16775932
]
Tiago Lacerda commented on NUMBERS-74:
--
Is this project currently active? Thank you
> Make "Fraction" a ValJO
> ---
>
> Key: NUMBERS-74
> URL: https://issues.apache.org/jira/browse/NUMBERS-74
> Project: Commons Numbers
> Issue Type: Sub-task
> Components: fraction
>Reporter: Gilles
>Priority: Major
> Labels: API
> Fix For: 1.0
>
>
> [This ML post|https://markmail.org/message/fhrnyg3nfer7y2cy] makes
> suggestions and points to potential issues with that class.
> A.o. things,
> * there seems to be some code overlap between the constructors and the
> {{getReducedFraction}} method (and the latter should probably be private
> anyways),
> * method {{percentageValue}} is not very useful,
> * a lot of constants should be removed,
> * {{serialVersionUID}} should be updated, and moved to the top of the
> declaration list.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-294) Link "Source repository" is broken on project website
[ https://issues.apache.org/jira/browse/FILEUPLOAD-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775930#comment-16775930 ] Jochen Wiedmann commented on FILEUPLOAD-294: Thanks for spotting this. Need to understand, how this could happen, as the site is basically generated by Maven. > Link "Source repository" is broken on project website > - > > Key: FILEUPLOAD-294 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-294 > Project: Commons FileUpload > Issue Type: Bug >Reporter: Stephan Markwalder >Priority: Minor > > The link behind "Source repository" is broken: > [https://commons.apache.org/proper/commons-fileupload/source-repository.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VALIDATOR-445) Inet6Address may also contain a scope id
[ https://issues.apache.org/jira/browse/VALIDATOR-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775929#comment-16775929 ] Tiago Lacerda commented on VALIDATOR-445: - Hello devson, is it possible for me to contribute to this project, mainly this issue? thank you > Inet6Address may also contain a scope id > > > Key: VALIDATOR-445 > URL: https://issues.apache.org/jira/browse/VALIDATOR-445 > Project: Commons Validator > Issue Type: Bug >Reporter: devson >Priority: Major > > InetAddressValidator.isValidInet6Address incorrectly returns false for IPv6 > address that contains a scope id such as in this: > fe80:0:0:0:c1e1:54cf:68bc:9d5e%12 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-293) FileExistsException: Destination .. already exists when DiskFileItem.write was given an existing file
[
https://issues.apache.org/jira/browse/FILEUPLOAD-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775925#comment-16775925
]
Jochen Wiedmann commented on FILEUPLOAD-293:
Sorry, need to correct myself again. To me, the problem is not reproducable.
> FileExistsException: Destination .. already exists when DiskFileItem.write
> was given an existing file
> -
>
> Key: FILEUPLOAD-293
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-293
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Mladen Girazovski
>Priority: Major
>
> Since 1.4, where FILEUPLOAD-248 was shipped, passing an existing file to
> DiskFileItem.write will cause an FileExistsException with the message
> "Destination FILE already exist", this prevents us from upgrading to 1.4 from
> 1.3.3.
>
> {{2019-02-20 01:12:56,504 http-nio-2990-exec-3 ERROR
> [|5ccb9b99-a96f-42ba-ad01-ac278516e1a4|]
> [IssueAttachmentsResource.privacy-safe] Error saving attachment}}
> {{org.apache.commons.io.FileExistsException: Destination
> '/buildeng/bamboo-agent-home/xml-data/build-dir/CLOUDRELEASE-AGILEWD15421-FT18/jira-test-runner-jira/target/cargo/configurations/tomcat9x/temp/attachment-3404789743778163937.tmp'
> already exists}}
> {{ at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001)}}
> {{ at
> org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405)}}
> {{ at
> com.atlassian.plugins.rest.common.multipart.fileupload.CommonsFileUploadFilePart.write(CommonsFileUploadFilePart.java:49)}}
> {{ at
> com.atlassian.jira.rest.v2.issue.IssueAttachmentsResource.getFileFromFilePart(IssueAttachmentsResource.java:175)}}
> {{...}}
>
> Apache Felix also ran into the same bug:
> https://issues.apache.org/jira/browse/FELIX-6037
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-293) FileExistsException: Destination .. already exists when DiskFileItem.write was given an existing file
[
https://issues.apache.org/jira/browse/FILEUPLOAD-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775923#comment-16775923
]
Jochen Wiedmann commented on FILEUPLOAD-293:
Okay, got it. Need to set sizeThreshold=0, to have it reproducable. Confirming
bug, working on the solution.
> FileExistsException: Destination .. already exists when DiskFileItem.write
> was given an existing file
> -
>
> Key: FILEUPLOAD-293
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-293
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Mladen Girazovski
>Priority: Major
>
> Since 1.4, where FILEUPLOAD-248 was shipped, passing an existing file to
> DiskFileItem.write will cause an FileExistsException with the message
> "Destination FILE already exist", this prevents us from upgrading to 1.4 from
> 1.3.3.
>
> {{2019-02-20 01:12:56,504 http-nio-2990-exec-3 ERROR
> [|5ccb9b99-a96f-42ba-ad01-ac278516e1a4|]
> [IssueAttachmentsResource.privacy-safe] Error saving attachment}}
> {{org.apache.commons.io.FileExistsException: Destination
> '/buildeng/bamboo-agent-home/xml-data/build-dir/CLOUDRELEASE-AGILEWD15421-FT18/jira-test-runner-jira/target/cargo/configurations/tomcat9x/temp/attachment-3404789743778163937.tmp'
> already exists}}
> {{ at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001)}}
> {{ at
> org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405)}}
> {{ at
> com.atlassian.plugins.rest.common.multipart.fileupload.CommonsFileUploadFilePart.write(CommonsFileUploadFilePart.java:49)}}
> {{ at
> com.atlassian.jira.rest.v2.issue.IssueAttachmentsResource.getFileFromFilePart(IssueAttachmentsResource.java:175)}}
> {{...}}
>
> Apache Felix also ran into the same bug:
> https://issues.apache.org/jira/browse/FELIX-6037
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-293) FileExistsException: Destination .. already exists when DiskFileItem.write was given an existing file
[
https://issues.apache.org/jira/browse/FILEUPLOAD-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775920#comment-16775920
]
Jochen Wiedmann commented on FILEUPLOAD-293:
Trying to reproduce the problem with the code below. Works fine, so please help
me by telling me what you are doing different:
{{ @Test}}
{{ public void testMoveFile() throws Exception {}}
{{ final String content = }}
{{ "-1234\r\n" +}}
{{ "Content-Disposition: form-data; name=\"file\";"}}
{{ + "filename=\"foo.tab\"\r\n" +}}
{{ "Content-Type: text/whatever\r\n" +}}
{{ "\r\n" +}}
{{ "This is the content of the file\n" +}}
{{ "\r\n" +}}
{{ "-1234--\r\n";}}
{{ final byte[] contentBytes = content.getBytes("US-ASCII");}}
{{ final HttpServletRequest request = new}}
{{ MockHttpServletRequest(contentBytes, Constants.CONTENT_TYPE);}}
{{ final List items = upload.parseRequest(request);}}
{{ assertNotNull(items);}}
{{ assertFalse(items.isEmpty());}}
{{ final DiskFileItem dfi = (DiskFileItem) items.get(0);}}
{{ final File out = new File("target/unit-tests/DiskFileUpload");}}
{{ final File outDir = out.getParentFile();}}
{{ if (!outDir.isDirectory()) {}}
{{ outDir.mkdirs();}}
{{ }}}
{{ dfi.write(out);}}
{{ }}}
> FileExistsException: Destination .. already exists when DiskFileItem.write
> was given an existing file
> -
>
> Key: FILEUPLOAD-293
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-293
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Mladen Girazovski
>Priority: Major
>
> Since 1.4, where FILEUPLOAD-248 was shipped, passing an existing file to
> DiskFileItem.write will cause an FileExistsException with the message
> "Destination FILE already exist", this prevents us from upgrading to 1.4 from
> 1.3.3.
>
> {{2019-02-20 01:12:56,504 http-nio-2990-exec-3 ERROR
> [|5ccb9b99-a96f-42ba-ad01-ac278516e1a4|]
> [IssueAttachmentsResource.privacy-safe] Error saving attachment}}
> {{org.apache.commons.io.FileExistsException: Destination
> '/buildeng/bamboo-agent-home/xml-data/build-dir/CLOUDRELEASE-AGILEWD15421-FT18/jira-test-runner-jira/target/cargo/configurations/tomcat9x/temp/attachment-3404789743778163937.tmp'
> already exists}}
> {{ at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001)}}
> {{ at
> org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405)}}
> {{ at
> com.atlassian.plugins.rest.common.multipart.fileupload.CommonsFileUploadFilePart.write(CommonsFileUploadFilePart.java:49)}}
> {{ at
> com.atlassian.jira.rest.v2.issue.IssueAttachmentsResource.getFileFromFilePart(IssueAttachmentsResource.java:175)}}
> {{...}}
>
> Apache Felix also ran into the same bug:
> https://issues.apache.org/jira/browse/FELIX-6037
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FILEUPLOAD-295) DiskFileItem: getStoreLocation() may return non-existing file
[
https://issues.apache.org/jira/browse/FILEUPLOAD-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775914#comment-16775914
]
Jochen Wiedmann commented on FILEUPLOAD-295:
I admit, that I wouldn't design it like this, if this were a new API. On the
other hand, FileUpload is quite established, and I do not consider this a
serious problem. So, I am suggesting to resolve this as WONTFIX.
> DiskFileItem: getStoreLocation() may return non-existing file
> -
>
> Key: FILEUPLOAD-295
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-295
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Stephan Markwalder
>Priority: Minor
>
> *How to reproduce*
> # Create a DiskFileItem with threshold set to -1 (force save to disk).
> # Get OutputStream from DiskFileItem.
> # Close OutputStream without calling any write(...) method (e.g., because
> the uploaded file is empty).
> # Test the return value of the following methods:
> ** isInMemory() --> returns false (OK)
> ** getSize() --> returns 0 (OK)
> ** getStoreLocation() --> returns a File object (OK), but the file does not
> exist (FAILURE).
> I think this is an inconsistency. If isInMemory() returns false adn
> getStoreLocation() returns a File object, the file should also exist.
> Java code (run with -ea to enable assertions):
> {code:java}
> // create a DiskFileItem
> int sizeThreshold = -1; // always store to disk
> File repository = null; // use temporary folder
> DiskFileItem item = new DiskFileItem("file", "text/plain", false, "file.txt",
> sizeThreshold, repository);
> OutputStream outputStream = item.getOutputStream();
> // do not write to stream <-- IMPORTANT
> outputStream.close();
> // assert that data has been stored to disk
> assert !item.isInMemory(); // pass
> assert item.getSize() == 0; // pass
> assert item.getStoreLocation() != null; // pass
> assert item.getStoreLocation().isFile(); // fails
> {code}
> When adding a call to outputStream.write(new byte[0]), the behavior changes
> and the empty file is created on disk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (CODEC-250) Wrong value calculated by Cologne Phonetic if a special character is placed between equal letters
[
https://issues.apache.org/jira/browse/CODEC-250?focusedWorklogId=203043&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-203043
]
ASF GitHub Bot logged work on CODEC-250:
Author: ASF GitHub Bot
Created on: 23/Feb/19 13:00
Start Date: 23/Feb/19 13:00
Worklog Time Spent: 10m
Work Description: DerXHelp commented on pull request #14: [CODEC-250]
correcting handling of special character between equal letters for cologne
phonetic
URL: https://github.com/apache/commons-codec/pull/14
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 203043)
Time Spent: 10m
Remaining Estimate: 0h
> Wrong value calculated by Cologne Phonetic if a special character is placed
> between equal letters
> -
>
> Key: CODEC-250
> URL: https://issues.apache.org/jira/browse/CODEC-250
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.5, 1.11
>Reporter: Alex Volodko
>Priority: Major
> Fix For: 1.12
>
> Attachments: CODEC250.patch, ColognePhonetic.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The algorith for cologne phonetic is (simpilied):
> # Encode letter by letter from left to right according to the conversion
> table.
> # Remove all digits occurring more than once next to each other.
> # Remove all code "0" except at the beginning.
> Characters which are not specified in conversion table (such as hyphens) are
> ignored. See https://en.wikipedia.org/wiki/Cologne_phonetics
> If the input is "test-test" the step results will be:
> # 20822082
> # 2082082
> # 28282
> The expected result for "test-test" is therefor 28282.
> The actual result for "test-test" is 282{color:#FF}2{color}82.
> This bug is caused by the fix from
> [https://github.com/apache/commons-codec/commit/72c8759a22c6552a2dfcdf61b29729f981752879]
> and is present since 1.5
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CODEC-250) Wrong value calculated by Cologne Phonetic if a special character is placed between equal letters
[
https://issues.apache.org/jira/browse/CODEC-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins closed CODEC-250.
--
> Wrong value calculated by Cologne Phonetic if a special character is placed
> between equal letters
> -
>
> Key: CODEC-250
> URL: https://issues.apache.org/jira/browse/CODEC-250
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.5, 1.11
>Reporter: Alex Volodko
>Priority: Major
> Fix For: 1.12
>
> Attachments: CODEC250.patch, ColognePhonetic.java
>
>
> The algorith for cologne phonetic is (simpilied):
> # Encode letter by letter from left to right according to the conversion
> table.
> # Remove all digits occurring more than once next to each other.
> # Remove all code "0" except at the beginning.
> Characters which are not specified in conversion table (such as hyphens) are
> ignored. See https://en.wikipedia.org/wiki/Cologne_phonetics
> If the input is "test-test" the step results will be:
> # 20822082
> # 2082082
> # 28282
> The expected result for "test-test" is therefor 28282.
> The actual result for "test-test" is 282{color:#FF}2{color}82.
> This bug is caused by the fix from
> [https://github.com/apache/commons-codec/commit/72c8759a22c6552a2dfcdf61b29729f981752879]
> and is present since 1.5
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CODEC-250) Wrong value calculated by Cologne Phonetic if a special character is placed between equal letters
[
https://issues.apache.org/jira/browse/CODEC-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated CODEC-250:
---
Fix Version/s: 1.12
> Wrong value calculated by Cologne Phonetic if a special character is placed
> between equal letters
> -
>
> Key: CODEC-250
> URL: https://issues.apache.org/jira/browse/CODEC-250
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.5, 1.11
>Reporter: Alex Volodko
>Priority: Major
> Fix For: 1.12
>
> Attachments: CODEC250.patch, ColognePhonetic.java
>
>
> The algorith for cologne phonetic is (simpilied):
> # Encode letter by letter from left to right according to the conversion
> table.
> # Remove all digits occurring more than once next to each other.
> # Remove all code "0" except at the beginning.
> Characters which are not specified in conversion table (such as hyphens) are
> ignored. See https://en.wikipedia.org/wiki/Cologne_phonetics
> If the input is "test-test" the step results will be:
> # 20822082
> # 2082082
> # 28282
> The expected result for "test-test" is therefor 28282.
> The actual result for "test-test" is 282{color:#FF}2{color}82.
> This bug is caused by the fix from
> [https://github.com/apache/commons-codec/commit/72c8759a22c6552a2dfcdf61b29729f981752879]
> and is present since 1.5
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CODEC-250) Wrong value calculated by Cologne Phonetic if a special character is placed between equal letters
[
https://issues.apache.org/jira/browse/CODEC-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins resolved CODEC-250.
Resolution: Fixed
> Wrong value calculated by Cologne Phonetic if a special character is placed
> between equal letters
> -
>
> Key: CODEC-250
> URL: https://issues.apache.org/jira/browse/CODEC-250
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.5, 1.11
>Reporter: Alex Volodko
>Priority: Major
> Fix For: 1.12
>
> Attachments: CODEC250.patch, ColognePhonetic.java
>
>
> The algorith for cologne phonetic is (simpilied):
> # Encode letter by letter from left to right according to the conversion
> table.
> # Remove all digits occurring more than once next to each other.
> # Remove all code "0" except at the beginning.
> Characters which are not specified in conversion table (such as hyphens) are
> ignored. See https://en.wikipedia.org/wiki/Cologne_phonetics
> If the input is "test-test" the step results will be:
> # 20822082
> # 2082082
> # 28282
> The expected result for "test-test" is therefor 28282.
> The actual result for "test-test" is 282{color:#FF}2{color}82.
> This bug is caused by the fix from
> [https://github.com/apache/commons-codec/commit/72c8759a22c6552a2dfcdf61b29729f981752879]
> and is present since 1.5
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CODEC-246) ColognePhoneticTest.testIsEncodeEquals missing assertions
[ https://issues.apache.org/jira/browse/CODEC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated CODEC-246: --- Fix Version/s: 1.12 > ColognePhoneticTest.testIsEncodeEquals missing assertions > - > > Key: CODEC-246 > URL: https://issues.apache.org/jira/browse/CODEC-246 > Project: Commons Codec > Issue Type: Improvement >Reporter: Oscar Luis Vera Pérez >Priority: Trivial > Fix For: 1.12 > > > The test method ColognePhoneticTest.isEncodeEquals misses an assertion to > properly verify the ColognePhonetic.isEncodeEquals method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CODEC-252) Make B64 salt generator Random -> ThreadLocalRandom
[
https://issues.apache.org/jira/browse/CODEC-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated CODEC-252:
---
Fix Version/s: (was: 1.11.1)
> Make B64 salt generator Random -> ThreadLocalRandom
> ---
>
> Key: CODEC-252
> URL: https://issues.apache.org/jira/browse/CODEC-252
> Project: Commons Codec
> Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.12
>
>
> For the sake of performance, I want {{Random}} in {{B64.java}}, the salt
> generator for our hashes, to be a {{ThreadLocalRandom}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CODEC-240) Add Percent-Encoding Codec (described in RFC3986 and RFC7578)
[ https://issues.apache.org/jira/browse/CODEC-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins resolved CODEC-240. Resolution: Fixed > Add Percent-Encoding Codec (described in RFC3986 and RFC7578) > - > > Key: CODEC-240 > URL: https://issues.apache.org/jira/browse/CODEC-240 > Project: Commons Codec > Issue Type: New Feature >Reporter: Ioannis Sermetziadis >Priority: Minor > Fix For: 1.12 > > > Similar but more generic than the URLCodec. > Reference: https://tools.ietf.org/html/rfc3986#section-2.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CODEC-240) Add Percent-Encoding Codec (described in RFC3986 and RFC7578)
[ https://issues.apache.org/jira/browse/CODEC-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed CODEC-240. -- > Add Percent-Encoding Codec (described in RFC3986 and RFC7578) > - > > Key: CODEC-240 > URL: https://issues.apache.org/jira/browse/CODEC-240 > Project: Commons Codec > Issue Type: New Feature >Reporter: Ioannis Sermetziadis >Priority: Minor > Fix For: 1.12 > > > Similar but more generic than the URLCodec. > Reference: https://tools.ietf.org/html/rfc3986#section-2.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CODEC-240) Add Percent-Encoding Codec (described in RFC3986 and RFC7578)
[ https://issues.apache.org/jira/browse/CODEC-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated CODEC-240: --- Fix Version/s: 1.12 > Add Percent-Encoding Codec (described in RFC3986 and RFC7578) > - > > Key: CODEC-240 > URL: https://issues.apache.org/jira/browse/CODEC-240 > Project: Commons Codec > Issue Type: New Feature >Reporter: Ioannis Sermetziadis >Priority: Minor > Fix For: 1.12 > > > Similar but more generic than the URLCodec. > Reference: https://tools.ietf.org/html/rfc3986#section-2.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
