[jira] [Comment Edited] (LANG-1445) NumberUtils.createNumber() incorrectly creates BigDecimal when a double type is specified
[
https://issues.apache.org/jira/browse/LANG-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235732#comment-17235732
]
Arturo Bernal edited comment on LANG-1445 at 1/3/21, 7:54 AM:
--
HI [~ggregory]
IMO this improvement its already implemented.
I think we can close the issues;
was (Author: arturobernalg):
HI [~ggregory]
This improvement its already implemented.
We can close the issues;
> NumberUtils.createNumber() incorrectly creates BigDecimal when a double type
> is specified
> -
>
> Key: LANG-1445
> URL: https://issues.apache.org/jira/browse/LANG-1445
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.8.1
>Reporter: Costa Theodosiou
>Priority: Major
> Attachments:
> NumberUtils_createNumber()_incorrectly_creates_BigDecimal_when_a_double_type_is_specified.patch
>
>
> {{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() +
> "D")}}
> and
> {{NumberUtils.createNumber(Double.valueOf(Double.MIN_VALUE).toString() +
> "F")}}
> are incorrectly creating BigDecimals.
> This is due to a bug:
> {{if (!(d.isInfinite() || d.floatValue() == 0.0D && !allZeros)) {}}
> which should be:
> {{if (!(d.isInfinite() || d.doubleValue() == 0.0D && !allZeros)) {}}
> A patch has been attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (LANG-1635) Count True function improvement
[ https://issues.apache.org/jira/browse/LANG-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal closed LANG-1635. --- > Count True function improvement > --- > > Key: LANG-1635 > URL: https://issues.apache.org/jira/browse/LANG-1635 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.11 >Reporter: Arturo Bernal >Priority: Major > Fix For: 3.12 > > Time Spent: 1h > Remaining Estimate: 0h > > I've had the need recently of count the "true" value in a array. I didn't > find any function that i can use easily and directly in BooleanUtils > Would be great if we have some function to do that -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (LANG-1635) Count True function improvement
[ https://issues.apache.org/jira/browse/LANG-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal resolved LANG-1635. - Resolution: Won't Fix > Count True function improvement > --- > > Key: LANG-1635 > URL: https://issues.apache.org/jira/browse/LANG-1635 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.11 >Reporter: Arturo Bernal >Priority: Major > Fix For: 3.12 > > Time Spent: 1h > Remaining Estimate: 0h > > I've had the need recently of count the "true" value in a array. I didn't > find any function that i can use easily and directly in BooleanUtils > Would be great if we have some function to do that -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-configuration] arturobernalg commented on pull request #91: Minor Improvements
arturobernalg commented on pull request #91: URL: https://github.com/apache/commons-configuration/pull/91#issuecomment-753580269 > I would just fix checkstyle issues in your PR, not everywhere. Great. Fix it 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] coveralls commented on pull request #690: (doc) Processor.java: check enum euqality with == instead of .equals() method
coveralls commented on pull request #690: URL: https://github.com/apache/commons-lang/pull/690#issuecomment-753562816 [](https://coveralls.io/builds/36043457) Coverage remained the same at 95.013% when pulling **a1cb4de8e40d52381fcc5b22677e4ef481121d89 on akarimin:master** into **48927030951c5f58d7eea559856b51faad0e07c9 on apache:master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] akarimin opened a new pull request #690: (doc) Processor.java: check enum euqality with == instead of .equals() method
akarimin opened a new pull request #690: URL: https://github.com/apache/commons-lang/pull/690 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (COMPRESS-503) "open when actually needed" for MultiReadOnlySeekableByteChannel
[
https://issues.apache.org/jira/browse/COMPRESS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lee closed COMPRESS-503.
--
Resolution: Duplicate
> "open when actually needed" for MultiReadOnlySeekableByteChannel
>
>
> Key: COMPRESS-503
> URL: https://issues.apache.org/jira/browse/COMPRESS-503
> Project: Commons Compress
> Issue Type: Improvement
>Affects Versions: 1.19, 1.20
>Reporter: Peter Alfred Lee
>Priority: Minor
> Fix For: 1.21
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When I was adding zip64 support for split zip, I encountered a problem :
> When adding testcases in {{Zip64SupportIT}}, I created a split zip with
> 10,000+ split segments. Then I found that I was unable to unzip it because
> there would be too many open files when extracting it. We can oepn the files
> when actually needed and therefore we can successfully extract such split
> zips with great amount of segments.
> I have set a threshold of 20 in {{MultiReadOnlySeekableByteChannel}}. The
> "open when actually needed" procedure will only work when the number of split
> segments is greater than the threshold.
>
> This may be used in ZipArchiveInputStream and ZipFile cause
> {{MultiReadOnlySeekableByteChannel}} is used in them.
>
> Actually this is a pretty rare case cause most split zips would not have too
> many segments. Just thinking about a split zip with 1,000+ segments - it must
> be a nightmare. So I'm not sure if this is needed for
> {{MultiReadOnlySeekableByteChannel.WDYT?}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (COMPRESS-540) Random access on Tar archive
[ https://issues.apache.org/jira/browse/COMPRESS-540?focusedWorklogId=530324&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530324 ] ASF GitHub Bot logged work on COMPRESS-540: --- Author: ASF GitHub Bot Created on: 03/Jan/21 02:50 Start Date: 03/Jan/21 02:50 Worklog Time Spent: 10m Work Description: PeterAlfredLee commented on a change in pull request #113: URL: https://github.com/apache/commons-compress/pull/113#discussion_r550947582 ## File path: src/main/java/org/apache/commons/compress/utils/BoundedArchiveInputStream.java ## @@ -0,0 +1,98 @@ +/* Review comment: I'm +1 for this. But IIRC there was a issue or mailing discussing about this : the `skip` implemention in Commons IO didn't use the `skip` of the InputStream it's reading from. I will try to find this. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 530324) Time Spent: 8h 40m (was: 8.5h) > Random access on Tar archive > > > Key: COMPRESS-540 > URL: https://issues.apache.org/jira/browse/COMPRESS-540 > Project: Commons Compress > Issue Type: Improvement >Reporter: Robin Schimpf >Priority: Major > Time Spent: 8h 40m > Remaining Estimate: 0h > > The TarArchiveInputStream only provides sequential access. If only a small > amount of files from the archive is needed large amount of data in the input > stream needs to be skipped. > Therefore I was working on a implementation to provide random access to > TarFiles equal to the ZipFile api. The basic idea behind the implementation > is the following > * Random access is backed by a SeekableByteChannel > * Read all headers of the tar file and save the place to the data of every > header > * User can request an input stream for any entry in the archive multiple > times -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee commented on a change in pull request #113: COMPRESS-540: Implement TarFile to allow random access to tar files
PeterAlfredLee commented on a change in pull request #113: URL: https://github.com/apache/commons-compress/pull/113#discussion_r550947582 ## File path: src/main/java/org/apache/commons/compress/utils/BoundedArchiveInputStream.java ## @@ -0,0 +1,98 @@ +/* Review comment: I'm +1 for this. But IIRC there was a issue or mailing discussing about this : the `skip` implemention in Commons IO didn't use the `skip` of the InputStream it's reading from. I will try to find this. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (FILEUPLOAD-285) MultipartStream API constructor has internal class
[ https://issues.apache.org/jira/browse/FILEUPLOAD-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257630#comment-17257630 ] Abhyankar Chaubey commented on FILEUPLOAD-285: -- [~joc...@apache.org] is there anything to work on this . from code ProgressNotifier is public static class --> https://github.com/apache/commons-fileupload/blob/8ff8ba4f19b16d404ed24c53e6e6afe3d25f0e4a/src/main/java/org/apache/commons/fileupload2/MultipartStream.java#L90 > MultipartStream API constructor has internal class > -- > > Key: FILEUPLOAD-285 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-285 > Project: Commons FileUpload > Issue Type: Bug >Reporter: Obidul >Priority: Major > > The last argument of the constructor is internal class (ProgressNotifier). > How to use notifier in the constructor. > MultipartStream(InputStream input, byte[] boundary, int bufSize, > MultipartStream.ProgressNotifier pNotifier) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257626#comment-17257626
]
Michael Osipov commented on LANG-1637:
--
{{WeekYear}} assumes that the wrapped rule handles years only.
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257625#comment-17257625
]
Michael Osipov edited comment on LANG-1637 at 1/3/21, 1:03 AM:
---
Here is a possible patch:
{noformat}
$ git diff
diff --git a/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
b/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
index 658e3cacb..2bbd7e22b 100644
--- a/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
+++ b/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
@@ -1293,7 +1293,7 @@ public int estimateLength() {
@Override
public void appendTo(final Appendable buffer, final Calendar calendar) throws
IOException {
- mRule.appendTo(buffer, calendar.getWeekYear());
+ mRule.appendTo(buffer, (estimateLength() == 2 ? calendar.getWeekYear() % 100
: calendar.getWeekYear() ));
}
@Override
{noformat}
was (Author: michael-o):
Here is a possible patch:
{code}
$ git diff
diff --git a/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
b/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
index 658e3cacb..2bbd7e22b 100644
--- a/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
+++ b/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
@@ -1293,7 +1293,7 @@ public int estimateLength() {
@Override
public void appendTo(final Appendable buffer, final Calendar calendar) throws
IOException {
- mRule.appendTo(buffer, calendar.getWeekYear());
+ mRule.appendTo(buffer, (estimateLength() == 2 ? calendar.getWeekYear() % 100
: calendar.getWeekYear() ));
}
@Override
{code}
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530319&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530319
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 03/Jan/21 01:02
Start Date: 03/Jan/21 01:02
Worklog Time Spent: 10m
Work Description: michael-o commented on a change in pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#discussion_r550939708
##
File path: src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
##
@@ -1118,7 +1118,7 @@ public void appendTo(final Appendable buffer, final
Calendar calendar) throws IO
*/
@Override
public final void appendTo(final Appendable buffer, final int value)
throws IOException {
-appendDigits(buffer, value);
+appendDigits(buffer, value % 100);
Review comment:
I am not convinced by this because it patches the wrong spot.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530319)
Time Spent: 3h 20m (was: 3h 10m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257625#comment-17257625
]
Michael Osipov commented on LANG-1637:
--
Here is a possible patch:
{code}
$ git diff
diff --git a/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
b/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
index 658e3cacb..2bbd7e22b 100644
--- a/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
+++ b/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
@@ -1293,7 +1293,7 @@ public int estimateLength() {
@Override
public void appendTo(final Appendable buffer, final Calendar calendar) throws
IOException {
- mRule.appendTo(buffer, calendar.getWeekYear());
+ mRule.appendTo(buffer, (estimateLength() == 2 ? calendar.getWeekYear() % 100
: calendar.getWeekYear() ));
}
@Override
{code}
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] michael-o commented on a change in pull request #688: [LANG-1637] Fix 2 digit week year formatting
michael-o commented on a change in pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#discussion_r550939708
##
File path: src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
##
@@ -1118,7 +1118,7 @@ public void appendTo(final Appendable buffer, final
Calendar calendar) throws IO
*/
@Override
public final void appendTo(final Appendable buffer, final int value)
throws IOException {
-appendDigits(buffer, value);
+appendDigits(buffer, value % 100);
Review comment:
I am not convinced by this because it patches the wrong spot.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257618#comment-17257618
]
Michael Osipov edited comment on LANG-1637 at 1/3/21, 12:26 AM:
OK, this was a misunderstanding. Sorry for that. Here is the problem: {{Y}}
denotes the ISO week year, not necessary the current year.
{{TwoDigitYearField.INSTANCE}} is passed to to {{WeekYear}} ctor. It calls the
former rule with {{calendar.getWeekYear()}}. The problem is that
{{TwoDigitYearField#appendTo(Appendable, int)}} expects a value between 0 and
99 because it uses {{#appendDigits()}} which operates on two-digit numbers
only. Everything else is undefined. Since it is an internal method it expects
the input to be always valid.
was (Author: michael-o):
OK, this was a misunderstanding. Sorry for that. Here is the problem: {{Y}}
denotes the ISO week year, not necessary the current year.
{{TwoDigitYearField.INSTANCE}} is passed to to {{WeekYear}} ctor. It calls the
former rule with {{calendar.getWeekYear()}}. The problem is that
{{TwoDigitYearField#appendTo(Appendable, int)}} expects a value between 0 and
99 because it uses {{##appendDigits()}} which operates on two-digit numbers
only. Everything else is undefined. Since it is an internal method it expects
the input to be always valid.
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257618#comment-17257618
]
Michael Osipov commented on LANG-1637:
--
OK, this was a misunderstanding. Sorry for that. Here is the problem: {{Y}}
denotes the ISO week year, not necessary the current year.
{{TwoDigitYearField.INSTANCE}} is passed to to {{WeekYear}} ctor. It calls the
former rule with {{calendar.getWeekYear()}}. The problem is that
{{TwoDigitYearField#appendTo(Appendable, int)}} expects a value between 0 and
99 because it uses {{##appendDigits()}} which operates on two-digit numbers
only. Everything else is undefined. Since it is an internal method it expects
the input to be always valid.
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257612#comment-17257612
]
Michael Osipov commented on LANG-1637:
--
I can confirm that there is indeed a bug. Looking into...
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-email] dependabot[bot] opened a new pull request #34: Bump maven-pmd-plugin from 3.13.0 to 3.14.0
dependabot[bot] opened a new pull request #34: URL: https://github.com/apache/commons-email/pull/34 Bumps [maven-pmd-plugin](https://github.com/apache/maven-pmd-plugin) from 3.13.0 to 3.14.0. Commits https://github.com/apache/maven-pmd-plugin/commit/56924f33687bfbc6fb051241dc51a0fc5bdf7ef6";>56924f3 [maven-release-plugin] prepare release maven-pmd-plugin-3.14.0 https://github.com/apache/maven-pmd-plugin/commit/bd5b0173532a23caa12ae3751ac87a9cf870e7df";>bd5b017 Fix integration test MPMD-165 https://github.com/apache/maven-pmd-plugin/commit/5048ab82bd92fa6526eba922d059f1a646b30cc6";>5048ab8 [MPMD-302] - Upgrade to PMD 6.29.0 https://github.com/apache/maven-pmd-plugin/commit/563654b474e031d7639429128b4d30eab5da3c02";>563654b [MPMD-307] - NPE when using custom rule https://github.com/apache/maven-pmd-plugin/commit/aff4499e154e34d050d0b099ed1b7fae85cddcef";>aff4499 [MPMD-290] - Skip integration test for maven < 3.3 https://github.com/apache/maven-pmd-plugin/commit/f39c0018e622e6c12a3a3df3a2a92bfb0ceeab44";>f39c001 [MPMD-304] - maven-pmd-plugin should be toolchains-aware https://github.com/apache/maven-pmd-plugin/commit/597d4cb712cf63a17daf67e6f0c0516fe1643e69";>597d4cb [MPMD-290] - Add integration test for CPD for C# https://github.com/apache/maven-pmd-plugin/commit/d766fdb0c93a6630ad7a788f260746b05c804a71";>d766fdb [MPMD-302] - Upgrade to PMD 6.28.0 https://github.com/apache/maven-pmd-plugin/commit/50765584772cd063e71d0922bfc8b74b82c113c5";>5076558 Fix typo in CpdReport.java https://github.com/apache/maven-pmd-plugin/commit/de2ff17c612faba5db5412fe45255e5e8f6e370c";>de2ff17 [MPMD-305] Add back support for txt format for CPD Additional commits viewable in https://github.com/apache/maven-pmd-plugin/compare/maven-pmd-plugin-3.13.0...maven-pmd-plugin-3.14.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] garydgregory merged pull request #23: Bump commons-release-plugin from 1.0 to 1.7
garydgregory merged pull request #23: URL: https://github.com/apache/commons-email/pull/23 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257609#comment-17257609
]
Michael Osipov commented on LANG-1637:
--
I am going thorugh this now.
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-email] garydgregory merged pull request #33: Bump actions/checkout from v2.3.2 to v2.3.4
garydgregory merged pull request #33: URL: https://github.com/apache/commons-email/pull/33 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] garydgregory merged pull request #30: Bump actions/setup-java from v1.4.0 to v1.4.3
garydgregory merged pull request #30: URL: https://github.com/apache/commons-email/pull/30 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] garydgregory commented on pull request #91: Minor Improvements
garydgregory commented on pull request #91: URL: https://github.com/apache/commons-configuration/pull/91#issuecomment-753539098 I would just fix checkstyle issues in your PR, not everywhere. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] arturobernalg edited a comment on pull request #91: Minor Improvements
arturobernalg edited a comment on pull request #91: URL: https://github.com/apache/commons-configuration/pull/91#issuecomment-753527406 Hi @garydgregory I agree that I should have checked if the binaries was broken. My mistake by not running `mvn clean install japicmp:cmp` I've execute `japicmp:cmp` and i notice that are several error, including the two of the UPPERCASE that you comment. What do you think we should do? we solve all the error of CheckStyle in this PR or do we create a new one? [WARNING] checkstyle:check violations detected but failOnViolation set to false [INFO] You have 82 Checkstyle violations. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] arturobernalg commented on pull request #91: Minor Improvements
arturobernalg commented on pull request #91: URL: https://github.com/apache/commons-configuration/pull/91#issuecomment-753527406 Hi @garydgregory I agree that I should have checked if the binaries was broken. My mistake by not running `mvn clean install japicmp:cmp` I've execute `japicmp:cmp` and i notice that are several error, including the two of the UPPERCASE that you comment. What do you think we should do? we solve all the error of CheckStyle in this PR or do we create a new one? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (JEXL-338) Release 3.2 to Maven Central
[
https://issues.apache.org/jira/browse/JEXL-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257477#comment-17257477
]
Garret Wilson commented on JEXL-338:
I'm still waiting to hear back on what the release process is and what the next
steps are to get a release out.
I've found this [Apache Commons – Preparations for a
Release|https://commons.apache.org/releases/prepare.html] page. Is that the
most up-to-date documentation? It seems still to refer to Subversion. Surely
you're releasing from a Git repository now (I would hope)?
And who managed the last release? It would be nice to at least touch base with
them to see what the major pain points are.
> Release 3.2 to Maven Central
>
>
> Key: JEXL-338
> URL: https://issues.apache.org/jira/browse/JEXL-338
> Project: Commons JEXL
> Issue Type: Wish
> Environment: Maven, Eclipse-GIT, Maven Central.
>Reporter: Sylke Soong
>Priority: Critical
> Labels: maven
>
> Similar to JEXL-220.
> JEXL github homepage [https://github.com/apache/commons-jexl] recommends
> {noformat}
>
> org.apache.commons
> commons-jexl3
> 3.2
> {noformat}
> But Maven central does not have it.. EGIT croaks artefact jar not foundr,
> when jexl 3.2 dependency is in the pom.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-340) JexlException message access is incomplete and reversed
[
https://issues.apache.org/jira/browse/JEXL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257476#comment-17257476
]
Garret Wilson commented on JEXL-340:
Thanks for responding, [~ggregory]. I would be happy to provide a pull request,
but I'm hesitant to do any work if it is still unclear whether and when there
will even be any new releases, as we've been discussing in JEXL-338. I have
said in that ticket that I would be interested in serving as Release Manager,
but I still have some questions in JEXL-338 that are unanswered, and no one has
told me what the next steps would be.
> JexlException message access is incomplete and reversed
> ---
>
> Key: JEXL-340
> URL: https://issues.apache.org/jira/browse/JEXL-340
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Garret Wilson
>Priority: Trivial
>
> I need to wrap {{JexlException}} and provide a nice error message to the
> user. If I have an expression using a variable {{foobar}} not present in the
> context, here is what {{JexlException.getMessage()}} returns:
> {quote}io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined variable
> foobar{quote}
> This is not a pretty error message. It has lots of things a user doesn't care
> about. I just want the real error message:
> {quote}undefined variable foobar{quote}
> But there is no way to get just that simple error message from
> {{JexlException}}. If you look at the source code for
> {{JexlException.getMessage()}}, you'll see that the "simple" message comes
> from {{JexlException.detailedMessage()}}.
> Unfortunately {{JexlException.detailedMessage()}} is {{protected}}—there is
> no way to access it from outside. Moreover the semantics of "message" and
> "detailed message" are reversed! The "message" should provide fewer details
> than the "detailed message".
> Here is what should be done:
> * {{JexlException.getMessage()}} should provide what {{detailedMessage()}}
> provides now. (You'll note that {{detailedMessage()}} already calls
> {{super.getMessage()}}; this criss-cross overriding is not the best practice.
> My suggestion would therefore improve and even reduce the code.)
> * A new {{JexlException.getDetailedMessage()}} should provide what
> {{getMessage()}} provides now.
> That would be simpler and more correct. And it would give me the simpler
> error message I need. If you absolutely must leave
> {{JexlException.getMessage()}} the way it is for backwards compatibility, at
> least provide a {{getSimpleMessage()}} that returns what
> {{detailedMessage()}} returns now. (That way you can leave
> {{detailedMessage()}} hidden, because it returns the _opposite_ of a detailed
> message.)
> I would guess that this issue of {{detailedMessage()}} returning the opposite
> of a "detailed message" arose out of confusion of the API docs of
> {{Throwable}} and {{Exception}} referring to a "detail message". But "detail
> message" and "detailed message" mean different things. The API docs of
> {{Throwable}} et. al. are referring to the message providing a detail about
> the {{Throwable}}. The message itself is the "detail". But when you change
> "detail message" to "detailed message", the "detailed" now means that the
> message provides additional details than a normal message. So by adding the
> "ed" to "detail" it changed the sense of what "detail message" originally
> meant (the message providing detail).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-340) JexlException message access is incomplete and reversed
[
https://issues.apache.org/jira/browse/JEXL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257474#comment-17257474
]
Gary D. Gregory commented on JEXL-340:
--
[~garretwilson]
Thank you for your report.
Feel free to provide a PR on GitHub (with tests).
> JexlException message access is incomplete and reversed
> ---
>
> Key: JEXL-340
> URL: https://issues.apache.org/jira/browse/JEXL-340
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Garret Wilson
>Priority: Trivial
>
> I need to wrap {{JexlException}} and provide a nice error message to the
> user. If I have an expression using a variable {{foobar}} not present in the
> context, here is what {{JexlException.getMessage()}} returns:
> {quote}io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined variable
> foobar{quote}
> This is not a pretty error message. It has lots of things a user doesn't care
> about. I just want the real error message:
> {quote}undefined variable foobar{quote}
> But there is no way to get just that simple error message from
> {{JexlException}}. If you look at the source code for
> {{JexlException.getMessage()}}, you'll see that the "simple" message comes
> from {{JexlException.detailedMessage()}}.
> Unfortunately {{JexlException.detailedMessage()}} is {{protected}}—there is
> no way to access it from outside. Moreover the semantics of "message" and
> "detailed message" are reversed! The "message" should provide fewer details
> than the "detailed message".
> Here is what should be done:
> * {{JexlException.getMessage()}} should provide what {{detailedMessage()}}
> provides now. (You'll note that {{detailedMessage()}} already calls
> {{super.getMessage()}}; this criss-cross overriding is not the best practice.
> My suggestion would therefore improve and even reduce the code.)
> * A new {{JexlException.getDetailedMessage()}} should provide what
> {{getMessage()}} provides now.
> That would be simpler and more correct. And it would give me the simpler
> error message I need. If you absolutely must leave
> {{JexlException.getMessage()}} the way it is for backwards compatibility, at
> least provide a {{getSimpleMessage()}} that returns what
> {{detailedMessage()}} returns now. (That way you can leave
> {{detailedMessage()}} hidden, because it returns the _opposite_ of a detailed
> message.)
> I would guess that this issue of {{detailedMessage()}} returning the opposite
> of a "detailed message" arose out of confusion of the API docs of
> {{Throwable}} and {{Exception}} referring to a "detail message". But "detail
> message" and "detailed message" mean different things. The API docs of
> {{Throwable}} et. al. are referring to the message providing a detail about
> the {{Throwable}}. The message itself is the "detail". But when you change
> "detail message" to "detailed message", the "detailed" now means that the
> message provides additional details than a normal message. So by adding the
> "ed" to "detail" it changed the sense of what "detail message" originally
> meant (the message providing detail).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JEXL-340) JexlException message access is incomplete and reversed
[
https://issues.apache.org/jira/browse/JEXL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated JEXL-340:
---
Description:
I need to wrap {{JexlException}} and provide a nice error message to the user.
If I have an expression using a variable {{foobar}} not present in the context,
here is what {{JexlException.getMessage()}} returns:
{quote}io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined variable
foobar{quote}
This is not a pretty error message. It has lots of things a user doesn't care
about. I just want the real error message:
{quote}undefined variable foobar{quote}
But there is no way to get just that simple error message from
{{JexlException}}. If you look at the source code for
{{JexlException.getMessage()}}, you'll see that the "simple" message comes from
{{JexlException.detailedMessage()}}.
Unfortunately {{JexlException.detailedMessage()}} is {{protected}}—there is no
way to access it from outside. Moreover the semantics of "message" and
"detailed message" are reversed! The "message" should provide fewer details
than the "detailed message".
Here is what should be done:
* {{JexlException.getMessage()}} should provide what {{detailedMessage()}}
provides now. (You'll note that {{detailedMessage()}} already calls
{{super.getMessage()}}; this criss-cross overriding is not the best practice.
My suggestion would therefore improve and even reduce the code.)
* A new {{JexlException.getDetailedMessage()}} should provide what
{{getMessage()}} provides now.
That would be simpler and more correct. And it would give me the simpler error
message I need. If you absolutely must leave {{JexlException.getMessage()}} the
way it is for backwards compatibility, at least provide a
{{getSimpleMessage()}} that returns what {{detailedMessage()}} returns now.
(That way you can leave {{detailedMessage()}} hidden, because it returns the
_opposite_ of a detailed message.)
I would guess that this issue of {{detailedMessage()}} returning the opposite
of a "detailed message" arose out of confusion of the API docs of {{Throwable}}
and {{Exception}} referring to a "detail message". But "detail message" and
"detailed message" mean different things. The API docs of {{Throwable}} et. al.
are referring to the message providing a detail about the {{Throwable}}. The
message itself is the "detail". But when you change "detail message" to
"detailed message", the "detailed" now means that the message provides
additional details than a normal message. So by adding the "ed" to "detail" it
changed the sense of what "detail message" originally meant (the message
providing detail).
was:
I need to wrap {{JexlException}} and provide a nice error message to the user.
If I have an expression using a variable {{foobar}} not present in the context,
here is what {{JexlException.getMessage()}} returns:
{quote}io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined variable
foobar{quote}
This is not a pretty error message. It has lots of things a user doesn't care
about. I just want the real error message:
{quote}undefined variable foobar{quote}
But there is no way to get just that simple error message from
{{JexlException}}. If you look at the source code for
{{JexlException.getMessage()}}, you'll see that the "simple" message comes from
{{JexlException.detailedMessage()}}.
Unfortunately {{JexlException.detailedMessage()}} is {{protected}}—there is no
way to access it from outside. Moreover the semantics of "message" and
"detailed message" are reversed! The "message" should provide fewer details
than the "detailed message".
Here is what should be done:
* {{JexlException.getMessage()}} should provide what {{detailedMessage()}}
provides now. (You'll note that {{detailedMessage()}} already calls
{{super.getMessage()}}; this criss-cross overriding is not the best practice.
My suggestion would therefore improve and even reduce the code.)
* A new {{JexlException.getDetailedMessage()}} should provide what
{{getMessage()}} provides now.
That would be simpler and more correct. And it would give me the simpler error
message I need.
It's not apparent to me why the current roundabout implementation was used to
begin with, or what benefit it brings.
> JexlException message access is incomplete and reversed
> ---
>
> Key: JEXL-340
> URL: https://issues.apache.org/jira/browse/JEXL-340
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Garret Wilson
>Priority: Trivial
>
> I need to wrap {{JexlException}} and provide a nice error message to the
> user. If I have an expression using a variable {{foobar}} not present in the
> context, here is what {{JexlException.getMessage()}} returns:
> {quote}io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined vari
[jira] [Updated] (JEXL-340) JexlException message access is incomplete and reversed
[
https://issues.apache.org/jira/browse/JEXL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated JEXL-340:
---
Priority: Trivial (was: Minor)
> JexlException message access is incomplete and reversed
> ---
>
> Key: JEXL-340
> URL: https://issues.apache.org/jira/browse/JEXL-340
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Garret Wilson
>Priority: Trivial
>
> I need to wrap {{JexlException}} and provide a nice error message to the
> user. If I have an expression using a variable {{foobar}} not present in the
> context, here is what {{JexlException.getMessage()}} returns:
> {quote}io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined variable
> foobar{quote}
> This is not a pretty error message. It has lots of things a user doesn't care
> about. I just want the real error message:
> {quote}undefined variable foobar{quote}
> But there is no way to get just that simple error message from
> {{JexlException}}. If you look at the source code for
> {{JexlException.getMessage()}}, you'll see that the "simple" message comes
> from {{JexlException.detailedMessage()}}.
> Unfortunately {{JexlException.detailedMessage()}} is {{protected}}—there is
> no way to access it from outside. Moreover the semantics of "message" and
> "detailed message" are reversed! The "message" should provide fewer details
> than the "detailed message".
> Here is what should be done:
> * {{JexlException.getMessage()}} should provide what {{detailedMessage()}}
> provides now. (You'll note that {{detailedMessage()}} already calls
> {{super.getMessage()}}; this criss-cross overriding is not the best practice.
> My suggestion would therefore improve and even reduce the code.)
> * A new {{JexlException.getDetailedMessage()}} should provide what
> {{getMessage()}} provides now.
> That would be simpler and more correct. And it would give me the simpler
> error message I need.
> It's not apparent to me why the current roundabout implementation was used to
> begin with, or what benefit it brings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JEXL-340) JexlException message access is incomplete and reversed
[
https://issues.apache.org/jira/browse/JEXL-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated JEXL-340:
---
Priority: Minor (was: Major)
> JexlException message access is incomplete and reversed
> ---
>
> Key: JEXL-340
> URL: https://issues.apache.org/jira/browse/JEXL-340
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Garret Wilson
>Priority: Minor
>
> I need to wrap {{JexlException}} and provide a nice error message to the
> user. If I have an expression using a variable {{foobar}} not present in the
> context, here is what {{JexlException.getMessage()}} returns:
> {quote}io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined variable
> foobar{quote}
> This is not a pretty error message. It has lots of things a user doesn't care
> about. I just want the real error message:
> {quote}undefined variable foobar{quote}
> But there is no way to get just that simple error message from
> {{JexlException}}. If you look at the source code for
> {{JexlException.getMessage()}}, you'll see that the "simple" message comes
> from {{JexlException.detailedMessage()}}.
> Unfortunately {{JexlException.detailedMessage()}} is {{protected}}—there is
> no way to access it from outside. Moreover the semantics of "message" and
> "detailed message" are reversed! The "message" should provide fewer details
> than the "detailed message".
> Here is what should be done:
> * {{JexlException.getMessage()}} should provide what {{detailedMessage()}}
> provides now. (You'll note that {{detailedMessage()}} already calls
> {{super.getMessage()}}; this criss-cross overriding is not the best practice.
> My suggestion would therefore improve and even reduce the code.)
> * A new {{JexlException.getDetailedMessage()}} should provide what
> {{getMessage()}} provides now.
> That would be simpler and more correct. And it would give me the simpler
> error message I need.
> It's not apparent to me why the current roundabout implementation was used to
> begin with, or what benefit it brings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JEXL-340) JexlException message access is incomplete and reversed
Garret Wilson created JEXL-340:
--
Summary: JexlException message access is incomplete and reversed
Key: JEXL-340
URL: https://issues.apache.org/jira/browse/JEXL-340
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Garret Wilson
I need to wrap {{JexlException}} and provide a nice error message to the user.
If I have an expression using a variable {{foobar}} not present in the context,
here is what {{JexlException.getMessage()}} returns:
{quote}io.guise.mesh.JexlMexlEvaluator.evaluate@1:1 undefined variable
foobar{quote}
This is not a pretty error message. It has lots of things a user doesn't care
about. I just want the real error message:
{quote}undefined variable foobar{quote}
But there is no way to get just that simple error message from
{{JexlException}}. If you look at the source code for
{{JexlException.getMessage()}}, you'll see that the "simple" message comes from
{{JexlException.detailedMessage()}}.
Unfortunately {{JexlException.detailedMessage()}} is {{protected}}—there is no
way to access it from outside. Moreover the semantics of "message" and
"detailed message" are reversed! The "message" should provide fewer details
than the "detailed message".
Here is what should be done:
* {{JexlException.getMessage()}} should provide what {{detailedMessage()}}
provides now. (You'll note that {{detailedMessage()}} already calls
{{super.getMessage()}}; this criss-cross overriding is not the best practice.
My suggestion would therefore improve and even reduce the code.)
* A new {{JexlException.getDetailedMessage()}} should provide what
{{getMessage()}} provides now.
That would be simpler and more correct. And it would give me the simpler error
message I need.
It's not apparent to me why the current roundabout implementation was used to
begin with, or what benefit it brings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530219&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530219
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 16:41
Start Date: 02/Jan/21 16:41
Worklog Time Spent: 10m
Work Description: michael-o commented on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753496059
Will have a look.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530219)
Time Spent: 3h 10m (was: 3h)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] michael-o commented on pull request #688: [LANG-1637] Fix 2 digit week year formatting
michael-o commented on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753496059 Will have a look. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] coveralls edited a comment on pull request #154: Bump maven-pmd-plugin from 3.13.0 to 3.14.0
coveralls edited a comment on pull request #154: URL: https://github.com/apache/commons-compress/pull/154#issuecomment-732678869 [](https://coveralls.io/builds/36040319) Coverage remained the same at 87.274% when pulling **26284777bf395b350ae794f6592dcc7e50345877 on dependabot/maven/org.apache.maven.plugins-maven-pmd-plugin-3.14.0** into **4944b13a898c407912a99e5d71011243f94a9244 on master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530218&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530218
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 16:24
Start Date: 02/Jan/21 16:24
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474295
[](https://coveralls.io/builds/36040275)
Coverage decreased (-0.01%) to 95.001% when pulling
**b1ad8ae3ea910e37cfc69b18d70158861942739d on
ugonen:LANG-1637-fix-week-year-two-digits** into
**f5c86f6d4e8d9023f9e023fb1cd09ef47c8fd1cf on apache:master**.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530218)
Time Spent: 3h (was: 2h 50m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 3h
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #688: [LANG-1637] Fix 2 digit week year formatting
coveralls edited a comment on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474295 [](https://coveralls.io/builds/36040275) Coverage decreased (-0.01%) to 95.001% when pulling **b1ad8ae3ea910e37cfc69b18d70158861942739d on ugonen:LANG-1637-fix-week-year-two-digits** into **f5c86f6d4e8d9023f9e023fb1cd09ef47c8fd1cf on apache:master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530216&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530216
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 16:22
Start Date: 02/Jan/21 16:22
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474295
[](https://coveralls.io/builds/36040263)
Coverage increased (+0.0009%) to 95.013% when pulling
**b1ad8ae3ea910e37cfc69b18d70158861942739d on
ugonen:LANG-1637-fix-week-year-two-digits** into
**f5c86f6d4e8d9023f9e023fb1cd09ef47c8fd1cf on apache:master**.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530216)
Time Spent: 2h 50m (was: 2h 40m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #688: [LANG-1637] Fix 2 digit week year formatting
coveralls edited a comment on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474295 [](https://coveralls.io/builds/36040263) Coverage increased (+0.0009%) to 95.013% when pulling **b1ad8ae3ea910e37cfc69b18d70158861942739d on ugonen:LANG-1637-fix-week-year-two-digits** into **f5c86f6d4e8d9023f9e023fb1cd09ef47c8fd1cf on apache:master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530215&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530215
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 16:18
Start Date: 02/Jan/21 16:18
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474295
[](https://coveralls.io/builds/36040229)
Coverage increased (+0.0009%) to 95.013% when pulling
**fd4bb4ab89678ce29fd18d8fc20bcfb57f146a8f on
ugonen:LANG-1637-fix-week-year-two-digits** into
**f5c86f6d4e8d9023f9e023fb1cd09ef47c8fd1cf on apache:master**.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530215)
Time Spent: 2h 40m (was: 2.5h)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #688: [LANG-1637] Fix 2 digit week year formatting
coveralls edited a comment on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474295 [](https://coveralls.io/builds/36040229) Coverage increased (+0.0009%) to 95.013% when pulling **fd4bb4ab89678ce29fd18d8fc20bcfb57f146a8f on ugonen:LANG-1637-fix-week-year-two-digits** into **f5c86f6d4e8d9023f9e023fb1cd09ef47c8fd1cf on apache:master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530214&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530214
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 16:16
Start Date: 02/Jan/21 16:16
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753492355
@michael-o The PR seems OK to me now. 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530214)
Time Spent: 2.5h (was: 2h 20m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530213&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530213
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 16:16
Start Date: 02/Jan/21 16:16
Worklog Time Spent: 10m
Work Description: ugonen commented on a change in pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#discussion_r550896126
##
File path: src/test/java/org/apache/commons/lang3/time/FastDatePrinterTest.java
##
@@ -432,4 +432,15 @@ public void testDayNumberOfWeek() {
calendar.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
assertEquals("7", printer.format(calendar.getTime()));
}
+
+@DefaultLocale(language = "en", country = "US")
+@DefaultTimeZone("America/New_York")
+@Test
+public void testWeekYear() {
+final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0,
0, 0);
+final DatePrinter printer4Digits = getInstance("");
+final DatePrinter printer2Digits = getInstance("YY");
Review comment:
added, thanks
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530213)
Time Spent: 2h 20m (was: 2h 10m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on pull request #688: LANG-1637: fix 2 digit week year formatting
garydgregory commented on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753492355 @michael-o The PR seems OK to me now. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] ugonen commented on a change in pull request #688: LANG-1637: fix 2 digit week year formatting
ugonen commented on a change in pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#discussion_r550896126
##
File path: src/test/java/org/apache/commons/lang3/time/FastDatePrinterTest.java
##
@@ -432,4 +432,15 @@ public void testDayNumberOfWeek() {
calendar.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
assertEquals("7", printer.format(calendar.getTime()));
}
+
+@DefaultLocale(language = "en", country = "US")
+@DefaultTimeZone("America/New_York")
+@Test
+public void testWeekYear() {
+final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0,
0, 0);
+final DatePrinter printer4Digits = getInstance("");
+final DatePrinter printer2Digits = getInstance("YY");
Review comment:
added, thanks
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Closed] (NET-696) Issue with ParserInitializationException: Unknown Parser Type: NOOP ok
[
https://issues.apache.org/jira/browse/NET-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb closed NET-696.
> Issue with ParserInitializationException: Unknown Parser Type: NOOP ok
> --
>
> Key: NET-696
> URL: https://issues.apache.org/jira/browse/NET-696
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.7
>Reporter: Edward Lynch-Milner
>Priority: Major
>
> When a thread sends a no-op to the FTPClient, and then the main UI thread I
> have running lists the files for a specified directory I get an exception
> trace similar to the one found in issue NET-476 similar to this:
> {noformat}
> Caused by: org.apache.commons.net.ftp.parser.ParserInitializationException:
> Unknown parser type: PORT command successful. Consider using PASV.
> at
> org.apache.commons.net.ftp.parser.DefaultFTPFileEntryParserFactory.createFileEntryParser(DefaultFTPFileEntryParserFactory.java:118)
> at
> org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2359)
> at
> org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2142){noformat}
> But in my case after the no-op is sent, the Unknown parser type is: NOOP ok
> or something along the lines of that.
> I have been struggling to reproduce it as it happens occasionally and I can't
> find a pattern to it. Could it be because of a race condition, when the
> thread sends a no-op at the exact same time the main thread sends a listFiles
> command? (They use the same ftpClient objects, the main UI thread and the
> thread sending no-ops). I wish I could find a workaround to this issue but
> not sure where to start with it.
> It also happens with getModificationTime. Here is an exception from trying to
> parse the modification time returned by ftpClient.getModificationTime:
> {noformat}
> Exception in thread "JavaFX Application Thread"
> java.time.format.DateTimeParseException: Text 'NOOP ok.' could not be parsed
> at index 0
> at
> java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2046)
> at
> java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1948)
> at
> java.base/java.time.LocalDateTime.parse(LocalDateTime.java:492){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (NET-686) Most files aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-686. -- Resolution: Won't Fix > Most files aren't downloaded completely from an FTP server > -- > > Key: NET-686 > URL: https://issues.apache.org/jira/browse/NET-686 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6, 3.7.2 > Environment: Win 10 > Java 8 > Android Studio 3.6.1 (min SDK 24, target SDK 27) >Reporter: JRRR >Priority: Major > Attachments: 2a-original.png, 2b-corrupt.png, 2c-corrupt.png, > 5a-original.jpg, 5b-corrupt.jpg, 5c-corrupt.jpg, DownloadProblem.java > > > About a month ago I opened another > [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because > it wasn't reproducible with macOS and a public FTP server. > Short summary: Downloading files from an FTP server results in these files > randomly missing bytes. It looks like the download always "completes" and > there are no error messages/exceptions but random bytes in random files are > simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe > 40, bytes smaller than the original), and are then also visibly corrupt, than > text files (usually only 2-3 bytes smaller, rarely more). > I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK > 24, target SDK 27), which I'm testing with FTP servers in the same network > (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what > method in the library I use (retrieveFile, retrieveFileStream, > sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a > single file that's corrupted. > I also tested the same code with public servers and even though I didn't have > a lot of time because those servers regularely delete uploaded files, I never > experienced said problem with them. > I even wrote my own mini-library (just for login/logout and download) using > Java's default "Socket" but I still had the same problem on Android Studio's > simulator/a real device. BUT: When I used the same code to create a small > Windows/Swing/Java app, there were no more corrupted files. > It looks like this bug is only affecting a very specific combination of > OS,...: > Android (emulator/real device) + Java (8) + FTP server in the same network > (accessed via IP) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (NET-665) Support for multiple FTPFileFilters
[
https://issues.apache.org/jira/browse/NET-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-665.
--
Resolution: Won't Do
Adds unnecessary code which has to be tested, documented and maintained
> Support for multiple FTPFileFilters
> ---
>
> Key: NET-665
> URL: https://issues.apache.org/jira/browse/NET-665
> Project: Commons Net
> Issue Type: New Feature
>Affects Versions: 3.6
>Reporter: David Tarr
>Priority: Major
>
> FTPClient now has a method
> [*listFiles*|https://commons.apache.org/proper/commons-net/apidocs/org/apache/commons/net/ftp/FTPClient.html#listFiles(java.lang.String,%20org.apache.commons.net.ftp.FTPFileFilter)]
> that allows a filter to filter out irrelevant files.
> I'd like to be able to pass multiple filters.
> This way I don't need to combine multiple FileFilters into one (cleaner code)
> Current:
> {{public FTPFile[] listFiles(String pathname, FTPFileFilter filter) throws
> IOException}}
> New:
> {{public FTPFile[] listFiles(String pathname, FTPFileFilter... filter) throws
> IOException}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (VALIDATOR-478) In the latest version 1.7 the UrlValidator is giving the result as Invalid for some of the Urls which were valid in version 1.6
[ https://issues.apache.org/jira/browse/VALIDATOR-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved VALIDATOR-478. Fix Version/s: (was: 1.7) Resolution: Not A Problem The code now uses java.net.URI to parse the string, see VALIDATOR-472, and the URL is not valid as far as Java is concerned (looks like a fragment is not allowed to contain a #). You will need to escape the invalid characters. > In the latest version 1.7 the UrlValidator is giving the result as Invalid > for some of the Urls which were valid in version 1.6 > --- > > Key: VALIDATOR-478 > URL: https://issues.apache.org/jira/browse/VALIDATOR-478 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.7 >Reporter: Sunil kumar S >Priority: Major > Labels: features > > The following URL which I have specified is coming as InValid URL according > to Commons-validator latest version 1.7 > [https://checkoutshopper-live.adyen.com/checkoutshopper/3dnotif.shtml?originKey=pub.v2.###MAASKED#0012.aHR0cHM6Ly9jaGVja291dHNob3BwZXItbGl2ZS5hZHllbi5jb20.FRf3zC99VPpJ8Eg1gNYaiR_PxMLPZfWnHWc6uYhbyNw] > where this URL was valid when I validated with version 1.6 > Please help me out why this has happened? if the above URL specified is > really invalid please specify the reason. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-dbutils] coveralls edited a comment on pull request #51: Bump checkstyle from 8.37 to 8.39
coveralls edited a comment on pull request #51: URL: https://github.com/apache/commons-dbutils/pull/51#issuecomment-753267337 [](https://coveralls.io/builds/36039843) Coverage remained the same at 64.939% when pulling **04111790ff4eadad80742518418ef43a5f35bff0 on dependabot/maven/com.puppycrawl.tools-checkstyle-8.39** into **e906f6535e796dbc5311052b56ce18f5c784fa8f on master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] garydgregory commented on a change in pull request #91: Minor Improvements
garydgregory commented on a change in pull request #91:
URL:
https://github.com/apache/commons-configuration/pull/91#discussion_r550888036
##
File path:
src/main/java/org/apache/commons/configuration2/web/AppletConfiguration.java
##
@@ -31,7 +31,7 @@
public class AppletConfiguration extends BaseWebConfiguration
{
/** Stores the wrapped applet.*/
-protected Applet applet;
+protected final Applet applet;
Review comment:
**Please do NOT break binary compatibility.**
##
File path:
src/main/java/org/apache/commons/configuration2/web/ServletRequestConfiguration.java
##
@@ -34,7 +34,7 @@
public class ServletRequestConfiguration extends BaseWebConfiguration
{
/** Stores the wrapped request.*/
-protected ServletRequest request;
+protected final ServletRequest request;
Review comment:
**Please do NOT break binary compatibility.**
##
File path:
src/main/java/org/apache/commons/configuration2/spring/ConfigurationPropertiesFactoryBean.java
##
@@ -56,7 +56,7 @@
/** Spring resources for loading configurations **/
private Resource[] locations;
-/** @see
org.apache.commons.configuration2.AbstractConfiguration#throwExceptionOnMissing
**/
+/** @link
org.apache.commons.configuration2.AbstractConfiguration#throwExceptionOnMissing
**/
Review comment:
-1 breaks Javadoc, leave as is please.
##
File path:
src/main/java/org/apache/commons/configuration2/web/ServletContextConfiguration.java
##
@@ -34,7 +34,7 @@
public class ServletContextConfiguration extends BaseWebConfiguration
{
/** Stores the wrapped servlet context.*/
-protected ServletContext context;
+protected final ServletContext context;
Review comment:
**Please do NOT break binary compatibility.**
##
File path:
src/main/java/org/apache/commons/configuration2/web/ServletConfiguration.java
##
@@ -34,7 +34,7 @@
public class ServletConfiguration extends BaseWebConfiguration
{
/** Stores a reference to the wrapped {@code ServletConfig}.*/
-protected ServletConfig config;
+protected final ServletConfig config;
Review comment:
**Please do NOT break binary compatibility.**
##
File path:
src/test/java/org/apache/commons/configuration2/TestPropertiesConfiguration.java
##
@@ -246,13 +246,13 @@ public PropertiesWriterTestImpl(final
ListDelimiterHandler handler) throws IOExc
private static final String CR = System.getProperty("line.separator");
/** The File that we test with */
-private static String testProperties =
ConfigurationAssert.getTestFile("test.properties").getAbsolutePath();
+private static final String testProperties =
ConfigurationAssert.getTestFile("test.properties").getAbsolutePath();
Review comment:
static finals are in UPPER CASE by convention.
##
File path:
src/main/java/org/apache/commons/configuration2/tree/ModelTransaction.java
##
@@ -361,12 +361,7 @@ Operations fetchOperations(final ImmutableNode target,
final int level)
Integer.valueOf(level == LEVEL_UNKNOWN ? level(target)
: level);
Map levelOperations =
-operations.get(nodeLevel);
-if (levelOperations == null)
-{
-levelOperations = new HashMap<>();
-operations.put(nodeLevel, levelOperations);
-}
+operations.computeIfAbsent(nodeLevel, k -> new HashMap<>());
Review comment:
Fix formatting.
##
File path:
src/main/java/org/apache/commons/configuration2/web/ServletFilterConfiguration.java
##
@@ -33,7 +33,7 @@
public class ServletFilterConfiguration extends BaseWebConfiguration
{
/** Stores the wrapped filter config.*/
-protected FilterConfig config;
+protected final FilterConfig config;
Review comment:
**Please do NOT break binary compatibility.**
##
File path: src/main/java/org/apache/commons/configuration2/io/FileUtils.java
##
@@ -33,7 +34,7 @@
/**
* The UTF-8 character set, used to decode octets in URLs.
*/
-private static final Charset UTF8 = Charset.forName("UTF-8");
+private static final Charset UTF8 = StandardCharsets.UTF_8;
Review comment:
You can now inline this private var.
##
File path:
src/test/java/org/apache/commons/configuration2/TestPropertiesConfiguration.java
##
@@ -246,13 +246,13 @@ public PropertiesWriterTestImpl(final
ListDelimiterHandler handler) throws IOExc
private static final String CR = System.getProperty("line.separator");
/** The File that we test with */
-private static String testProperties =
ConfigurationAssert.getTestFile("test.properties").getAbsolutePath();
+private static final String testProperties =
ConfigurationAssert.getTestFile("test.properties").getAbsolutePath();
-private static String testBasePath =
Co
[GitHub] [commons-configuration] garydgregory merged pull request #88: Bump jackson-databind from 2.11.3 to 2.12.0
garydgregory merged pull request #88: URL: https://github.com/apache/commons-configuration/pull/88 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] dependabot[bot] closed pull request #87: Bump spring.version from 4.3.27.RELEASE to 5.3.1
dependabot[bot] closed pull request #87: URL: https://github.com/apache/commons-configuration/pull/87 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] dependabot[bot] commented on pull request #87: Bump spring.version from 4.3.27.RELEASE to 5.3.1
dependabot[bot] commented on pull request #87: URL: https://github.com/apache/commons-configuration/pull/87#issuecomment-753480443 Superseded by #92. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] dependabot[bot] opened a new pull request #92: Bump spring.version from 4.3.27.RELEASE to 5.3.2
dependabot[bot] opened a new pull request #92: URL: https://github.com/apache/commons-configuration/pull/92 Bumps `spring.version` from 4.3.27.RELEASE to 5.3.2. Updates `spring-core` from 4.3.27.RELEASE to 5.3.2 Release notes Sourced from https://github.com/spring-projects/spring-framework/releases";>spring-core's releases. v5.3.2 :star: New Features Refine ConfigurationClassPostProcessor behavior in native images https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26236";>#26236 Ability to correlate ByteBuf leak records to log messages for a specific request https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26230";>#26230 Avoid CGLIB proxies in websocket/messaging configuration https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26227";>#26227 ContentCachingResponseWrapper should not add “Content-Length” when “Transfer-Encoding” is present https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26182";>#26182 Allow customization of file extension to media type map for WebFlux static resources https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26170";>#26170 Register bean definition dependencies when used via configuration class injected fields https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26167";>#26167 Print helpful information in RSocket MetadataExtractor https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26130";>#26130 Add ResponseSpec#toEntityFlux overload that accepts BodyExtractor https://github-redirect.dependabot.com/spring-projects/spring-framework/pull/26114";>#26114 Wildcard is a valid Access-Control-Expose-Headers value https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26113";>#26113 Reduce overhead of char[] creation https://github-redirect.dependabot.com/spring-projects/spring-framework/pull/26101";>#26101 EntityManagerFactory startup failure in deferred mode is only available on first use https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26093";>#26093 @DynamicPropertySource is not supported via @NestedTestConfiguration semantics https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26091";>#26091 Introduce and() methods in MethodFilter and FieldFilter for composite filters https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26063";>#26063 Kotlin extensions for WebClient.ResponseSpec https://github-redirect.dependabot.com/spring-projects/spring-framework/pull/26030";>#26030 Validate that JUnit Jupiter test methods and lifecycle methods are not annotated with @Autowired https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/25966";>#25966 Add support for SSE to WebMvc.fn https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/25920";>#25920 Template URI Variables with newline %0A or %0D are not matched https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/23252";>#23252 :beetle: Bug Fixes AsyncServerResponse interoperability issue with path variables https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26239";>#26239 Remove duplicate "property" in PropertyCacheKey.toString() https://github-redirect.dependabot.com/spring-projects/spring-framework/pull/26237";>#26237 DataBuffer Leak in Server Response https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26232";>#26232 Wrong HttpServletMapping used on INCLUDE in UrlPathHelper.skipServletPathDetermination https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26216";>#26216 MockMvc ignores MultipartFile registrations when both files and parts are registered https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26166";>#26166 cannot resolve ServerRequest::pathVariable in nested RequestPredicate https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26163";>#26163 ConcurrentModificationException in NativeMessageHeaderAccessor#copyHeaders https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26155";>#26155 AbstractServerHttpRequest constructor breaks binary compatibility between 5.2.x and 5.3.x https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26151";>#26151 Refine kotlinx.serialization support https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26147";>#26147 MimeType is no longer actually serializable https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26127";>#26127 Resttemplate throws NPE with spring-boot-starter-log4j2 within tests https://github-redirect.dependabot.com/spring-projects/spring-framework/i
[GitHub] [commons-configuration] garydgregory merged pull request #90: Bump checkstyle from 8.36.2 to 8.39
garydgregory merged pull request #90: URL: https://github.com/apache/commons-configuration/pull/90 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] garydgregory merged pull request #85: Bump actions/checkout from v2.3.3 to v2.3.4
garydgregory merged pull request #85: URL: https://github.com/apache/commons-configuration/pull/85 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530207&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530207
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 13:35
Start Date: 02/Jan/21 13:35
Worklog Time Spent: 10m
Work Description: garydgregory edited a comment on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474335
- https://docs.oracle.com/javase/8/docs/api/java/text/SimpleDateFormat.html
-
https://docs.oracle.com/javase/8/docs/api/java/util/GregorianCalendar.html#week_year
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530207)
Time Spent: 2h 10m (was: 2h)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory edited a comment on pull request #688: LANG-1637: fix 2 digit week year formatting
garydgregory edited a comment on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474335 - https://docs.oracle.com/javase/8/docs/api/java/text/SimpleDateFormat.html - https://docs.oracle.com/javase/8/docs/api/java/util/GregorianCalendar.html#week_year 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530206&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530206
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 13:33
Start Date: 02/Jan/21 13:33
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474335
https://docs.oracle.com/javase/8/docs/api/java/text/SimpleDateFormat.html
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530206)
Time Spent: 2h (was: 1h 50m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 2h
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530205&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530205
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 13:33
Start Date: 02/Jan/21 13:33
Worklog Time Spent: 10m
Work Description: coveralls commented on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474295
[](https://coveralls.io/builds/36039362)
Coverage increased (+0.0009%) to 95.013% when pulling
**bc0354f22e1d42a2a08016fd2d577f1e65d9d35c on
ugonen:LANG-1637-fix-week-year-two-digits** into
**f5c86f6d4e8d9023f9e023fb1cd09ef47c8fd1cf on apache:master**.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530205)
Time Spent: 1h 50m (was: 1h 40m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on pull request #688: LANG-1637: fix 2 digit week year formatting
garydgregory commented on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474335 https://docs.oracle.com/javase/8/docs/api/java/text/SimpleDateFormat.html 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] coveralls commented on pull request #688: LANG-1637: fix 2 digit week year formatting
coveralls commented on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753474295 [](https://coveralls.io/builds/36039362) Coverage increased (+0.0009%) to 95.013% when pulling **bc0354f22e1d42a2a08016fd2d577f1e65d9d35c on ugonen:LANG-1637-fix-week-year-two-digits** into **f5c86f6d4e8d9023f9e023fb1cd09ef47c8fd1cf on apache:master**. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530203&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530203
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 13:30
Start Date: 02/Jan/21 13:30
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#discussion_r550882167
##
File path: src/test/java/org/apache/commons/lang3/time/FastDatePrinterTest.java
##
@@ -432,4 +432,15 @@ public void testDayNumberOfWeek() {
calendar.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
assertEquals("7", printer.format(calendar.getTime()));
}
+
+@DefaultLocale(language = "en", country = "US")
+@DefaultTimeZone("America/New_York")
+@Test
+public void testWeekYear() {
+final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0,
0, 0);
+final DatePrinter printer4Digits = getInstance("");
+final DatePrinter printer2Digits = getInstance("YY");
Review comment:
Please add code in your new test for Y and YYY.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530203)
Time Spent: 1h 40m (was: 1.5h)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on a change in pull request #688: LANG-1637: fix 2 digit week year formatting
garydgregory commented on a change in pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#discussion_r550882167
##
File path: src/test/java/org/apache/commons/lang3/time/FastDatePrinterTest.java
##
@@ -432,4 +432,15 @@ public void testDayNumberOfWeek() {
calendar.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
assertEquals("7", printer.format(calendar.getTime()));
}
+
+@DefaultLocale(language = "en", country = "US")
+@DefaultTimeZone("America/New_York")
+@Test
+public void testWeekYear() {
+final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0,
0, 0);
+final DatePrinter printer4Digits = getInstance("");
+final DatePrinter printer2Digits = getInstance("YY");
Review comment:
Please add code in your new test for Y and YYY.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Closed] (IMAGING-274) Corrupted TIFF output
[
https://issues.apache.org/jira/browse/IMAGING-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bjoeni closed IMAGING-274.
--
Resolution: Not A Bug
Sorry, I didn't properly read the documentation. I passed the file bytes as
exif bytes which obviously doesn't work. I'm using the lossy TIFF writer for
now.
{code:java}
new TiffImageWriterLossy().write(os, outputSet);
{code}
> Corrupted TIFF output
> -
>
> Key: IMAGING-274
> URL: https://issues.apache.org/jira/browse/IMAGING-274
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0-alpha1, 1.0-alpha2
>Reporter: Bjoeni
>Priority: Major
> Attachments: 20171029_171217 - 20171029_171223-gps-corrupted.tif,
> 20171029_171217 - 20171029_171223-original.tif
>
>
> I'm attempting to update GPS data in JPEG and TIFF files. The following
> example results in corrupted TIFF files while working perfectly fine for JPEG:
> {code:java}
> try (BufferedOutputStream os = new BufferedOutputStream(new
> FileOutputStream(dst))) {
> if (metadata instanceof JpegImageMetadata) {
> new
> ExifRewriter().updateExifMetadataLossless(imageFile, os, outputSet);
> } else if (metadata instanceof TiffImageMetadata) {
> new
> TiffImageWriterLossless(FileUtils.readFileToByteArray(imageFile)).write(os,
> outputSet);
> }
> }
> {code}
> I attached both the original and the updated (corrupted) TIFF file with GPS
> data. Some software (e.g. Windows Photos) is able to show the images with
> black stripes, other software (including javax.ImageIO) is unable to read
> them at all.
> And even though not exactly related to this issue: It would be really awesome
> to have a similar ExifRewriter function for TIFF files!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530201&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530201
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 13:27
Start Date: 02/Jan/21 13:27
Worklog Time Spent: 10m
Work Description: garydgregory removed a comment on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753325246
Closing per the comment in the ticket
https://issues.apache.org/jira/browse/LANG-1637
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530201)
Time Spent: 1h 20m (was: 1h 10m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530202&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530202
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 13:27
Start Date: 02/Jan/21 13:27
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753473812
Reopening, I was going by the "invalid" comment.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530202)
Time Spent: 1.5h (was: 1h 20m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on pull request #688: LANG-1637: fix 2 digit week year formatting
garydgregory commented on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753473812 Reopening, I was going by the "invalid" comment. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] garydgregory removed a comment on pull request #688: LANG-1637: fix 2 digit week year formatting
garydgregory removed a comment on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753325246 Closing per the comment in the ticket https://issues.apache.org/jira/browse/LANG-1637 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530198&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530198
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 13:24
Start Date: 02/Jan/21 13:24
Worklog Time Spent: 10m
Work Description: ugonen opened a new pull request #688:
URL: https://github.com/apache/commons-lang/pull/688
https://issues.apache.org/jira/browse/LANG-1637
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530198)
Time Spent: 1h 10m (was: 1h)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257362#comment-17257362
]
Uri Gonen commented on LANG-1637:
-
[https://github.com/apache/commons-lang/pull/688] was closed based on this
JIRA, not sure why
what do you mean by "hu_HU" ?
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?focusedWorklogId=530195&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-530195
]
ASF GitHub Bot logged work on LANG-1637:
Author: ASF GitHub Bot
Created on: 02/Jan/21 12:56
Start Date: 02/Jan/21 12:56
Worklog Time Spent: 10m
Work Description: ugonen commented on pull request #688:
URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753470530
@garydgregory can you explain why you closed this PR ?
formatting date with year 31 Dec 2020 with pattern YY should result in '21'
but instead you get 'ú1' (before the fix) which is clearly a bug
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 530195)
Time Spent: 1h (was: 50m)
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] ugonen commented on pull request #688: LANG-1637: fix 2 digit week year formatting
ugonen commented on pull request #688: URL: https://github.com/apache/commons-lang/pull/688#issuecomment-753470530 @garydgregory can you explain why you closed this PR ? formatting date with year 31 Dec 2020 with pattern YY should result in '21' but instead you get 'ú1' (before the fix) which is clearly a bug 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257356#comment-17257356
]
Michael Osipov commented on LANG-1637:
--
We didn't close anything yet. We indicated that any amount of {{Y}} will give
you four digits. Why on {{hu_HU}} you get this result one needs to investigate.
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1637) FastDatePrinter formatting using YY pattern yields junk digits
[
https://issues.apache.org/jira/browse/LANG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257351#comment-17257351
]
Uri Gonen commented on LANG-1637:
-
[~ggregory] [~michael-o] not sure why you closed this ticket. I stated that the
the test above fails, i.e., the year is *not* truncated to 2 digits *properly*
as stated in the javaoc. formatting date with year 31 Dec 2020 with pattern YY
should result in '21' but instead you get 'ú1'
> FastDatePrinter formatting using YY pattern yields junk digits
> --
>
> Key: LANG-1637
> URL: https://issues.apache.org/jira/browse/LANG-1637
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Uri Gonen
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {code:java}
> final GregorianCalendar cal = new GregorianCalendar(2020, 12, 31, 0, 0, 0);
> final DatePrinter printer2Digits = getInstance("YY");
> assertEquals("21", printer2Digits.format(cal));
> {code}
> the above test fails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
