[jira] [Updated] (IMAGING-323) Verify that all ImageParsers behave in a uniform way when null arguments are given
[ https://issues.apache.org/jira/browse/IMAGING-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-323: --- Fix Version/s: 1.0 (was: 1.0-alpha3) > Verify that all ImageParsers behave in a uniform way when null arguments are > given > -- > > Key: IMAGING-323 > URL: https://issues.apache.org/jira/browse/IMAGING-323 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha2 >Reporter: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0 > > Attachments: image-2022-01-16-10-30-54-266.png > > > From IMAGING-159 review feedback: > [https://github.com/apache/commons-imaging/pull/116#discussion_r785343370] > about this Javadoc: > !image-2022-01-16-10-30-54-266.png! > We must make sure that the ImageParser's behave in the same predictable way, > when null params are passed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IMAGING-322) In ImageFormat, use Lists instead of arrays
[
https://issues.apache.org/jira/browse/IMAGING-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-322:
---
Fix Version/s: 1.0
(was: 1.0-alpha3)
> In ImageFormat, use Lists instead of arrays
> ---
>
> Key: IMAGING-322
> URL: https://issues.apache.org/jira/browse/IMAGING-322
> Project: Commons Imaging
> Issue Type: Improvement
> Components: imaging.*
>Affects Versions: 1.0-alpha2
>Reporter: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.0
>
> Attachments: image-2022-01-16-10-27-54-267.png
>
>
> From IMAGING-159 review feedback:
> https://github.com/apache/commons-imaging/pull/116#discussion_r762471218
> >Use {{List}} instead of {{{}String[]{}}}? I generally find lists
> >easier to work with, especially for streams.
> !image-2022-01-16-10-27-54-267.png!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IMAGING-310) JpegImageParser: Grayscale JPEG file with app14Segment returns ColorType.UNKNOWN
[
https://issues.apache.org/jira/browse/IMAGING-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-310:
---
Fix Version/s: 1.0
> JpegImageParser: Grayscale JPEG file with app14Segment returns
> ColorType.UNKNOWN
>
>
> Key: IMAGING-310
> URL: https://issues.apache.org/jira/browse/IMAGING-310
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: John Phillips
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0
>
> Attachments: sample-grayscale-with-app14segment.jpg
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> In org.apache.commons.imaging.formats.jpeg. the logic to determine colorType
> (lines 825-970) does not account for a Grayscale image when there is an app14
> segment present.
> When the number of components is 1 or 2, the colorType should always be
> Grayscale. None of the other logic would change that.
> It seems to me that the switch (numberOfComponents) statement should be moved
> to the top of this bit of code, and the rest of the logic should handled
> under Case 3 & 4:
> {noformat}
> // See
> http://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
> ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
> switch (numberOfComponents) {
> case 1:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> break;
>
> case 2:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> transparent = true;
> break;
>
> case 3:
> case 4:
> // Some images have both JFIF/APP0 and APP14.
> // JFIF is meant to win but in them APP14 is clearly right, so make it
> win.
> if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
> etc.
> {noformat}
> Attached sample-grayscale-with-app14segment.jpg, which can be used to
> demonstrate the issue.
> I've modified the code locally, but I'm a newbie at submitting
> pull-requests
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IMAGING-155) Remove file loading framework
[ https://issues.apache.org/jira/browse/IMAGING-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-155: --- Fix Version/s: 1.0 (was: 1.0-alpha3) > Remove file loading framework > - > > Key: IMAGING-155 > URL: https://issues.apache.org/jira/browse/IMAGING-155 > Project: Commons Imaging > Issue Type: Test >Affects Versions: Patch Needed >Reporter: Benedikt Ritter >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently test files are loaded through the use of a self implemented > framework, which implements a custom file tree traversal. Instead of this, we > should just use standard Java file loading mechanisms like > Class.getResource(String) and the like. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IMAGING-310) JpegImageParser: Grayscale JPEG file with app14Segment returns ColorType.UNKNOWN
[
https://issues.apache.org/jira/browse/IMAGING-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-310:
---
Fix Version/s: (was: 1.0-alpha3)
> JpegImageParser: Grayscale JPEG file with app14Segment returns
> ColorType.UNKNOWN
>
>
> Key: IMAGING-310
> URL: https://issues.apache.org/jira/browse/IMAGING-310
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: John Phillips
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: sample-grayscale-with-app14segment.jpg
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> In org.apache.commons.imaging.formats.jpeg. the logic to determine colorType
> (lines 825-970) does not account for a Grayscale image when there is an app14
> segment present.
> When the number of components is 1 or 2, the colorType should always be
> Grayscale. None of the other logic would change that.
> It seems to me that the switch (numberOfComponents) statement should be moved
> to the top of this bit of code, and the rest of the logic should handled
> under Case 3 & 4:
> {noformat}
> // See
> http://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
> ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
> switch (numberOfComponents) {
> case 1:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> break;
>
> case 2:
> colorType = ImageInfo.ColorType.GRAYSCALE;
> transparent = true;
> break;
>
> case 3:
> case 4:
> // Some images have both JFIF/APP0 and APP14.
> // JFIF is meant to win but in them APP14 is clearly right, so make it
> win.
> if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
> etc.
> {noformat}
> Attached sample-grayscale-with-app14segment.jpg, which can be used to
> demonstrate the issue.
> I've modified the code locally, but I'm a newbie at submitting
> pull-requests
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IMAGING-269) Remove or reduce duplication in DataReaderStrips
[ https://issues.apache.org/jira/browse/IMAGING-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-269: --- Fix Version/s: 1.0 (was: 1.0-alpha3) > Remove or reduce duplication in DataReaderStrips > > > Key: IMAGING-269 > URL: https://issues.apache.org/jira/browse/IMAGING-269 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: TIFF >Affects Versions: 1.0-alpha2 >Reporter: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > From discussion in the PR #98: > [https://github.com/apache/commons-imaging/pull/98#discussion_r491309213] > There's some code that could be improved, which would either remove or reduce > the duplication. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IMAGING-282) NullPointerException in org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata() when GraphicControlExtension is null
[ https://issues.apache.org/jira/browse/IMAGING-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-282: --- Fix Version/s: 1.0 (was: 1.0-alpha3) > NullPointerException in > org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata() when > GraphicControlExtension is null > - > > Key: IMAGING-282 > URL: https://issues.apache.org/jira/browse/IMAGING-282 > Project: Commons Imaging > Issue Type: Bug > Components: Format: GIF >Affects Versions: 1.0-alpha2 >Reporter: Samuel Monsarrat >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0 > > Attachments: problem.gif > > > The attached gif file produces a NullPointerException in > org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata() l553 due > to variable id not having a GraphicControlExtension component (id.gce = null). > This is set to null in findAllImageData l715. > Elsewhere in org.apache.commons.imaging.formats.gif.GifImageParser is tested > for null (l746). > This gif seems to contain incorrect metadata. Simply re-saving it with > ImageMagick correct the issue but since the gif is correctly displayed by all > viewers at my disposal it would seem that org.apache.commons.imaging needs to > be more permissive. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IMAGING-226) Add support for TIFF Zlib/deflate compression
[ https://issues.apache.org/jira/browse/IMAGING-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-226: --- Fix Version/s: 1.0 (was: 1.0-alpha3) > Add support for TIFF Zlib/deflate compression > - > > Key: IMAGING-226 > URL: https://issues.apache.org/jira/browse/IMAGING-226 > Project: Commons Imaging > Issue Type: Improvement >Affects Versions: 1.0-alpha1 >Reporter: Paul Austin >Priority: Minor > Fix For: 1.0 > > > Add support for the TIFF deflate compression. > 0x0008 Deflate, Adobe variant (official) read/write > 0x80B2 Deflate, PKZIP variant (obsolete) read > Also fixes a bug in TiffReader.readDirectories that ignored the readImageData > parameter. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IMAGING-221) updateExifMetadataLossless restructures meta data (and problems with Maker Notes)
[ https://issues.apache.org/jira/browse/IMAGING-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-221: --- Fix Version/s: 1.0 (was: 1.0-alpha3) > updateExifMetadataLossless restructures meta data (and problems with Maker > Notes) > - > > Key: IMAGING-221 > URL: https://issues.apache.org/jira/browse/IMAGING-221 > Project: Commons Imaging > Issue Type: Bug >Reporter: Joakim Knudsen >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0 > > Attachments: mine-gps.JPG, mine-metadata.JPG, mine-original.JPG, > mine.JPG, mine.JPG.html, original.JPG, original.html, tagsmissing.png, > test.JPG, test.html > > > ExifRewriter's *updateExifMetadataLossless* method causes the meta data of > the JPEG to be completely reordered after writing. This, in itself, might not > be a big concern, but it's a bit unexpected when the method is named > "lossless". More worryingly, I also find problems are introduced wrt. the > Maker Notes tag (odd offset). > I've produced an example of the problem in the attached JPEG file, using > ExifTool to validate/analyze the images before and after. The image is taken > by a Sony Xperia Z5 phone, and the "original.JPG" validates OK. After > modifying the contents of the UserComments tag (value: "Test") the modified > image produces a warning: > Verifying the attached photo using ExifTool gives the following output: > $ ./exiftool\(-k\).exe -validate -warning -a ../test.JPG > -- press RETURN -- > > Validate : 1 Warning (all minor) > Warning : [minor] Possibly incorrect maker notes > offsets (fix by -628?) > > Using ExifTool's -htmldump option, it is easy to see how the meta data has > been affected. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (IMAGING-326) Use JDK's multiplyExact to avoid integer overflows
[ https://issues.apache.org/jira/browse/IMAGING-326?focusedWorklogId=768832=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-768832 ] ASF GitHub Bot logged work on IMAGING-326: -- Author: ASF GitHub Bot Created on: 11/May/22 04:35 Start Date: 11/May/22 04:35 Worklog Time Spent: 10m Work Description: kinow opened a new pull request, #219: URL: https://github.com/apache/commons-imaging/pull/219 …t overflows This one will take a long time to be done over the code base. I didn't apply it everywhere, but I may still have overdone it. For someday :-) Issue Time Tracking --- Worklog Id: (was: 768832) Remaining Estimate: 0h Time Spent: 10m > Use JDK's multiplyExact to avoid integer overflows > -- > > Key: IMAGING-326 > URL: https://issues.apache.org/jira/browse/IMAGING-326 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha2 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Blocker > Fix For: 1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See PR > [https://github.com/apache/commons-imaging/pull/196#discussion_r790148843] > for context. > Integer overflow is a common source of problems in Imaging. The work on this > issue is to address when that could happen and prevent it of doing so. > Java 8 includes methods like > [multiplyExact|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Math.html#multiplyExact(int,int)] > which are convenient for us. > NOTE: we should start fixing it by the integer overflow in the PR linked > above. Then go over the rest of the code, applying it to other places where > integers are multipled/added/etc, and where the values could result in OOM or > other annoying security issues (i.e. we don't need to blindly replace every + > operation by addExactly). > -Bruno -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-imaging] kinow opened a new pull request, #219: [IMAGING-326] Use add/multiply/subtract exact JVM methods to avoid in…
kinow opened a new pull request, #219: URL: https://github.com/apache/commons-imaging/pull/219 …t overflows This one will take a long time to be done over the code base. I didn't apply it everywhere, but I may still have overdone it. For someday :-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (IMAGING-326) Use JDK's multiplyExact to avoid integer overflows
[ https://issues.apache.org/jira/browse/IMAGING-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IMAGING-326: --- Assignee: Bruno P. Kinoshita > Use JDK's multiplyExact to avoid integer overflows > -- > > Key: IMAGING-326 > URL: https://issues.apache.org/jira/browse/IMAGING-326 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha2 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Blocker > Fix For: 1.0 > > > See PR > [https://github.com/apache/commons-imaging/pull/196#discussion_r790148843] > for context. > Integer overflow is a common source of problems in Imaging. The work on this > issue is to address when that could happen and prevent it of doing so. > Java 8 includes methods like > [multiplyExact|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Math.html#multiplyExact(int,int)] > which are convenient for us. > NOTE: we should start fixing it by the integer overflow in the PR linked > above. Then go over the rest of the code, applying it to other places where > integers are multipled/added/etc, and where the values could result in OOM or > other annoying security issues (i.e. we don't need to blindly replace every + > operation by addExactly). > -Bruno -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-configuration] kinow commented on a diff in pull request #107: Bump mailapi from 1.6.6 to 2.0.1
kinow commented on code in PR #107:
URL:
https://github.com/apache/commons-configuration/pull/107#discussion_r869852144
##
src/test/java/org/apache/commons/configuration2/TestDataConfiguration.java:
##
@@ -73,10 +73,13 @@ private static Date expectedDate() throws ParseException {
/**
* Create an instance of InternetAddress. This trick is necessary to
compile and run the test with Java 1.3 and the
- * javamail-1.4 which is not compatible with Java 1.3
+ * javamail-1.4 which is not compatible with Java 1.3.
+ *
+ * javamail-2.0 had a namespace change, moving javax.mail.* to
jakarta.mail.*. This test verifies if we have
+ * javax.mail.* in the classpath before trying the Jakarta classes.
*/
private Object createInternetAddress(final String email) throws Exception {
-final Class cls =
Class.forName("javax.mail.internet.InternetAddress");
+final Class cls =
Class.forName("jakarta.mail.internet.InternetAddress");
Review Comment:
No, only the Jakarta path. I started modifying the test to create a test
object using javax.mail too, but then I couldn't find a clear way to load the
javax.mail into the classpath. `mailapi` has a different package structure for
the mail part, but it also has a common `com.sun.mail` part…
Adding two versions of the `mailapi` results in only the last dependency
being added by Maven, and doesn't really sound like a good idea.
Maybe we should leave it as it is until we decide to drop javax.mail and
support only jakarta.mail, or leave it untested? Or maybe there's some other
way to test with different dependencies (never had to do that). WDYT?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-io] garydgregory commented on pull request #350: Add FileWatcher feature
garydgregory commented on PR #350: URL: https://github.com/apache/commons-io/pull/350#issuecomment-1123083646 Hello @saiple, -1. I am am sorry but this code seems flawed and not in the right home. It seems too easy to break an app on exit or at time really. It's hard to tell of course since this PR has zero unit tests so use cases are imaginary at this point. It seems that little or no thought was given to concurrency issues, for example, the use of a concurrent unsafe list, use of non-daemon threads, threads updating a global variable. IMO, the "lines of code" argument is not relevant since you can abstract these in a method in your app. I am not a fan of duplicating this kind of functionality across IO and VFS. In my mind, IO is a low level library and VFS is a higher level library where I see this type of functionality residing. I am curious to learn what others think. What is also problematic IMO is the use of a global variable to track threads as well as the other issues mentioned. So -1. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COLLECTIONS-803) CaseInsensitiveMap prevent duplicate key conversion on put
[
https://issues.apache.org/jira/browse/COLLECTIONS-803?focusedWorklogId=768703=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-768703
]
ASF GitHub Bot logged work on COLLECTIONS-803:
--
Author: ASF GitHub Bot
Created on: 10/May/22 20:39
Start Date: 10/May/22 20:39
Worklog Time Spent: 10m
Work Description: codecov-commenter commented on PR #276:
URL:
https://github.com/apache/commons-collections/pull/276#issuecomment-1122838755
#
[Codecov](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
Report
> Merging
[#276](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
(3ac374a) into
[master](https://codecov.io/gh/apache/commons-collections/commit/1677daceab74895fdf5056c9a48aa94f9e709fb9?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
(1677dac) will **increase** coverage by `0.01%`.
> The diff coverage is `94.73%`.
```diff
@@ Coverage Diff @@
## master #276 +/- ##
+ Coverage 85.87% 85.88% +0.01%
- Complexity 4676 4681 +5
Files 292 292
Lines 1346913488 +19
Branches 1955 1957 +2
+ Hits 1156611584 +18
Misses 1326 1326
- Partials577 578 +1
```
| [Impacted
Files](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
| Coverage Δ | |
|---|---|---|
|
[...e/commons/collections4/map/CaseInsensitiveMap.java](https://codecov.io/gh/apache/commons-collections/pull/276/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L21hcC9DYXNlSW5zZW5zaXRpdmVNYXAuamF2YQ==)
| `92.50% <94.73%> (+2.02%)` | :arrow_up: |
--
[Continue to review full report at
Codecov](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=continue_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation).
> **Legend** - [Click here to learn
more](https://docs.codecov.io/docs/codecov-delta?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
> `Δ = absolute (impact)`, `ø = not affected`, `? = missing data`
> Powered by
[Codecov](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=footer_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation).
Last update
[1677dac...3ac374a](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=lastupdated_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation).
Read the [comment
docs](https://docs.codecov.io/docs/pull-request-comments?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation).
Issue Time Tracking
---
Worklog Id: (was: 768703)
Time Spent: 1h 40m (was: 1.5h)
> CaseInsensitiveMap prevent duplicate key conversion on put
> --
>
> Key: COLLECTIONS-803
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-803
> Project: Commons Collections
> Issue Type: Improvement
> Components: Map
>Affects Versions: 4.4
>Reporter: Simulant
>Priority: Minor
> Labels: performance
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> When adding a new item into a {{CaseInsensitiveMap}} the {{convertKey(key)}}
> method is called twice, once in the {{put(key, value)}} method and second in
> the {{createEntry(next, hashCode, key, value)}} method. The result could be
> re-used resulting in a better performance.
> Depending on the {{toString()}} implementation of the key and the resulting
> length of the key before the lower case conversion the operation can get
> expensive and should not be called twice, as the {{CaseInsensitiveMap}}
> overwrites the {{convertKey(key)}} method and makes it more expensive and
> depending on the input unlike in the implementation of the
> {{AbstractHashedMap}}.
[GitHub] [commons-collections] codecov-commenter commented on pull request #276: COLLECTIONS-803: prevent duplicate call to convertKey on put for CaseInsensitiveMap
codecov-commenter commented on PR #276: URL: https://github.com/apache/commons-collections/pull/276#issuecomment-1122838755 # [Codecov](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#276](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (3ac374a) into [master](https://codecov.io/gh/apache/commons-collections/commit/1677daceab74895fdf5056c9a48aa94f9e709fb9?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (1677dac) will **increase** coverage by `0.01%`. > The diff coverage is `94.73%`. ```diff @@ Coverage Diff @@ ## master #276 +/- ## + Coverage 85.87% 85.88% +0.01% - Complexity 4676 4681 +5 Files 292 292 Lines 1346913488 +19 Branches 1955 1957 +2 + Hits 1156611584 +18 Misses 1326 1326 - Partials577 578 +1 ``` | [Impacted Files](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...e/commons/collections4/map/CaseInsensitiveMap.java](https://codecov.io/gh/apache/commons-collections/pull/276/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L21hcC9DYXNlSW5zZW5zaXRpdmVNYXAuamF2YQ==) | `92.50% <94.73%> (+2.02%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=continue_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=footer_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). Last update [1677dac...3ac374a](https://codecov.io/gh/apache/commons-collections/pull/276?src=pr=lastupdated_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] dependabot[bot] commented on pull request #68: Bump spotbugs from 4.2.2 to 4.6.0
dependabot[bot] commented on PR #68: URL: https://github.com/apache/commons-email/pull/68#issuecomment-1122831435 Superseded by #76. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] dependabot[bot] closed pull request #68: Bump spotbugs from 4.2.2 to 4.6.0
dependabot[bot] closed pull request #68: Bump spotbugs from 4.2.2 to 4.6.0 URL: https://github.com/apache/commons-email/pull/68 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] dependabot[bot] opened a new pull request, #76: Bump spotbugs from 4.2.2 to 4.7.0
dependabot[bot] opened a new pull request, #76: URL: https://github.com/apache/commons-email/pull/76 Bumps [spotbugs](https://github.com/spotbugs/spotbugs) from 4.2.2 to 4.7.0. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases;>spotbugs's releases. SpotBugs 4.7.0 CHANGELOG Changed Updated documentation by adding parenthesis () to the negative odd check message (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1995;>#1995) https://github.com/axkr;>@axkr Let the Plugin class implement AutoCloseable so we can release the .jar file (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/2024;>#2024) https://github.com/gtoison;>@gtoison Fixed Fixed reports to truncate existing files before writing new content (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1950;>#1950) https://github.com/sdati;>@sdati Fixed traversal of nested archives governed by -nested:true (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1930;>#1930) https://github.com/Vogel612;>@Vogel612 Warnings of deprecated System::setSecurityManager calls on Java 17 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1983;>#1983) https://github.com/wborn;>@wborn Fixed false positive SSD bug for locking on java.lang.Class objects (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1978;>#1978) https://github.com/jpschewe;>@jpschewe FindReturnRef throws an IllegalArgumentException unexpectedly (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/2019;>#2019) https://github.com/KengoTODA;>@KengoTODA Bumped Saxon-HE from 10.6 to 11.3 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1955;>#1955, https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1999;>#1999) Bump ObjectWeb ASM from 9.2 to 9.3 supporting JDK 19 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/2004;>#2004) Added New detector ThrowingExceptions and introduced new bug types https://github.com/oroszbd;>@oroszbd THROWS_METHOD_THROWS_RUNTIMEEXCEPTION is reported in case of a method throwing RuntimeException, THROWS_METHOD_THROWS_CLAUSE_BASIC_EXCEPTION is reported when a method has Exception in its throws clause and THROWS_METHOD_THROWS_CLAUSE_THROWABLE is reported when a method has Throwable in its throws clause (See https://wiki.sei.cmu.edu/confluence/display/java/ERR07-J.+Do+not+throw+RuntimeException%2C+Exception%2C+or+Throwable;>SEI CERT ERR07-J) New rule PERM_SUPER_NOT_CALLED_IN_GETPERMISSIONS to warn for custom class loaders who do not call their superclasses' getPermissions() in their getPermissions() method. This rule based on the SEI CERT rule SEC07-J Call the superclass's getPermissions() method when writing a custom class loader. (https://wiki.sei.cmu.edu/confluence/display/java/SEC07-J.+Call+the+superclass%27s+getPermissions%28%29+method+when+writing+a+custom+class+loader;>#SEC07-J) https://github.com/baloghadamsoftware;>@baloghadamsoftware New rule USC_POTENTIAL_SECURITY_CHECK_BASED_ON_UNTRUSTED_SOURCE to detect cases where a non-final method of a non-final class is called from public methods of public classes and then the same method is called on the same object inside a doPrivileged block. Since the called method may have been overridden to behave differently on the first and second invocations this is a possible security check based on an unreliable source. This rule is based on SEC02-J. Do not base security checks on untrusted sources. (https://wiki.sei.cmu.edu/confluence/display/java/SEC02-J.+Do+not+base+security+checks+on+untrusted+sources;>#SEC02-J) https://github.com/baloghadamsoftware;>@baloghadamsoftware New detector DontUseFloatsAsLoopCounters to detect usage of floating-point variables as loop counters (FL_FLOATS_AS_LOOP_COUNTERS), according to SEI CERT rules https://wiki.sei.cmu.edu/confluence/display/java/NUM09-J.+Do+not+use+floating-point+variables+as+loop+counters;>NUM09-J. Do not use floating-point variables as loop counters https://github.com/adrianturtoczki;>@adrianturtoczki New test detector ViewCFG to visualize the control-flow graph for SpotBugs developers https://github.com/baloghadamsoftware;>@baloghadamsoftware CHECKSUM file checksum (sha256) spotbugs-4.7.0-javadoc.jar 43745221e8fdf50fa2f89d659034523dd58da3d10223de6e0c91704c07e025a0 spotbugs-4.7.0-sources.jar 6e90f856826b48a3031e2cb903534b4fdb494759863ea14e8df93c9cf15a272c spotbugs-4.7.0.tgz 8c871e279c7d9b1933158db6355b8ac817a84fd724b88b1e393e3abcf6874910 spotbugs-4.7.0.zip 9ee793b0f3f78901089211dfa67b8603e38fd1abd64eac09d2590df506cfedf5 spotbugs-annotations-4.7.0-javadoc.jar 76a9a7d45590494a220840d173809b2fe0ec50e554435dd9b28de9312cc6a34a spotbugs-annotations-4.7.0-sources.jar
[GitHub] [commons-io] saiple commented on pull request #350: Add FileWatcher feature
saiple commented on PR #350: URL: https://github.com/apache/commons-io/pull/350#issuecomment-1122718887 > Hm, Commons VFS already does stuff like this, for example https://commons.apache.org/proper/commons-vfs/commons-vfs2/apidocs/org/apache/commons/vfs2/impl/DefaultFileMonitor.html Hi @garydgregory ! Sorry for long delay. Yea, I know that Commons VFS this feature, but I wanted creating watchers by calling one line of code, so most of methods of this lib (Commons IO) have this ideology. In VFS it need to write at less 5 lines of code for reaching it, it makes code less cleaner. I use this lib in my private projects, and I wanted to use this method natively from lib. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] saiple commented on a diff in pull request #350: Add FileWatcher feature
saiple commented on code in PR #350: URL: https://github.com/apache/commons-io/pull/350#discussion_r869540696 ## src/main/java/org/apache/commons/io/FileWatcher.java: ## @@ -0,0 +1,90 @@ +package org.apache.commons.io; Review Comment: added ## src/main/java/org/apache/commons/io/watcher/WatcherProperties.java: ## @@ -0,0 +1,31 @@ +package org.apache.commons.io.watcher; Review Comment: added ## src/main/java/org/apache/commons/io/watcher/WatcherException.java: ## @@ -0,0 +1,7 @@ +package org.apache.commons.io.watcher; Review Comment: added -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[
https://issues.apache.org/jira/browse/CSV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry M. Caceres updated CSV-296:
-
Description:
I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
{_}(see attached ZIP file){_}:
{code:java}
CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
.withIgnoreEmptyLines(true).withTrim(true);{code}
However, a quoted string that begins after a delimiter followed by preceding
whitespace is not properly parsed. For example:
{code:java}
GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
"Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
"John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
"Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
{code}
* Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on the
first record? This leads to the actual value containing the quotation marks
instead of them being stripped off.
* The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas, NV
89102"}}*{color} on the second record leads to it to being parsed as two
values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
89102"}}{*}.
* The third record is the only one that parses as expected.
I believe that this is because the trimming is done *after* the value is being
parsed rather than consuming the whitespace following the delimiter during
parsing. Either that, or the check for a quoted string is occurring *before*
the whitespace is being consumed.
*NOTE:* I have attached a ZIP file that easily reproduces the problem with the
CSV file given above.
To build the attached project use Apache Maven and then execute using using
Java 11:
{code:java}
> unzip csvfail.zip
> cd csvfail
> mvn package
> java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
was:
I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set.
{code:java}
CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
.withIgnoreEmptyLines(true).withTrim(true);{code}
However, a quoted string that begins after a delimiter followed by preceding
whitespace is not properly parsed.
For example:
{code:java}
GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
"Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
"John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
"Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
{code}
Notice the whitespace preceding *{{"Schmoe"}}* on the first record? This leads
to the actual value containing the quotation marks instead of them being
stripped off.
The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas, NV
89102"}}*{color} on the second record leads to it to being parsed as two
values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
89102"}}{*}.
The third record is the only one that parses as expected.
I believe that this is because the trimming is done *after* the value is being
parsed rather than consuming the whitespace following the delimiter during
parsing. Either that, or the check for a quoted string is occurring *before*
the whitespace is being consumed.
*NOTE:* I have attached a ZIP file that easily reproduces the problem with the
CSV file given above.
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8, 1.9.0
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
>
[jira] [Created] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
Barry M. Caceres created CSV-296:
Summary: Delimiter followed by Whitespace then by Quotes Failing
with setTrim(true)
Key: CSV-296
URL: https://issues.apache.org/jira/browse/CSV-296
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.9.0, 1.8
Environment: +{*}macOS{*}:+
{code:java}
> uname -a
Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
{code:java}
> java -version
openjdk version "11.0.14" 2022-01-18
OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode) {code}
{+}*Linux*{+}:
{code:java}
> uname -a
Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
x86_64 x86_64 x86_64 GNU/Linux {code}
{code:java}
> java -version
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
mode){code}
Reporter: Barry M. Caceres
Attachments: csvfail.zip
I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set.
{code:java}
CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
.withIgnoreEmptyLines(true).withTrim(true);{code}
However, a quoted string that begins after a delimiter followed by preceding
whitespace is not properly parsed.
For example:
{code:java}
GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
"Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
"John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
"Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
{code}
Notice the whitespace preceding *{{"Schmoe"}}* on the first record? This leads
to the actual value containing the quotation marks instead of them being
stripped off.
The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas, NV
89102"}}*{color} on the second record leads to it to being parsed as two
values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
89102"}}{*}.
The third record is the only one that parses as expected.
I believe that this is because the trimming is done *after* the value is being
parsed rather than consuming the whitespace following the delimiter during
parsing. Either that, or the check for a quoted string is occurring *before*
the whitespace is being consumed.
*NOTE:* I have attached a ZIP file that easily reproduces the problem with the
CSV file given above.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Work logged] (LANG-1662) Create methods on ReflectionToStringBuilder to reflect only select fields
[ https://issues.apache.org/jira/browse/LANG-1662?focusedWorklogId=768577=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-768577 ] ASF GitHub Bot logged work on LANG-1662: Author: ASF GitHub Bot Created on: 10/May/22 16:42 Start Date: 10/May/22 16:42 Worklog Time Spent: 10m Work Description: GutoVeronezi commented on PR #849: URL: https://github.com/apache/commons-lang/pull/849#issuecomment-1122632501 Hi, can anyone else review this PR? Best regards, Daniel Issue Time Tracking --- Worklog Id: (was: 768577) Remaining Estimate: 3h 40m (was: 3h 50m) Time Spent: 2h 20m (was: 2h 10m) > Create methods on ReflectionToStringBuilder to reflect only select fields > - > > Key: LANG-1662 > URL: https://issues.apache.org/jira/browse/LANG-1662 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Reporter: Daniel Augusto Veronezi Salvador >Priority: Minor > Original Estimate: 6h > Time Spent: 2h 20m > Remaining Estimate: 3h 40m > > *ReflectionToStringBuilder* has methods to exclude fields from *toString*; If > we have an object with several fields and want to reflect only a fews, we > have to list all the fields that we don't want to reflect and pass to > *excludeFieldNames*. > Would be valid implement a way to pass the fields that we want and reflect > only the selected fields? > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-lang] GutoVeronezi commented on pull request #849: [LANG-1662] Create methods on ReflectionToStringBuilder to reflect only select fields
GutoVeronezi commented on PR #849: URL: https://github.com/apache/commons-lang/pull/849#issuecomment-1122632501 Hi, can anyone else review this PR? Best regards, Daniel -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-614) Use FileTime for time fields in SevenZipArchiveEntry
[ https://issues.apache.org/jira/browse/COMPRESS-614?focusedWorklogId=768560=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-768560 ] ASF GitHub Bot logged work on COMPRESS-614: --- Author: ASF GitHub Bot Created on: 10/May/22 15:49 Start Date: 10/May/22 15:49 Worklog Time Spent: 10m Work Description: andrebrait commented on PR #256: URL: https://github.com/apache/commons-compress/pull/256#issuecomment-1122570793 @garydgregory done ;) Issue Time Tracking --- Worklog Id: (was: 768560) Time Spent: 2h 40m (was: 2.5h) > Use FileTime for time fields in SevenZipArchiveEntry > > > Key: COMPRESS-614 > URL: https://issues.apache.org/jira/browse/COMPRESS-614 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: 7zip > Time Spent: 2h 40m > Remaining Estimate: 0h > > Instead of java.util.Date, which caps precision in milliseconds, let's move > on to using FileTime. > We can keep backwards compatibility through the getters and setters for > modification, access and creation dates. > If you're ok with it, I'll send a PR for this. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-compress] andrebrait commented on pull request #256: COMPRESS-614: Use FileTime in SevenZArchiveEntry
andrebrait commented on PR #256: URL: https://github.com/apache/commons-compress/pull/256#issuecomment-1122570793 @garydgregory done ;) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] darkma773r commented on a diff in pull request #107: Bump mailapi from 1.6.6 to 2.0.1
darkma773r commented on code in PR #107:
URL:
https://github.com/apache/commons-configuration/pull/107#discussion_r869300908
##
src/test/java/org/apache/commons/configuration2/TestDataConfiguration.java:
##
@@ -73,10 +73,13 @@ private static Date expectedDate() throws ParseException {
/**
* Create an instance of InternetAddress. This trick is necessary to
compile and run the test with Java 1.3 and the
- * javamail-1.4 which is not compatible with Java 1.3
+ * javamail-1.4 which is not compatible with Java 1.3.
+ *
+ * javamail-2.0 had a namespace change, moving javax.mail.* to
jakarta.mail.*. This test verifies if we have
+ * javax.mail.* in the classpath before trying the Jakarta classes.
*/
private Object createInternetAddress(final String email) throws Exception {
-final Class cls =
Class.forName("javax.mail.internet.InternetAddress");
+final Class cls =
Class.forName("jakarta.mail.internet.InternetAddress");
Review Comment:
Are we hitting both paths in that `try-catch` during the unit tests?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-configuration] kinow commented on a diff in pull request #36: [CONFIGURATION-764] Default date lookup can not work for some specific
kinow commented on code in PR #36:
URL:
https://github.com/apache/commons-configuration/pull/36#discussion_r868846177
##
src/changes/changes.xml:
##
@@ -46,6 +46,9 @@
[Javadoc] Specify that typed getList returns null for missing key
#100.
+
+ Default date lookup can not work for some specific format
+
Review Comment:
You can leave `changes.xml` to be updated later by a committer, no need to
include in this PR :+1: (it's also conflicting with `master` now, so removing
it from this PR will fix that).
##
src/main/java/org/apache/commons/configuration2/interpol/StringLookupCatchExceptionAdapter.java:
##
@@ -0,0 +1,46 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.configuration2.interpol;
+
+import org.apache.commons.text.lookup.StringLookup;
+
+/**
+ * Extension of StringLookupAdapter, the difference is return null if catching
exception during lookup.
+ *
+ * @since 2.8.0
+ */
+class StringLookupCatchExceptionAdapter extends StringLookupAdapter
+{
+
+
+StringLookupCatchExceptionAdapter(final StringLookup stringLookup)
+{
+super(stringLookup);
+}
+
+@Override
+public Object lookup(final String key)
+{
+try {
+ return super.lookup(key);
+} catch (Exception e) {
+ return null;
+}
Review Comment:
Formatting issues above :point_up:
##
src/main/java/org/apache/commons/configuration2/interpol/StringLookupCatchExceptionAdapter.java:
##
@@ -0,0 +1,46 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.configuration2.interpol;
+
+import org.apache.commons.text.lookup.StringLookup;
+
+/**
+ * Extension of StringLookupAdapter, the difference is return null if catching
exception during lookup.
+ *
+ * @since 2.8.0
+ */
+class StringLookupCatchExceptionAdapter extends StringLookupAdapter
Review Comment:
Maybe `StringLookupAdapter` could have a parameter like `suppress=false`
that's disabled by default? This class is not public, so either way is fine, we
can improve on it later IMO.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
