[GitHub] commons-lang pull request: fix JsonToStringStyle
Github user jacktan1991 commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/74#discussion_r29491785
--- Diff: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
---
@@ -2568,13 +2573,13 @@ protected void appendDetail(StringBuffer buffer,
String fieldName, Object value)
return;
}
-if (value.getClass() == String.class) {
+if (value instanceof Number || value.getClass() ==
Boolean.class) {
-appendValueAsString(buffer, (String)value);
+buffer.append(value);
return;
}
-buffer.append(value);
+appendValueAsString(buffer, value.toString());
--- End diff --
Yes. But if `Address` like you suppose here does not *Override*
`Object.toString()` (maybe someone just wants Address instance represented by
its hash code), then its json style looks like `"address":"Address@1ab2f62"`.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] commons-lang pull request: fix JsonToStringStyle
Github user coveralls commented on the pull request: https://github.com/apache/commons-lang/pull/74#issuecomment-98058183 [](https://coveralls.io/builds/2464114) Coverage increased (+0.01%) to 93.33% when pulling **b08c903ad2161847be53df0e0a20da625a90ba43 on jacktan1991:branch-3.4-fix-json-style-rebase** into **102b75cd923c30fb81047211ea1eb0b12cfe1a43 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (DBCP-438) Nested connections in a transaction (local) throws null pointer
[
https://issues.apache.org/jira/browse/DBCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522739#comment-14522739
]
Phil Steitz commented on DBCP-438:
--
A quick fix that would eliminate the NPE would be to just have
DelegatingConnection#closeInternal null-check _conn. But we should verify
correctness of the logic in MC updateTransactionStatus.
> Nested connections in a transaction (local) throws null pointer
> ---
>
> Key: DBCP-438
> URL: https://issues.apache.org/jira/browse/DBCP-438
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
> Environment: All (linux, aix, windows)
>Reporter: Raihan Kibria
> Fix For: 2.1.1
>
> Attachments: TestManagedDataSourceInNesetedConnTx.java, dbcpNull.png
>
>
> In a transaction context, if we open multiple connections and close each of
> them after commit, we get a null pointer exception. Sample code:
> transactionManager.begin();
>
> Connection c1 = null;
> Connection c2 = null;
>
> c1 = newConnection();
> c2 = newConnection();
>
> transactionManager.commit();
>
> try{
> c1.close();
> }catch(Exception e){
> e.printStackTrace();
> }
>
> try{
> c2.close();
> }catch(Exception e){
> //throws execption
> e.printStackTrace();
> }
> Null pointer is thrown at:
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal
> Affects versions-- 2.1, 2.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-438) Nested connections in a transaction (local) throws null pointer
[
https://issues.apache.org/jira/browse/DBCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated DBCP-438:
-
Affects Version/s: 2.0
Fix Version/s: 2.1.1
> Nested connections in a transaction (local) throws null pointer
> ---
>
> Key: DBCP-438
> URL: https://issues.apache.org/jira/browse/DBCP-438
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
> Environment: All (linux, aix, windows)
>Reporter: Raihan Kibria
> Fix For: 2.1.1
>
> Attachments: TestManagedDataSourceInNesetedConnTx.java, dbcpNull.png
>
>
> In a transaction context, if we open multiple connections and close each of
> them after commit, we get a null pointer exception. Sample code:
> transactionManager.begin();
>
> Connection c1 = null;
> Connection c2 = null;
>
> c1 = newConnection();
> c2 = newConnection();
>
> transactionManager.commit();
>
> try{
> c1.close();
> }catch(Exception e){
> e.printStackTrace();
> }
>
> try{
> c2.close();
> }catch(Exception e){
> //throws execption
> e.printStackTrace();
> }
> Null pointer is thrown at:
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal
> Affects versions-- 2.1, 2.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBCP-438) Nested connections in a transaction (local) throws null pointer
[
https://issues.apache.org/jira/browse/DBCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522732#comment-14522732
]
Phil Steitz commented on DBCP-438:
--
Thanks for reporting this and extra thanks for the test case. I think the
problem is likely in the updateTransactionStatus method in ManagedConnection.
> Nested connections in a transaction (local) throws null pointer
> ---
>
> Key: DBCP-438
> URL: https://issues.apache.org/jira/browse/DBCP-438
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: All (linux, aix, windows)
>Reporter: Raihan Kibria
> Attachments: TestManagedDataSourceInNesetedConnTx.java, dbcpNull.png
>
>
> In a transaction context, if we open multiple connections and close each of
> them after commit, we get a null pointer exception. Sample code:
> transactionManager.begin();
>
> Connection c1 = null;
> Connection c2 = null;
>
> c1 = newConnection();
> c2 = newConnection();
>
> transactionManager.commit();
>
> try{
> c1.close();
> }catch(Exception e){
> e.printStackTrace();
> }
>
> try{
> c2.close();
> }catch(Exception e){
> //throws execption
> e.printStackTrace();
> }
> Null pointer is thrown at:
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal
> Affects versions-- 2.1, 2.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Honton resolved LANG-916.
-
Resolution: Fixed
commit 775203dd2cfce017910d04c58a0b1b4e0a64923c
These changes have subtle implications. The TimeZone of the Calendar being
formatted will no longer be used as the TImeZone of the formatted output. The
TimeZone specified during construction of the Formatter/Printer will be used as
the formatted TimeZone, (if no TimeZone is specified during construction, the
system default TimeZone will be used.)
> CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
> certain situations
>
>
> Key: LANG-916
> URL: https://issues.apache.org/jira/browse/LANG-916
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
> Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
>Reporter: Christian P. MOMON
>Assignee: Charles Honton
> Labels: patch, time
> Fix For: Patch Needed
>
> Attachments: LANG-916-B.patch, LANG-916-C.patch,
> LANG-916-final-git.patch, LANG-916.patch
>
>
> In LANG-538 issue, there is an unit test:
> {noformat}
> public void testFormat_CalendarIsoMsZulu() {
> final String dateTime = "2009-10-16T16:42:16.000Z";
> GregorianCalendar cal = new
> GregorianCalendar(TimeZone.getTimeZone("GMT-8"));
> cal.clear();
> cal.set(2009, 9, 16, 8, 42, 16);
> cal.getTime();
> FastDateFormat format =
> FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("GMT"));
> assertEquals("dateTime", dateTime, format.format(cal));
> }
> {noformat}
> This test passes successfully in lang-2.6 but failed in lang3-3.1:
> {noformat}
> org.junit.ComparisonFailure: dateTime expected:<2009-10-16T[16]:42:16.000Z>
> but was:<2009-10-16T[08]:42:16.000Z>
> {noformat}
> Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
> Moreover, I wrote another unit test showing that the timeZone parameter seems
> to be ignored :
> {noformat}
> public void test() {
> Calendar cal =
> Calendar.getInstance(TimeZone.getTimeZone("Europe/Paris"));
> cal.set(2009, 9, 16, 8, 42, 16);
> //
> System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
> System.out.println("long");
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar");
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar fast");
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/Paris")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Asia/Kolkata")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/London")).format(cal));
> }
> {noformat}
> Gives the following console logs:
> {noformat}
> long
> 2009-10-16T08:42:16+02:00
> 2009-10-16T12:12:16+05:30
> 2009-10-16T07:42:16+01:00
> calendar
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> calendar fast
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> {noformat}
> When DateFormatUtils.format takes a long parameter, the time string is good.
> When DateFormatUtils.format takes a Calendar parameter, the time string is
> wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LANG-1123) Unit test FastDatePrinterTimeZonesTest needs a timezone set
[
https://issues.apache.org/jira/browse/LANG-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Honton resolved LANG-1123.
--
Resolution: Fixed
changelist 775203dd2cfce017910d04c58a0b1b4e0a64923c
Note that there were other unit tests needing repair. Many of
DateFormatUtilsTest made improper assumptions about the active TimeZone.
> Unit test FastDatePrinterTimeZonesTest needs a timezone set
> ---
>
> Key: LANG-1123
> URL: https://issues.apache.org/jira/browse/LANG-1123
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
> Environment: Java 6, timezone is "Europe/Paris" (GMT/UTC +01:00),
> GNU/Linux.
>Reporter: Christian P. MOMON
>Assignee: Charles Honton
>Priority: Blocker
> Fix For: Review Patch
>
> Attachments: LANG-1123-fix-git.patch
>
>
> In file :
> {noformat}
> src/test/java/org/apache/commons/lang3/time/FastDatePrinterTimeZonesTest.java
> {noformat}
> The unit test testCalendarTimezoneRespected set a timezone for the
> expectedValue but none for the actualValue. Because the actualValue use
> always the default timezone, then It has to fail.
> Actually, there is no fail because of a bug in FastDatePrinter.format()
> method (see LANG-916).
> When applying the LANG-916 patch, the unit test flood more than 600 failed:
> {noformat}
> cpm > mvn test
> Failed tests:
> [...]
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[2:19PM EDT]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[2:19PM AST]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[12:19PM MDT]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[1:19PM ACT]> but was:<[6:19PM UTC]>
> [...]
> Tests run: 3544, Failures: 617, Errors: 0, Skipped: 5
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522484#comment-14522484
]
Charles Honton commented on LANG-916:
-
I agree with your reasoning. I'll update the javadoc to make that clear.
> CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
> certain situations
>
>
> Key: LANG-916
> URL: https://issues.apache.org/jira/browse/LANG-916
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
> Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
>Reporter: Christian P. MOMON
> Labels: patch, time
> Fix For: Patch Needed
>
> Attachments: LANG-916-B.patch, LANG-916-C.patch,
> LANG-916-final-git.patch, LANG-916.patch
>
>
> In LANG-538 issue, there is an unit test:
> {noformat}
> public void testFormat_CalendarIsoMsZulu() {
> final String dateTime = "2009-10-16T16:42:16.000Z";
> GregorianCalendar cal = new
> GregorianCalendar(TimeZone.getTimeZone("GMT-8"));
> cal.clear();
> cal.set(2009, 9, 16, 8, 42, 16);
> cal.getTime();
> FastDateFormat format =
> FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("GMT"));
> assertEquals("dateTime", dateTime, format.format(cal));
> }
> {noformat}
> This test passes successfully in lang-2.6 but failed in lang3-3.1:
> {noformat}
> org.junit.ComparisonFailure: dateTime expected:<2009-10-16T[16]:42:16.000Z>
> but was:<2009-10-16T[08]:42:16.000Z>
> {noformat}
> Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
> Moreover, I wrote another unit test showing that the timeZone parameter seems
> to be ignored :
> {noformat}
> public void test() {
> Calendar cal =
> Calendar.getInstance(TimeZone.getTimeZone("Europe/Paris"));
> cal.set(2009, 9, 16, 8, 42, 16);
> //
> System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
> System.out.println("long");
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar");
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar fast");
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/Paris")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Asia/Kolkata")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/London")).format(cal));
> }
> {noformat}
> Gives the following console logs:
> {noformat}
> long
> 2009-10-16T08:42:16+02:00
> 2009-10-16T12:12:16+05:30
> 2009-10-16T07:42:16+01:00
> calendar
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> calendar fast
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> {noformat}
> When DateFormatUtils.format takes a long parameter, the time string is good.
> When DateFormatUtils.format takes a Calendar parameter, the time string is
> wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LANG-1116) DateUtilsTest.testLang530 fails for some timezones
[
https://issues.apache.org/jira/browse/LANG-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Honton resolved LANG-1116.
--
Resolution: Fixed
commit bea1ae92aa52a985f8c171c6e17ff7fc4aa61fe4
Using FastDateParser which can handle Z formats
(feel free to rollback if you think the solution too radical)
> DateUtilsTest.testLang530 fails for some timezones
> --
>
> Key: LANG-1116
> URL: https://issues.apache.org/jira/browse/LANG-1116
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.4
> Environment: Redhat 5 / Java8u45
>Reporter: Aaron Sheldon
>Assignee: Charles Honton
> Fix For: Discussion
>
> Attachments: lang-1116.patch, lang-1116.patch
>
>
> Unit test for testLang530 fails when the isoDateStr comes out with just a Z
> instead of +00:00.
> {code}
> Tests run: 38, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.014 sec
> <<< FAILURE! - in org.apache.commons.lang3.time.DateUtilsTest
> testLang530(org.apache.commons.lang3.time.DateUtilsTest) Time elapsed: 0.005
> sec <<< ERROR!
> java.text.ParseException: Unable to parse the date: 2015-04-17T18:51:52Z
> at
> org.apache.commons.lang3.time.DateUtils.parseDateWithLeniency(DateUtils.java:401)
> at
> org.apache.commons.lang3.time.DateUtils.parseDate(DateUtils.java:301)
> at
> org.apache.commons.lang3.time.DateUtils.parseDate(DateUtils.java:278)
> at
> org.apache.commons.lang3.time.DateUtilsTest.testLang530(DateUtilsTest.java:1222)
> {code}
> On a Linux machine where this test passes, isoDateStr is
> 2015-04-17T19:26:03+00:00.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522422#comment-14522422
]
Christian P. MOMON edited comment on LANG-916 at 4/30/15 10:53 PM:
---
I am not agree with you <3 A Calendar parameter is containing an absolute date
time information. If I put a calendar parameter and a timezone parameter, it is
because I want use this absolute date time with another timezone. The new
timezone has priority. This is a common need. So the method is relevant and
unambiguous.
Is there any error in my reasoning? :D
I see that the null timezone case is not described in method comment. If
timezone parameter is null then the default timezone is used. Perhaps it would
be good to add a comment about it. (on)
Because this subject is very different than the LANG-916 subject, can I suggest
to create a dedicated issue for it?
Regards. :-)
was (Author: cpm):
I am not agree with you <3 A Calendar parameter is containing an absolute date
time information. If I put a calendar parameter and a timezone parameter, it is
because I want use this absolute date time with another timezone. The new
timezone has priority. This is a common need. So the method is relevant and
unambiguous.
Is there any error in my reasoning? :D
I see that the null timezone case is not described in method comment. If
timezone parameter is null then the default timezone is used. Perhaps it would
be good to add a comment about it.
Because this subject is very different than the LANG-916 subject, can I suggest
to create a dedicated issue for it?
Regards. :-)
> CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
> certain situations
>
>
> Key: LANG-916
> URL: https://issues.apache.org/jira/browse/LANG-916
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
> Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
>Reporter: Christian P. MOMON
> Labels: patch, time
> Fix For: Patch Needed
>
> Attachments: LANG-916-B.patch, LANG-916-C.patch,
> LANG-916-final-git.patch, LANG-916.patch
>
>
> In LANG-538 issue, there is an unit test:
> {noformat}
> public void testFormat_CalendarIsoMsZulu() {
> final String dateTime = "2009-10-16T16:42:16.000Z";
> GregorianCalendar cal = new
> GregorianCalendar(TimeZone.getTimeZone("GMT-8"));
> cal.clear();
> cal.set(2009, 9, 16, 8, 42, 16);
> cal.getTime();
> FastDateFormat format =
> FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("GMT"));
> assertEquals("dateTime", dateTime, format.format(cal));
> }
> {noformat}
> This test passes successfully in lang-2.6 but failed in lang3-3.1:
> {noformat}
> org.junit.ComparisonFailure: dateTime expected:<2009-10-16T[16]:42:16.000Z>
> but was:<2009-10-16T[08]:42:16.000Z>
> {noformat}
> Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
> Moreover, I wrote another unit test showing that the timeZone parameter seems
> to be ignored :
> {noformat}
> public void test() {
> Calendar cal =
> Calendar.getInstance(TimeZone.getTimeZone("Europe/Paris"));
> cal.set(2009, 9, 16, 8, 42, 16);
> //
> System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
> System.out.println("long");
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar");
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar fast");
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/Paris")).format(cal));
>
> System.out
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522422#comment-14522422
]
Christian P. MOMON commented on LANG-916:
-
I am not agree with you <3 A Calendar parameter is containing an absolute date
time information. If I put a calendar parameter and a timezone parameter, it is
because I want use this absolute date time with another timezone. The new
timezone has priority. This is a common need. So the method is relevant and
unambiguous.
Is there any error in my reasoning? :D
I see that the null timezone case is not described in method comment. If
timezone parameter is null then the default timezone is used. Perhaps it would
be good to add a comment about it.
Because this subject is very different than the LANG-916 subject, can I suggest
to create a dedicated issue for it?
Regards. :-)
> CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
> certain situations
>
>
> Key: LANG-916
> URL: https://issues.apache.org/jira/browse/LANG-916
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
> Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
>Reporter: Christian P. MOMON
> Labels: patch, time
> Fix For: Patch Needed
>
> Attachments: LANG-916-B.patch, LANG-916-C.patch,
> LANG-916-final-git.patch, LANG-916.patch
>
>
> In LANG-538 issue, there is an unit test:
> {noformat}
> public void testFormat_CalendarIsoMsZulu() {
> final String dateTime = "2009-10-16T16:42:16.000Z";
> GregorianCalendar cal = new
> GregorianCalendar(TimeZone.getTimeZone("GMT-8"));
> cal.clear();
> cal.set(2009, 9, 16, 8, 42, 16);
> cal.getTime();
> FastDateFormat format =
> FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("GMT"));
> assertEquals("dateTime", dateTime, format.format(cal));
> }
> {noformat}
> This test passes successfully in lang-2.6 but failed in lang3-3.1:
> {noformat}
> org.junit.ComparisonFailure: dateTime expected:<2009-10-16T[16]:42:16.000Z>
> but was:<2009-10-16T[08]:42:16.000Z>
> {noformat}
> Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
> Moreover, I wrote another unit test showing that the timeZone parameter seems
> to be ignored :
> {noformat}
> public void test() {
> Calendar cal =
> Calendar.getInstance(TimeZone.getTimeZone("Europe/Paris"));
> cal.set(2009, 9, 16, 8, 42, 16);
> //
> System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
> System.out.println("long");
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar");
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar fast");
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/Paris")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Asia/Kolkata")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/London")).format(cal));
> }
> {noformat}
> Gives the following console logs:
> {noformat}
> long
> 2009-10-16T08:42:16+02:00
> 2009-10-16T12:12:16+05:30
> 2009-10-16T07:42:16+01:00
> calendar
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> calendar fast
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> {noformat}
> When DateFormatUtils.format takes a long parameter, the time string is good.
> When DateFormatUtils.format takes a Calendar parameter
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522303#comment-14522303
]
Charles Honton commented on LANG-916:
-
There is a basic problem in the DateFormatUtils.format(Calendar, String
pattern, TimeZone, Locale) api. (And furthermore, the
FastDateFormat/FastDatePrinter.format(Calendar) apis.) Should the
implementation pay attention to the TimeZone set on the Calendar or the
TimeZone that is passed in the constructor? I recommend deprecating this
method with an explanation what it currently does and what the desired practice
should be.
> CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
> certain situations
>
>
> Key: LANG-916
> URL: https://issues.apache.org/jira/browse/LANG-916
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
> Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
>Reporter: Christian P. MOMON
> Labels: patch, time
> Fix For: Patch Needed
>
> Attachments: LANG-916-B.patch, LANG-916-C.patch,
> LANG-916-final-git.patch, LANG-916.patch
>
>
> In LANG-538 issue, there is an unit test:
> {noformat}
> public void testFormat_CalendarIsoMsZulu() {
> final String dateTime = "2009-10-16T16:42:16.000Z";
> GregorianCalendar cal = new
> GregorianCalendar(TimeZone.getTimeZone("GMT-8"));
> cal.clear();
> cal.set(2009, 9, 16, 8, 42, 16);
> cal.getTime();
> FastDateFormat format =
> FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("GMT"));
> assertEquals("dateTime", dateTime, format.format(cal));
> }
> {noformat}
> This test passes successfully in lang-2.6 but failed in lang3-3.1:
> {noformat}
> org.junit.ComparisonFailure: dateTime expected:<2009-10-16T[16]:42:16.000Z>
> but was:<2009-10-16T[08]:42:16.000Z>
> {noformat}
> Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
> Moreover, I wrote another unit test showing that the timeZone parameter seems
> to be ignored :
> {noformat}
> public void test() {
> Calendar cal =
> Calendar.getInstance(TimeZone.getTimeZone("Europe/Paris"));
> cal.set(2009, 9, 16, 8, 42, 16);
> //
> System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
> System.out.println("long");
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar");
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar fast");
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/Paris")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Asia/Kolkata")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/London")).format(cal));
> }
> {noformat}
> Gives the following console logs:
> {noformat}
> long
> 2009-10-16T08:42:16+02:00
> 2009-10-16T12:12:16+05:30
> 2009-10-16T07:42:16+01:00
> calendar
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> calendar fast
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> {noformat}
> When DateFormatUtils.format takes a long parameter, the time string is good.
> When DateFormatUtils.format takes a Calendar parameter, the time string is
> wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1153) Sampling from a 'BetaDistribution' is slow
[
https://issues.apache.org/jira/browse/MATH-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522272#comment-14522272
]
Thomas Neidhart commented on MATH-1153:
---
I did not write a jmh benchmark yet, but it looks like that for alpha/beta
values < 1 the variant with sampling from a gamma distribution is faster, while
for values > 1 the cheng sampling method is slightly faster.
The difference is just small, and is probably negligible once the code has been
compiled natively.
> Sampling from a 'BetaDistribution' is slow
> --
>
> Key: MATH-1153
> URL: https://issues.apache.org/jira/browse/MATH-1153
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sergei Lebedev
>Priority: Minor
> Fix For: 4.0
>
> Attachments: ChengBetaSampler.java, ChengBetaSampler.java,
> ChengBetaSamplerTest.java
>
>
> Currently the `BetaDistribution#sample` uses inverse CDF method, which is
> quite slow for sampling-intensive computations. I've implemented a method
> from the R. C. H. Cheng paper and it seems to work much better. Here's a
> simple microbenchmark:
> {code}
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 1e-31000 thrpt5
> 2592200.01514391.520 ops/s
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 10001000 thrpt5
> 3210800.2920.791 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion1e-31000 thrpt5
> 31034.225 438.273 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion10001000 thrpt5
> 21834.010 433.324 ops/s
> {code}
> Should I submit a patch?
> R. C. H. Cheng (1978). Generating beta variates with nonintegral shape
> parameters. Communications of the ACM, 21, 317–322.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1153) Sampling from a 'BetaDistribution' is slow
[
https://issues.apache.org/jira/browse/MATH-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522242#comment-14522242
]
Sergei Lebedev commented on MATH-1153:
--
Interesting, can you provide benchmark results for different values of alpha
and beta?
> Sampling from a 'BetaDistribution' is slow
> --
>
> Key: MATH-1153
> URL: https://issues.apache.org/jira/browse/MATH-1153
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sergei Lebedev
>Priority: Minor
> Fix For: 4.0
>
> Attachments: ChengBetaSampler.java, ChengBetaSampler.java,
> ChengBetaSamplerTest.java
>
>
> Currently the `BetaDistribution#sample` uses inverse CDF method, which is
> quite slow for sampling-intensive computations. I've implemented a method
> from the R. C. H. Cheng paper and it seems to work much better. Here's a
> simple microbenchmark:
> {code}
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 1e-31000 thrpt5
> 2592200.01514391.520 ops/s
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 10001000 thrpt5
> 3210800.2920.791 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion1e-31000 thrpt5
> 31034.225 438.273 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion10001000 thrpt5
> 21834.010 433.324 ops/s
> {code}
> Should I submit a patch?
> R. C. H. Cheng (1978). Generating beta variates with nonintegral shape
> parameters. Communications of the ACM, 21, 317–322.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MATH-1153) Sampling from a 'BetaDistribution' is slow
[
https://issues.apache.org/jira/browse/MATH-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520038#comment-14520038
]
Thomas Neidhart edited comment on MATH-1153 at 4/30/15 8:52 PM:
After fixing the KS inference tests the respective test failures disappeared as
expected.
The remaining test failure in testNextInversionDeviate is because the Cheng
sampler uses a kind of rejection sampling method and will consume more
randomness from the provided RandomGenerator.
This is a recurring issue, as also for other distributions there are improved
sampling methods that consume more randomness (see MATH-1220 for the Zipf
distribution).
This also relates to MATH-1158 as it proposes a different way to create a
sampler for a distribution. This would probably also allow to provide different
samplers using a common interface, e.g. the default one uses the inverse
transform method while more optimized ones could be available which require
different assumptions, e.g. wrt the RandomGenerator.
was (Author: tn):
After fixing the KS inference tests the respective test failures disappeared as
expected.
The remaining test failure in testNextInversionDeviate is because the Cheng
sampler uses a kind of rejection sampling method and will consume more
randomness from the provided RandomGenerator.
This is a recurring issue, as also for other distributions there are improved
sampling methods that consume more randomness (see MATH-1220 for the Zipf
distribution).
This also relates to MATH-1153 as it proposes a different way to create a
sampler for a distribution. This would probably also allow to provide different
samplers using a common interface, e.g. the default one uses the inverse
transform method while more optimized ones could be available which require
different assumptions, e.g. wrt the RandomGenerator.
> Sampling from a 'BetaDistribution' is slow
> --
>
> Key: MATH-1153
> URL: https://issues.apache.org/jira/browse/MATH-1153
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sergei Lebedev
>Priority: Minor
> Fix For: 4.0
>
> Attachments: ChengBetaSampler.java, ChengBetaSampler.java,
> ChengBetaSamplerTest.java
>
>
> Currently the `BetaDistribution#sample` uses inverse CDF method, which is
> quite slow for sampling-intensive computations. I've implemented a method
> from the R. C. H. Cheng paper and it seems to work much better. Here's a
> simple microbenchmark:
> {code}
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 1e-31000 thrpt5
> 2592200.01514391.520 ops/s
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 10001000 thrpt5
> 3210800.2920.791 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion1e-31000 thrpt5
> 31034.225 438.273 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion10001000 thrpt5
> 21834.010 433.324 ops/s
> {code}
> Should I submit a patch?
> R. C. H. Cheng (1978). Generating beta variates with nonintegral shape
> parameters. Communications of the ACM, 21, 317–322.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1153) Sampling from a 'BetaDistribution' is slow
[
https://issues.apache.org/jira/browse/MATH-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522216#comment-14522216
]
Thomas Neidhart commented on MATH-1153:
---
Looking at the wikipedia page I found another way to sample from a beta
distribution:
{code}
sample X from a gamma distribution with parameters (alpha, 1)
sample Y from a gamma distribution with parameters (beta, 1)
return X / (X + Y)
{code}
I quickly tested this method and it is even faster than the Cheng method,
succeeding the tests.
The same method is also implemented in mahout (see
https://github.com/apache/mahout/blob/master/mr/src/main/java/org/apache/mahout/clustering/UncommonDistributions.java)
> Sampling from a 'BetaDistribution' is slow
> --
>
> Key: MATH-1153
> URL: https://issues.apache.org/jira/browse/MATH-1153
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sergei Lebedev
>Priority: Minor
> Fix For: 4.0
>
> Attachments: ChengBetaSampler.java, ChengBetaSampler.java,
> ChengBetaSamplerTest.java
>
>
> Currently the `BetaDistribution#sample` uses inverse CDF method, which is
> quite slow for sampling-intensive computations. I've implemented a method
> from the R. C. H. Cheng paper and it seems to work much better. Here's a
> simple microbenchmark:
> {code}
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 1e-31000 thrpt5
> 2592200.01514391.520 ops/s
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 10001000 thrpt5
> 3210800.2920.791 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion1e-31000 thrpt5
> 31034.225 438.273 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion10001000 thrpt5
> 21834.010 433.324 ops/s
> {code}
> Should I submit a patch?
> R. C. H. Cheng (1978). Generating beta variates with nonintegral shape
> parameters. Communications of the ACM, 21, 317–322.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CONFIGURATION-599) CombinedConfiguration fails to merge correctly when one configuration only contains one property
[
https://issues.apache.org/jira/browse/CONFIGURATION-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522124#comment-14522124
]
Oliver Heger commented on CONFIGURATION-599:
I have never used {{MergeCombiner}} myself. So the only reference is the API
documentation of this class. There is the point
bq. Only a single node in the second file is considered a match to the node in
the first file.
Can this be related to your problem?
You said that you use {MergeCombiner}} because it is used elsewhere in the
project. This seems a bit strange to me. I would expect that you have some
concrete requirements and based on these choose the appropriate combiner.
> CombinedConfiguration fails to merge correctly when one configuration only
> contains one property
>
>
> Key: CONFIGURATION-599
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-599
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Martin Lindgren
>Priority: Critical
>
> When using a CombinedConfiguration it fails to merge properties located in
> both of the configurations if one of the configuration only contains 1
> property.
> {code:title=CombinedConfiguration.java|borderStyle=solid}
> public static void main(String[] args)
> {
> NodeCombiner combiner = new MergeCombiner();
> combiner.addListNode("module");
> CombinedConfiguration configuration = new
> CombinedConfiguration(combiner);
>
> XMLConfiguration xmlConf = new XMLConfiguration();
> xmlConf.addProperty("modules.module", "1");
> xmlConf.addProperty("modules.module", "2");
> xmlConf.addProperty("modules.module", "3");
>
> XMLConfiguration xmlConf2 = new XMLConfiguration();
> xmlConf2.addProperty("modules.module", "4");
> configuration.addConfiguration(xmlConf);
> configuration.addConfiguration(xmlConf2);
>
> //THIS WILL NOT PRINT THE VALUE 4 FROM XMLCONF2
> for(String s : configuration.getStringArray("modules.module"))
> {
> System.out.println(s);
> }
>
> System.out.println();
> //Now add one more additional property
> xmlConf2.addProperty("modules.module", "5");
>
> //NOW IT WILL PRINT BOTH VALUE 4 AND 5 FROM XMLCONF2
> for(String s : configuration.getStringArray("modules.module"))
> {
> System.out.println(s);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLI-249) Message for an illegal character in an option should contain more information
[ https://issues.apache.org/jira/browse/CLI-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521988#comment-14521988 ] Benedikt Ritter commented on CLI-249: - Hello [~dfg], would you like to create a patch/PR at github to sketch out, how you think a good/useful API should look like? With the DefaultParser and the new OptionBuilder we're introducing some new APIs so it would make sense to fix this as well. Thanks! Benedikt > Message for an illegal character in an option should contain more information > - > > Key: CLI-249 > URL: https://issues.apache.org/jira/browse/CLI-249 > Project: Commons CLI > Issue Type: Improvement > Components: CLI-1.x >Reporter: David Goodenough > Fix For: 1.3 > > > Currently the code in org.apache.commons.cli.OptionValidator generates an > IllegalArgumentException which contains the message:- > "illegal option value '" + ch + "'" > This is generated in two places, one for single character options and one for > multi character options. > However this does not tell the caller which option it is contains this > character, which makes debugging the error without the source (i.e most > users) extremely difficult. > Would it not be possible to change the message to:- > "illegal option '" + opt + "' value '" + ch + "'" > which would then at least identify the offending option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang pull request: fix JsonToStringStyle
Github user britter commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/74#discussion_r29455380
--- Diff: src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
---
@@ -2568,13 +2573,13 @@ protected void appendDetail(StringBuffer buffer,
String fieldName, Object value)
return;
}
-if (value.getClass() == String.class) {
+if (value instanceof Number || value.getClass() ==
Boolean.class) {
-appendValueAsString(buffer, (String)value);
+buffer.append(value);
return;
}
-buffer.append(value);
+appendValueAsString(buffer, value.toString());
--- End diff --
I don't think this is correct for nested object structures. Suppose we have
the following class structure:
```java
public class Person {
private String name;
private Address address;
}
public class Address {
private String city;
private String zip;
}
```
Translating this to JavaScript/JSON should look like this if both, Person
and Address use the JsonToStringStyle for their equals method:
```JavaScript
{
"name": "Peter",
"address": {
"city": "New York",
"zip": "10026"
}
}
```
If we apply this fix, the result will look like this:
```JavaScript
{
"name": "Peter",
"address": "{
"city": "New York",
"zip": "10026"
}"
}
```
Note the additional double quotes around the address object.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (LANG-1118) StringUtils.repeat('z', -1) throws NegativeArraySizeException
[
https://issues.apache.org/jira/browse/LANG-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521928#comment-14521928
]
ASF GitHub Bot commented on LANG-1118:
--
Github user rikles commented on the pull request:
https://github.com/apache/commons-lang/pull/72#issuecomment-97894359
Merged into master. Close PR.
> StringUtils.repeat('z', -1) throws NegativeArraySizeException
> -
>
> Key: LANG-1118
> URL: https://issues.apache.org/jira/browse/LANG-1118
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Loic Guibert
>Assignee: Benedikt Ritter
>Priority: Minor
> Fix For: 3.5
>
>
> Unlike what is said in JavaDoc comment, when passing a negative repeat value
> to the *StringUtils.repeat(char, int)* function, it doesn't return an empty
> String but throws a _NegativeArraySizeException_.
> See PR #72 : https://github.com/apache/commons-lang/pull/72
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1118) StringUtils.repeat('z', -1) throws NegativeArraySizeException
[
https://issues.apache.org/jira/browse/LANG-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521929#comment-14521929
]
ASF GitHub Bot commented on LANG-1118:
--
Github user rikles closed the pull request at:
https://github.com/apache/commons-lang/pull/72
> StringUtils.repeat('z', -1) throws NegativeArraySizeException
> -
>
> Key: LANG-1118
> URL: https://issues.apache.org/jira/browse/LANG-1118
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Loic Guibert
>Assignee: Benedikt Ritter
>Priority: Minor
> Fix For: 3.5
>
>
> Unlike what is said in JavaDoc comment, when passing a negative repeat value
> to the *StringUtils.repeat(char, int)* function, it doesn't return an empty
> String but throws a _NegativeArraySizeException_.
> See PR #72 : https://github.com/apache/commons-lang/pull/72
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request: LANG-1118: Fix StringUtils.repeat(char,...
Github user rikles closed the pull request at: https://github.com/apache/commons-lang/pull/72 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request: LANG-1118: Fix StringUtils.repeat(char,...
Github user rikles commented on the pull request: https://github.com/apache/commons-lang/pull/72#issuecomment-97894359 Merged into master. Close PR. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (MATH-1220) More efficient sample() method for ZipfDistribution
[ https://issues.apache.org/jira/browse/MATH-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521921#comment-14521921 ] Otmar Ertl commented on MATH-1220: -- Since we are sampling from a finite number of points, convergence of the infinite series is irrelevant. Exponent equal to 0 corresponds to a uniform distribution. Yes, the tail includes the points starting from 2 to N, because the first point (the head) is treated differently in order to limit the rejection rate. Otherwise, the rejection rate could become arbitrarily large for large exponents. > More efficient sample() method for ZipfDistribution > --- > > Key: MATH-1220 > URL: https://issues.apache.org/jira/browse/MATH-1220 > Project: Commons Math > Issue Type: Improvement >Reporter: Otmar Ertl > Attachments: patch_v1 > > > Currently, sampling from a ZipfDistribution is very inefficient. Random > values are generated by inverting the CDF. However, the current > implementation uses O(N) power function evaluations to calculate the CDF for > some point. (Here N is the number of points of the Zipf distribution.) I > propose to use rejection sampling instead, which allows the generation of a > single random value in constant time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang pull request: Adding unwrap and unwrapFull methods to...
Github user thiagoh commented on the pull request: https://github.com/apache/commons-lang/pull/25#issuecomment-96798120 Hi @britter what should I do by now? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (LANG-1121) FastDateFormat.parse() does not handle wrong length string
[
https://issues.apache.org/jira/browse/LANG-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Honton resolved LANG-1121.
--
Resolution: Invalid
Commit cb83f7cb31e50f265e098c5380b3f0051e257f46 has a test to show that this is
same behavior as SimpleDateFormat.
> FastDateFormat.parse() does not handle wrong length string
> --
>
> Key: LANG-1121
> URL: https://issues.apache.org/jira/browse/LANG-1121
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.3.2
>Reporter: Henry Kang
>Assignee: Charles Honton
>Priority: Minor
> Fix For: Patch Needed
>
>
> FDFP does not handled wrong length string.
> for example,
> {code}
> // Wed Apr 29 00:00:00 KST 2015
> FastDateFormat.getInstance("MMdd").parse("20150429");
> // throws ParseException
> FastDateFormat.getInstance("MMdd").parse("2015");
> // Thu Mar 16 00:00:00 KST 81724
> FastDateFormat.getInstance("MMdd").parse("20150429113100");
> {code}
> I think result of third throws ParseException,
> but FastDateFormat.parse() returns wrong year, ex, 81724 instead of 2015.
> As I tested,
> regex.matcher.group => (2015)(04)(29113100) => setCalendar => March 16, 81724
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1125) No release notes for version 3.4
Arend v. Reinersdorff created LANG-1125: --- Summary: No release notes for version 3.4 Key: LANG-1125 URL: https://issues.apache.org/jira/browse/LANG-1125 Project: Commons Lang Issue Type: Bug Components: Website Affects Versions: 3.4 Reporter: Arend v. Reinersdorff - Go to the release history page https://commons.apache.org/proper/commons-lang/release-history.html - click the link "release notes for 3.4" Result is a 404 error "Not Found". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[ https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521576#comment-14521576 ] Alexander Nozik commented on MATH-1143: --- Thank you Luc, I think that's what I needed. > Helper methods to FiniteDifferencesDifferentiator > - > > Key: MATH-1143 > URL: https://issues.apache.org/jira/browse/MATH-1143 > Project: Commons Math > Issue Type: Improvement >Reporter: Alexander Nozik >Priority: Trivial > > A DerivativeStructure and UnivariateDifferentiableFunction are great tools if > one needs to investigate the whole function but are not convenient if one > just needs derivative in a given point. > Perhaps you could add some helper methods to FiniteDifferencesDifferentiator > or to utility class like FunctionUtils. Also it would be good to have helper > methods to get the derivatives of UnivariateDifferentiableFunction or > MultivariateDifferentiableFunction as simple Univariate or Multivariate > functions (or vector-functions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[
https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521494#comment-14521494
]
Luc Maisonobe commented on MATH-1143:
-
OK. You may have a look at the JacobianMatrices class in the ode package that
allows integrating the variational equations
if your derivatives are computed with respect to either the initial state or
some model parameters. But even if you use this,
you will not directly get a DerivativeStructure and you will have to build it
afterwards.
So I guess you example is almost the helper function you need. Perhaps we could
rework it as follows:
{code}
UnivariateDifferentiableFunction buildDifferentiable(final UnivariateFunction
f, final UnivariateVectorFunction gradient) {
return new UnivariateDifferentiableFunction() {
public double value(final double x) {
return f.value(x);
}
public DerivativeStructure value(final DerivativeStructure t) {
if (t.getOrder() > 1) {
throw new NumberIsTooLargeException(t.getOrder(), 1, true);
}
double y = f.value(x);
double[] dy = gradient.value(x);
double[] packed = new double[dy.length + 1];
packed[0] = y;
System.arraycopy(dy, 0, packed, 1, dy.length);
return new DerivativeStructure(dy.length, 1, packed);
}
};
}
{code}
> Helper methods to FiniteDifferencesDifferentiator
> -
>
> Key: MATH-1143
> URL: https://issues.apache.org/jira/browse/MATH-1143
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Alexander Nozik
>Priority: Trivial
>
> A DerivativeStructure and UnivariateDifferentiableFunction are great tools if
> one needs to investigate the whole function but are not convenient if one
> just needs derivative in a given point.
> Perhaps you could add some helper methods to FiniteDifferencesDifferentiator
> or to utility class like FunctionUtils. Also it would be good to have helper
> methods to get the derivatives of UnivariateDifferentiableFunction or
> MultivariateDifferentiableFunction as simple Univariate or Multivariate
> functions (or vector-functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[ https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521457#comment-14521457 ] Alexander Nozik commented on MATH-1143: --- I do try to use DerivativeStructure in case it is not supposed to cover, but problem is that it is not always possible to present my function in the form of primitive operations composition. In my case the function is produced via numerical integration. For now Commons Math gives only two possibilities: work without derivatives at all or work with DerivativeStructure. So I am trying to do the later and not to reinvent the wheel. > Helper methods to FiniteDifferencesDifferentiator > - > > Key: MATH-1143 > URL: https://issues.apache.org/jira/browse/MATH-1143 > Project: Commons Math > Issue Type: Improvement >Reporter: Alexander Nozik >Priority: Trivial > > A DerivativeStructure and UnivariateDifferentiableFunction are great tools if > one needs to investigate the whole function but are not convenient if one > just needs derivative in a given point. > Perhaps you could add some helper methods to FiniteDifferencesDifferentiator > or to utility class like FunctionUtils. Also it would be good to have helper > methods to get the derivatives of UnivariateDifferentiableFunction or > MultivariateDifferentiableFunction as simple Univariate or Multivariate > functions (or vector-functions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[
https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521431#comment-14521431
]
Luc Maisonobe commented on MATH-1143:
-
{quote}
I am not sure I understand, how this constructor works. It seems that it
defines derivatives in the fixed point.
{quote}
Yes. A DerivativeStructure instance is just one set of values, just like a
double which would hold a value f(x). If you want to have f(x) for several x
values, you create as many double as you want, this is the same for
DerivativeStructure, you create one instance for each x value.
Your example to create a function is almost good. It just misses one point: you
don't use the derivatives of ds itself, only its value. This may be fine if you
are sure ds is already your canonical variable, but it would not work if your
function is the last step of a composition. The DerivativeStructure class has
been created to handle the second case, which explains why it seems overkill in
simpler cases.
In fact, in your case you seem to already do separately the computation of the
derivatives with separate code, using your someDerivativeCalculationHere
function. This is the kind of things DerivativesStructure could do for you. In
fact, as long as you have a way to implement "someOperationHere" using only
Java (i.e. with primitive operations, Math/FastMath/StrictMath functions and
even calls to intermediate functions, then you can reimplement it so it
directly computes the derivatives at the same time and most importantly at any
order, without requiring you to find the expression for the derivatives. This
is the essence of automatic differentiation. There is even the Apache Commons
Nable project (unfortunately not fully functional) that could do this for you,
i.e. you give it a UnivariateFunction and it creates the corresponding
UnivariateDifferentiableFunction automatically.
What you seem to ask here is for something different: you already have the
function and derivatives available, but probably only at the order at which you
did code them. Then if you want to put the result in a DerivativeStructure
instance, the class simply acts as a container for the values, and serves no
other purpose. Then of course it seems complicated for just doing this.
> Helper methods to FiniteDifferencesDifferentiator
> -
>
> Key: MATH-1143
> URL: https://issues.apache.org/jira/browse/MATH-1143
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Alexander Nozik
>Priority: Trivial
>
> A DerivativeStructure and UnivariateDifferentiableFunction are great tools if
> one needs to investigate the whole function but are not convenient if one
> just needs derivative in a given point.
> Perhaps you could add some helper methods to FiniteDifferencesDifferentiator
> or to utility class like FunctionUtils. Also it would be good to have helper
> methods to get the derivatives of UnivariateDifferentiableFunction or
> MultivariateDifferentiableFunction as simple Univariate or Multivariate
> functions (or vector-functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[
https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521411#comment-14521411
]
Alexander Nozik edited comment on MATH-1143 at 4/30/15 12:21 PM:
-
I am not sure I understand, how this constructor works. It seems that it
defines derivatives in the fixed point. How can I define a function for which I
know value and first derivative in any given point? Something like that?
{code}
UnivariateDifferentiableFunction f = (DerivativeStructure ds) -> {
double val = someOerationHere(ds.value);
double deriv = someDerivativeCalculationHere(ds.value)
return new DerivativeStructure(1, 1, val, deriv);
};
{code}
Anyway, it seems a bit complicated construct. I think it would be better to
create some kind of helper class (say DifferentiableFuncitonBuilder), in which
on could set function and its derivatives separately. Later one can add some
pretty fancy functionality like building function from String representation.
was (Author: darksnake):
I am not sure I understand, how this constructor works. It seems that it
defines derivatives in the fixed point. How can I define a function for which I
know value and first derivative in any given point? Something like that?
{code}
UnivariateFunction f = (DerivativeStructure ds) -> {
double val = someOerationHere(ds.value);
double deriv = someDerivativeCalculationHere(ds.value)
return new DerivativeStructure(1, 1, val, deriv);
};
{code}
Anyway, it seems a bit complicated construct. I think it would be better to
create some kind of helper class (say DifferentiableFuncitonBuilder), in which
on could set function and its derivatives separately. Later one can add some
pretty fancy functionality like building function from String representation.
> Helper methods to FiniteDifferencesDifferentiator
> -
>
> Key: MATH-1143
> URL: https://issues.apache.org/jira/browse/MATH-1143
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Alexander Nozik
>Priority: Trivial
>
> A DerivativeStructure and UnivariateDifferentiableFunction are great tools if
> one needs to investigate the whole function but are not convenient if one
> just needs derivative in a given point.
> Perhaps you could add some helper methods to FiniteDifferencesDifferentiator
> or to utility class like FunctionUtils. Also it would be good to have helper
> methods to get the derivatives of UnivariateDifferentiableFunction or
> MultivariateDifferentiableFunction as simple Univariate or Multivariate
> functions (or vector-functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[
https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521411#comment-14521411
]
Alexander Nozik commented on MATH-1143:
---
I am not sure I understand, how this constructor works. It seems that it
defines derivatives in the fixed point. How can I define a function for which I
know value and first derivative in any given point? Something like that?
{code}
UnivariateFunction f = (DerivativeStructure ds) -> {
double val = someOerationHere(ds.value);
double deriv = someDerivativeCalculationHere(ds.value)
return new DerivativeStructure(1, 1, val, deriv);
};
{code}
Anyway, it seems a bit complicated construct. I think it would be better to
create some kind of helper class (say DifferentiableFuncitonBuilder), in which
on could set function and its derivatives separately. Later one can add some
pretty fancy functionality like building function from String representation.
> Helper methods to FiniteDifferencesDifferentiator
> -
>
> Key: MATH-1143
> URL: https://issues.apache.org/jira/browse/MATH-1143
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Alexander Nozik
>Priority: Trivial
>
> A DerivativeStructure and UnivariateDifferentiableFunction are great tools if
> one needs to investigate the whole function but are not convenient if one
> just needs derivative in a given point.
> Perhaps you could add some helper methods to FiniteDifferencesDifferentiator
> or to utility class like FunctionUtils. Also it would be good to have helper
> methods to get the derivatives of UnivariateDifferentiableFunction or
> MultivariateDifferentiableFunction as simple Univariate or Multivariate
> functions (or vector-functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBUTILS-125) Using Oracle OJDBC7 gives ORA-00933
[ https://issues.apache.org/jira/browse/DBUTILS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521366#comment-14521366 ] EMR commented on DBUTILS-125: - Some background on troubleshooting i've done: I am accessing a view and/or tables as other schemas (users). My intended account is read-only, but I have used other accounts in troubleshooting. The url is of the format: "jdbc:oracle:thin:@mydbserver.example.com:1521/MYTNSDB" I am doing a ds.setUser() and ds.setPassword() I have changed my username to the same user/schema as the table... to no avail. I have added the username before the "@" to no avail. I have made sure that the views and tables are accessible via SQLDeveloper (from Oracle) from both users. Notably, they use the v11 driver for their app. I will be testing later today with dropping in the v12 driver in the app itself to see (confirm) dbutils issue or native java issue. The original query used COALESCE() which gave the ORA-00933, but now, since I created the view on the server (using the exact same query, so there's nothing wrong with it) I am doing a "select distinct *" which is giving the ORA-00942 (table or view does not exist). Note that, as noted previously, using the native JDBC calls work fine, and data is returned as expected. All of this works with the v11 drivers, but not the v12 drivers. > Using Oracle OJDBC7 gives ORA-00933 > --- > > Key: DBUTILS-125 > URL: https://issues.apache.org/jira/browse/DBUTILS-125 > Project: Commons DbUtils > Issue Type: Bug >Affects Versions: 1.6 > Environment: JDBC driver version is 12.1.0.1.0 >Reporter: EMR >Priority: Minor > > Attempting to run an sql query with the latest version of the drivers, it > fails with ERROR (JavaApplication33.java:107) - ORA-00933: SQL command not > properly ended. > However, if I revert to the 11 version of the driver, the query works fine. > Is there a setting that I am missing between the two versions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DBCP-438) Nested connections in a transaction (local) throws null pointer
[
https://issues.apache.org/jira/browse/DBCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521293#comment-14521293
]
Raihan Kibria edited comment on DBCP-438 at 4/30/15 11:26 AM:
--
This stack trace is from version 2.1
was (Author: raihan):
This stack trace is from version 2.2.0.1
> Nested connections in a transaction (local) throws null pointer
> ---
>
> Key: DBCP-438
> URL: https://issues.apache.org/jira/browse/DBCP-438
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: All (linux, aix, windows)
>Reporter: Raihan Kibria
> Attachments: TestManagedDataSourceInNesetedConnTx.java, dbcpNull.png
>
>
> In a transaction context, if we open multiple connections and close each of
> them after commit, we get a null pointer exception. Sample code:
> transactionManager.begin();
>
> Connection c1 = null;
> Connection c2 = null;
>
> c1 = newConnection();
> c2 = newConnection();
>
> transactionManager.commit();
>
> try{
> c1.close();
> }catch(Exception e){
> e.printStackTrace();
> }
>
> try{
> c2.close();
> }catch(Exception e){
> //throws execption
> e.printStackTrace();
> }
> Null pointer is thrown at:
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal
> Affects versions-- 2.1, 2.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-438) Nested connections in a transaction (local) throws null pointer
[
https://issues.apache.org/jira/browse/DBCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raihan Kibria updated DBCP-438:
---
Description:
In a transaction context, if we open multiple connections and close each of
them after commit, we get a null pointer exception. Sample code:
transactionManager.begin();
Connection c1 = null;
Connection c2 = null;
c1 = newConnection();
c2 = newConnection();
transactionManager.commit();
try{
c1.close();
}catch(Exception e){
e.printStackTrace();
}
try{
c2.close();
}catch(Exception e){
//throws execption
e.printStackTrace();
}
Null pointer is thrown at:
org.apache.commons.dbcp2.DelegatingConnection.closeInternal
Affects versions-- 2.1, 2.0
was:
In a transaction context, if we open multiple connections and close each of
them after commit, we get a null pointer exception. Sample code:
transactionManager.begin();
Connection c1 = null;
Connection c2 = null;
c1 = newConnection();
c2 = newConnection();
transactionManager.commit();
try{
c1.close();
}catch(Exception e){
e.printStackTrace();
}
try{
c2.close();
}catch(Exception e){
//throws execption
e.printStackTrace();
}
Null pointer is thrown at:
org.apache.commons.dbcp2.DelegatingConnection.closeInternal
Affects versions-- 2.0.1, 2.2.01
> Nested connections in a transaction (local) throws null pointer
> ---
>
> Key: DBCP-438
> URL: https://issues.apache.org/jira/browse/DBCP-438
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: All (linux, aix, windows)
>Reporter: Raihan Kibria
> Attachments: TestManagedDataSourceInNesetedConnTx.java, dbcpNull.png
>
>
> In a transaction context, if we open multiple connections and close each of
> them after commit, we get a null pointer exception. Sample code:
> transactionManager.begin();
>
> Connection c1 = null;
> Connection c2 = null;
>
> c1 = newConnection();
> c2 = newConnection();
>
> transactionManager.commit();
>
> try{
> c1.close();
> }catch(Exception e){
> e.printStackTrace();
> }
>
> try{
> c2.close();
> }catch(Exception e){
> //throws execption
> e.printStackTrace();
> }
> Null pointer is thrown at:
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal
> Affects versions-- 2.1, 2.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[
https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521339#comment-14521339
]
Luc Maisonobe edited comment on MATH-1143 at 4/30/15 11:24 AM:
---
If you have function f(x1, x2, x3) and know both the value and the derivatives,
you can directly build the DerivativeStructure as follows:
{code}
int nbParams = 3; // index 0 will be for x1, index 1 for x2, index 2 for x3
int order = 1; // we will use only value and first order derivative
return new DerivativeStructure(nbParams, order, f, dfdx1, dfdx2, dfdx3);
{code}
As this constructor has a variable number of arguments, this example can be
generalized
to other numbers of parameters.
The order in which the derivatives should be provided is difficult to set up in
the general case
when both nbParams and order are greater than 1, but it is straightforward in
the two limit
cases (nbParams = 1, order > 1) or (nbParams > 1, order = 1). In both cases,
you just give
the derivatives in the "natural" order, which is in increasing order when you
have one parameter
and high order derivatives, and in parameters order when you have only first
order derivatives
for all parameters.
was (Author: luc):
If you have function f(x1, x2, x3) and know both the value and the derivatives,
you can directly build the DerivativeStructure as follows:
{code}
int nbParams = 3; // index 0 will be for x1, index 1 for x2, index 2 for x3
int order = 1; // we will use only value and first order derivative
return new DerivativeStructure(nbParams, order, f, dfdx1, dfdx2, dfdx3);
{code}
As this constructor as a variable number of arguments, this example can be
generalized
to other numbers of parameters.
The order in which the derivatives should be provided is difficult to set up in
the general case
when both nbParams and order are greater than 1, but it is straightforward in
the two limit
cases (nbParams = 1, order > 1) or (nbParams > 1, order = 1). In both cases,
you just give
the derivatives in the "natural" order, which is in increasing order when you
have one parameter
and high order derivatives, and in parameters order when you have only first
order derivatives
for all parameters.
> Helper methods to FiniteDifferencesDifferentiator
> -
>
> Key: MATH-1143
> URL: https://issues.apache.org/jira/browse/MATH-1143
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Alexander Nozik
>Priority: Trivial
>
> A DerivativeStructure and UnivariateDifferentiableFunction are great tools if
> one needs to investigate the whole function but are not convenient if one
> just needs derivative in a given point.
> Perhaps you could add some helper methods to FiniteDifferencesDifferentiator
> or to utility class like FunctionUtils. Also it would be good to have helper
> methods to get the derivatives of UnivariateDifferentiableFunction or
> MultivariateDifferentiableFunction as simple Univariate or Multivariate
> functions (or vector-functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[
https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521339#comment-14521339
]
Luc Maisonobe commented on MATH-1143:
-
If you have function f(x1, x2, x3) and know both the value and the derivatives,
you can directly build the DerivativeStructure as follows:
{code}
int nbParams = 3; // index 0 will be for x1, index 1 for x2, index 2 for x3
int order = 1; // we will use only value and first order derivative
return new DerivativeStructure(nbParams, order, f, dfdx1, dfdx2, dfdx3);
{code}
As this constructor as a variable number of arguments, this example can be
generalized
to other numbers of parameters.
The order in which the derivatives should be provided is difficult to set up in
the general case
when both nbParams and order are greater than 1, but it is straightforward in
the two limit
cases (nbParams = 1, order > 1) or (nbParams > 1, order = 1). In both cases,
you just give
the derivatives in the "natural" order, which is in increasing order when you
have one parameter
and high order derivatives, and in parameters order when you have only first
order derivatives
for all parameters.
> Helper methods to FiniteDifferencesDifferentiator
> -
>
> Key: MATH-1143
> URL: https://issues.apache.org/jira/browse/MATH-1143
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Alexander Nozik
>Priority: Trivial
>
> A DerivativeStructure and UnivariateDifferentiableFunction are great tools if
> one needs to investigate the whole function but are not convenient if one
> just needs derivative in a given point.
> Perhaps you could add some helper methods to FiniteDifferencesDifferentiator
> or to utility class like FunctionUtils. Also it would be good to have helper
> methods to get the derivatives of UnivariateDifferentiableFunction or
> MultivariateDifferentiableFunction as simple Univariate or Multivariate
> functions (or vector-functions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (LANG-1116) DateUtilsTest.testLang530 fails for some timezones
[
https://issues.apache.org/jira/browse/LANG-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1116:
-
Comment: was deleted
(was: >I found out that testLang530 seems to fail when you're in UTC!
Confirmed, indeed failing in UTC. Furthermore, it fails in my time zone too:
"Pacific/Auckland", and works in "America/Sao Paulo".
Isolating the code and debugging, looks like the pattern used is constant, but
the ISO 8601 string is formatted differently depending on the time zone
selected. As the example below.
{noformat}
Success parsing date [2015-04-30T09:21:17+00:00] format
[-MM-dd'T'HH:mm:ssZZ]
Failed to parse date [2015-04-30T09:21:33Z] format [-MM-dd'T'HH:mm:ssZZ]
Failed to parse date [2015-04-30T21:32:13+12:00] format
[-MM-dd'T'HH:mm:ssZZ]
{noformat}
The first value between [] has different values for "America/Sao Paulo", "UTC"
and "Pacific/Auckland" respectively. )
> DateUtilsTest.testLang530 fails for some timezones
> --
>
> Key: LANG-1116
> URL: https://issues.apache.org/jira/browse/LANG-1116
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.4
> Environment: Redhat 5 / Java8u45
>Reporter: Aaron Sheldon
> Fix For: Discussion
>
> Attachments: lang-1116.patch, lang-1116.patch
>
>
> Unit test for testLang530 fails when the isoDateStr comes out with just a Z
> instead of +00:00.
> {code}
> Tests run: 38, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.014 sec
> <<< FAILURE! - in org.apache.commons.lang3.time.DateUtilsTest
> testLang530(org.apache.commons.lang3.time.DateUtilsTest) Time elapsed: 0.005
> sec <<< ERROR!
> java.text.ParseException: Unable to parse the date: 2015-04-17T18:51:52Z
> at
> org.apache.commons.lang3.time.DateUtils.parseDateWithLeniency(DateUtils.java:401)
> at
> org.apache.commons.lang3.time.DateUtils.parseDate(DateUtils.java:301)
> at
> org.apache.commons.lang3.time.DateUtils.parseDate(DateUtils.java:278)
> at
> org.apache.commons.lang3.time.DateUtilsTest.testLang530(DateUtilsTest.java:1222)
> {code}
> On a Linux machine where this test passes, isoDateStr is
> 2015-04-17T19:26:03+00:00.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1116) DateUtilsTest.testLang530 fails for some timezones
[
https://issues.apache.org/jira/browse/LANG-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521325#comment-14521325
]
Bruno P. Kinoshita commented on LANG-1116:
--
>I found out that testLang530 seems to fail when you're in UTC!
Confirmed, indeed failing in UTC. Furthermore, it fails in my time zone too:
"Pacific/Auckland", and works in "America/Sao Paulo".
Isolating the code and debugging, looks like the pattern used is constant, but
the ISO 8601 string is formatted differently depending on the time zone
selected. As the example below.
{noformat}
Success parsing date [2015-04-30T09:21:17+00:00] format
[-MM-dd'T'HH:mm:ssZZ]
Failed to parse date [2015-04-30T09:21:33Z] format [-MM-dd'T'HH:mm:ssZZ]
Failed to parse date [2015-04-30T21:32:13+12:00] format
[-MM-dd'T'HH:mm:ssZZ]
{noformat}
The first value between [] has different values for "America/Sao Paulo", "UTC"
and "Pacific/Auckland" respectively.
> DateUtilsTest.testLang530 fails for some timezones
> --
>
> Key: LANG-1116
> URL: https://issues.apache.org/jira/browse/LANG-1116
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.4
> Environment: Redhat 5 / Java8u45
>Reporter: Aaron Sheldon
> Fix For: Discussion
>
> Attachments: lang-1116.patch, lang-1116.patch
>
>
> Unit test for testLang530 fails when the isoDateStr comes out with just a Z
> instead of +00:00.
> {code}
> Tests run: 38, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.014 sec
> <<< FAILURE! - in org.apache.commons.lang3.time.DateUtilsTest
> testLang530(org.apache.commons.lang3.time.DateUtilsTest) Time elapsed: 0.005
> sec <<< ERROR!
> java.text.ParseException: Unable to parse the date: 2015-04-17T18:51:52Z
> at
> org.apache.commons.lang3.time.DateUtils.parseDateWithLeniency(DateUtils.java:401)
> at
> org.apache.commons.lang3.time.DateUtils.parseDate(DateUtils.java:301)
> at
> org.apache.commons.lang3.time.DateUtils.parseDate(DateUtils.java:278)
> at
> org.apache.commons.lang3.time.DateUtilsTest.testLang530(DateUtilsTest.java:1222)
> {code}
> On a Linux machine where this test passes, isoDateStr is
> 2015-04-17T19:26:03+00:00.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBCP-438) Nested connections in a transaction (local) throws null pointer
[
https://issues.apache.org/jira/browse/DBCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521304#comment-14521304
]
Adrian Crum commented on DBCP-438:
--
We are having a similar problem in OFBiz:
https://issues.apache.org/jira/browse/OFBIZ-6218
DBCP 2 v 2.1
> Nested connections in a transaction (local) throws null pointer
> ---
>
> Key: DBCP-438
> URL: https://issues.apache.org/jira/browse/DBCP-438
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: All (linux, aix, windows)
>Reporter: Raihan Kibria
> Attachments: TestManagedDataSourceInNesetedConnTx.java, dbcpNull.png
>
>
> In a transaction context, if we open multiple connections and close each of
> them after commit, we get a null pointer exception. Sample code:
> transactionManager.begin();
>
> Connection c1 = null;
> Connection c2 = null;
>
> c1 = newConnection();
> c2 = newConnection();
>
> transactionManager.commit();
>
> try{
> c1.close();
> }catch(Exception e){
> e.printStackTrace();
> }
>
> try{
> c2.close();
> }catch(Exception e){
> //throws execption
> e.printStackTrace();
> }
> Null pointer is thrown at:
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal
> Affects versions-- 2.0.1, 2.2.01
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-438) Nested connections in a transaction (local) throws null pointer
[
https://issues.apache.org/jira/browse/DBCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raihan Kibria updated DBCP-438:
---
Attachment: dbcpNull.png
This stack trace is from version 2.2.0.1
> Nested connections in a transaction (local) throws null pointer
> ---
>
> Key: DBCP-438
> URL: https://issues.apache.org/jira/browse/DBCP-438
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: All (linux, aix, windows)
>Reporter: Raihan Kibria
> Attachments: TestManagedDataSourceInNesetedConnTx.java, dbcpNull.png
>
>
> In a transaction context, if we open multiple connections and close each of
> them after commit, we get a null pointer exception. Sample code:
> transactionManager.begin();
>
> Connection c1 = null;
> Connection c2 = null;
>
> c1 = newConnection();
> c2 = newConnection();
>
> transactionManager.commit();
>
> try{
> c1.close();
> }catch(Exception e){
> e.printStackTrace();
> }
>
> try{
> c2.close();
> }catch(Exception e){
> //throws execption
> e.printStackTrace();
> }
> Null pointer is thrown at:
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal
> Affects versions-- 2.0.1, 2.2.01
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-438) Nested connections in a transaction (local) throws null pointer
[
https://issues.apache.org/jira/browse/DBCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raihan Kibria updated DBCP-438:
---
Description:
In a transaction context, if we open multiple connections and close each of
them after commit, we get a null pointer exception. Sample code:
transactionManager.begin();
Connection c1 = null;
Connection c2 = null;
c1 = newConnection();
c2 = newConnection();
transactionManager.commit();
try{
c1.close();
}catch(Exception e){
e.printStackTrace();
}
try{
c2.close();
}catch(Exception e){
//throws execption
e.printStackTrace();
}
Null pointer is thrown at:
org.apache.commons.dbcp2.DelegatingConnection.closeInternal
Affects versions-- 2.0.1, 2.2.01
was:
In a transaction context, if we open multiple connections and close each of
them after commit, we get a null pointer exception. Sample code:
transactionManager.begin();
Connection c1 = null;
Connection c2 = null;
c1 = newConnection();
c2 = newConnection();
transactionManager.commit();
try{
c1.close();
}catch(Exception e){
e.printStackTrace();
}
try{
c2.close();
}catch(Exception e){
//throws execption
e.printStackTrace();
}
Null pointer is thrown at:
org.apache.commons.dbcp2.DelegatingConnection.closeInternal
> Nested connections in a transaction (local) throws null pointer
> ---
>
> Key: DBCP-438
> URL: https://issues.apache.org/jira/browse/DBCP-438
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: All (linux, aix, windows)
>Reporter: Raihan Kibria
> Attachments: TestManagedDataSourceInNesetedConnTx.java
>
>
> In a transaction context, if we open multiple connections and close each of
> them after commit, we get a null pointer exception. Sample code:
> transactionManager.begin();
>
> Connection c1 = null;
> Connection c2 = null;
>
> c1 = newConnection();
> c2 = newConnection();
>
> transactionManager.commit();
>
> try{
> c1.close();
> }catch(Exception e){
> e.printStackTrace();
> }
>
> try{
> c2.close();
> }catch(Exception e){
> //throws execption
> e.printStackTrace();
> }
> Null pointer is thrown at:
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal
> Affects versions-- 2.0.1, 2.2.01
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-438) Nested connections in a transaction (local) throws null pointer
[
https://issues.apache.org/jira/browse/DBCP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raihan Kibria updated DBCP-438:
---
Attachment: TestManagedDataSourceInNesetedConnTx.java
The file can be tested as it is in maven test;
location:
src\test\java\org\apache\commons\dbcp2\managed
In the console you will see the null pointer exception stacktrace.
> Nested connections in a transaction (local) throws null pointer
> ---
>
> Key: DBCP-438
> URL: https://issues.apache.org/jira/browse/DBCP-438
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: All (linux, aix, windows)
>Reporter: Raihan Kibria
> Attachments: TestManagedDataSourceInNesetedConnTx.java
>
>
> In a transaction context, if we open multiple connections and close each of
> them after commit, we get a null pointer exception. Sample code:
> transactionManager.begin();
>
> Connection c1 = null;
> Connection c2 = null;
>
> c1 = newConnection();
> c2 = newConnection();
>
> transactionManager.commit();
>
> try{
> c1.close();
> }catch(Exception e){
> e.printStackTrace();
> }
>
> try{
> c2.close();
> }catch(Exception e){
> //throws execption
> e.printStackTrace();
> }
> Null pointer is thrown at:
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DBCP-438) Nested connections in a transaction (local) throws null pointer
Raihan Kibria created DBCP-438:
--
Summary: Nested connections in a transaction (local) throws null
pointer
Key: DBCP-438
URL: https://issues.apache.org/jira/browse/DBCP-438
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.1
Environment: All (linux, aix, windows)
Reporter: Raihan Kibria
In a transaction context, if we open multiple connections and close each of
them after commit, we get a null pointer exception. Sample code:
transactionManager.begin();
Connection c1 = null;
Connection c2 = null;
c1 = newConnection();
c2 = newConnection();
transactionManager.commit();
try{
c1.close();
}catch(Exception e){
e.printStackTrace();
}
try{
c2.close();
}catch(Exception e){
//throws execption
e.printStackTrace();
}
Null pointer is thrown at:
org.apache.commons.dbcp2.DelegatingConnection.closeInternal
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1124) Add split by length methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521269#comment-14521269
]
ASF GitHub Bot commented on LANG-1124:
--
Github user coveralls commented on the pull request:
https://github.com/apache/commons-lang/pull/75#issuecomment-97729139
[](https://coveralls.io/builds/2456530)
Coverage increased (+0.03%) to 93.36% when pulling
**7133787f58254bdb3cb4ff3a37eda0138745aa8d on rikles:fix-LANG-1124** into
**f431270c59b6d4558da8dff625a7738591a0d541 on apache:master**.
> Add split by length methods in StringUtils
> --
>
> Key: LANG-1124
> URL: https://issues.apache.org/jira/browse/LANG-1124
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Loic Guibert
>
> Add methods to split a String by fixed lengths :
> {code:java}
> public static String[] splitByLength(String str, int ... lengths);
> public static String[] splitByLengthRepeatedly(String str, int ... lengths);
> {code}
> Detail :
> {code:java}
> /**
> * Split a String into an array, using an array of fixed string
> lengths.
> *
> * If not null String input, the returned array size is same as the input
> lengths array.
> *
> * A null input String returns {@code null}.
> * A {@code null} or empty input lengths array returns an empty array.
> * A {@code 0} in the input lengths array results in en empty string.
> *
> * Extra characters are ignored (ie String length greater than sum of
> split lengths).
> * All empty substrings other than zero length requested, are returned {@code
> null}.
> *
> *
> * StringUtils.splitByLength(null, *) = null
> * StringUtils.splitByLength("abc")= []
> * StringUtils.splitByLength("abc", null) = []
> * StringUtils.splitByLength("abc", [])= []
> * StringUtils.splitByLength("", 2, 4, 1) = [null, null, null]
> *
> * StringUtils.splitByLength("abcdefg", 2, 4, 1) = ["ab", "cdef", "g"]
> * StringUtils.splitByLength("abcdefghij", 2, 4, 1) = ["ab", "cdef", "g"]
> * StringUtils.splitByLength("abcdefg", 2, 4, 5) = ["ab", "cdef", "g"]
> * StringUtils.splitByLength("abcdef", 2, 4, 1) = ["ab", "cdef", null]
> *
> * StringUtils.splitByLength(" abcdef", 2, 4, 1) = [" a", "bcde", "f"]
> * StringUtils.splitByLength("abcdef ", 2, 4, 1) = ["ab", "cdef", " "]
> * StringUtils.splitByLength("abcdefg", 2, 4, 0, 1) = ["ab", "cdef", "", "g"]
> * StringUtils.splitByLength("abcdefg", -1) = {@link
> IllegalArgumentException}
> *
> *
> * @param str the String to parse, may be null
> * @param lengths the string lengths where to cut, may be null, must not be
> negative
> * @return an array of splitted Strings, {@code null} if null String input
> * @throws IllegalArgumentException
> * if one of the lengths is negative
> */
> public static String[] splitByLength(String str, int ... lengths);
> /**
> * Split a String into an array, using an array of fixed string lengths
> repeated as
> * many times as necessary to reach the String end.
> *
> * If not null String input, the returned array size is a multiple of the
> input lengths array.
> *
> * A null input String returns {@code null}.
> * A {@code null} or empty input lengths array returns an empty array.
> * A {@code 0} in the input lengths array results in en empty string.
> *
> * All empty substrings other than zero length requested and following
> substrings,
> * are returned {@code null}.
> *
> *
> * StringUtils.splitByLengthRepeated(null, *) = null
> * StringUtils.splitByLengthRepeated("abc")= []
> * StringUtils.splitByLengthRepeated("abc", null) = []
> * StringUtils.splitByLengthRepeated("abc", [])= []
> * StringUtils.splitByLengthRepeated("", 2, 4, 1) = [null, null, null]
> *
> * StringUtils.splitByLengthRepeated("abcdefghij", 2, 3) = ["ab", "cde",
> "fg", "hij"]
> * StringUtils.splitByLengthRepeated("abcdefgh", 2, 3) = ["ab", "cde",
> "fg", "h"]
> * StringUtils.splitByLengthRepeated("abcdefg", 2, 3)= ["ab", "cde",
> "fg", null]
> *
> * StringUtils.splitByLengthRepeated(" abcdef", 2, 3)= [" a", "bcd",
> "ef", null]
> * StringUtils.splitByLengthRepeated("abcdef ", 2, 3)= ["ab", "cde",
> "f ", null]
> * StringUtils.splitByLengthRepeated("abcdef", 2, 3, 0, 1) = ["ab", "cde",
> "", "f"]
> * StringUtils.splitByLengthRepeated("abcdefg", 2, 3, 0, 1) = ["ab", "cde",
> "", "f",
> * "g", null,
> null, null]
> * StringUtils.splitByLengthRepeated("abcdefgh", 2, 0, 1, 0) = ["ab", "",
> "c", "",
> * "de", "",
> "f", "",
> *
[jira] [Commented] (CLI-249) Message for an illegal character in an option should contain more information
[ https://issues.apache.org/jira/browse/CLI-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521243#comment-14521243 ] David Goodenough commented on CLI-249: -- When I originally looked at this there were two messages, and I must have looked at an old version as the second (multi character) version did not put in the whole message. And yes the exception will gain nothing by repeating the offending character. However the point remains, that the message contains almost no information that is useful to the user of any packages using this code in working out what needs fixing. Now it could be argued that actually the caller should trap this error and put in some more context, but at a minimum this should be documented, and in real life is not going to happen. Perhaps the current API should be deprecated and a new method added that required a string providing that context be supplied - but that would cause outcry in the callers as they would have the change all their code. The bottom line is that the current except is really not useful to its likely audience and somehow this needs fixing. > Message for an illegal character in an option should contain more information > - > > Key: CLI-249 > URL: https://issues.apache.org/jira/browse/CLI-249 > Project: Commons CLI > Issue Type: Improvement > Components: CLI-1.x >Reporter: David Goodenough > Fix For: 1.3 > > > Currently the code in org.apache.commons.cli.OptionValidator generates an > IllegalArgumentException which contains the message:- > "illegal option value '" + ch + "'" > This is generated in two places, one for single character options and one for > multi character options. > However this does not tell the caller which option it is contains this > character, which makes debugging the error without the source (i.e most > users) extremely difficult. > Would it not be possible to change the message to:- > "illegal option '" + opt + "' value '" + ch + "'" > which would then at least identify the offending option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1122) Inconsistent behavior of swap for malformed inputs
[ https://issues.apache.org/jira/browse/LANG-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521148#comment-14521148 ] Adrian Ber commented on LANG-1122: -- I guess start is the start of first block (in swap methods - offset1), end is the start of second block (in swap methods - offset2) and offset is the length of block to swap (in swap methods - len). For case 1, 2, 3, 4, 5, 7, 8 I propose to result in no op. For case 6, it actually doesn't matter which block is first. For case 9 and 10 - what do you think it should happen with swap([1, 2, 3, 4, 5], 0, 3, 3)? It should result in no op or it should result in [4, 5, 3, 1, 2], meaning that it will swap as many as possible? I would incline to go for the latter. > Inconsistent behavior of swap for malformed inputs > -- > > Key: LANG-1122 > URL: https://issues.apache.org/jira/browse/LANG-1122 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Benedikt Ritter > Fix For: Patch Needed, 3.5 > > > Following the discussion at https://github.com/apache/commons-lang/pull/47 we > need to decide how malformed inputs should be handled by the swap method. We > have to handle several forms of malformed inputs and we should decide how to > do that based on the current behavior of ArrayUtils. Malformed inputs are: > * array == null > * array.length == 0 > * start < 0 > * end < 0 > * offset < 0 > * start > end > * start > array.length > * end > array.length > * start + offset > array.length > * end + offset > array.length -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1124) Add split by length methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Loic Guibert updated LANG-1124:
---
Description:
Add methods to split a String by fixed lengths :
{code:java}
public static String[] splitByLength(String str, int ... lengths);
public static String[] splitByLengthRepeatedly(String str, int ... lengths);
{code}
Detail :
{code:java}
/**
* Split a String into an array, using an array of fixed string lengths.
*
* If not null String input, the returned array size is same as the input
lengths array.
*
* A null input String returns {@code null}.
* A {@code null} or empty input lengths array returns an empty array.
* A {@code 0} in the input lengths array results in en empty string.
*
* Extra characters are ignored (ie String length greater than sum of split
lengths).
* All empty substrings other than zero length requested, are returned {@code
null}.
*
*
* StringUtils.splitByLength(null, *) = null
* StringUtils.splitByLength("abc")= []
* StringUtils.splitByLength("abc", null) = []
* StringUtils.splitByLength("abc", [])= []
* StringUtils.splitByLength("", 2, 4, 1) = [null, null, null]
*
* StringUtils.splitByLength("abcdefg", 2, 4, 1) = ["ab", "cdef", "g"]
* StringUtils.splitByLength("abcdefghij", 2, 4, 1) = ["ab", "cdef", "g"]
* StringUtils.splitByLength("abcdefg", 2, 4, 5) = ["ab", "cdef", "g"]
* StringUtils.splitByLength("abcdef", 2, 4, 1) = ["ab", "cdef", null]
*
* StringUtils.splitByLength(" abcdef", 2, 4, 1) = [" a", "bcde", "f"]
* StringUtils.splitByLength("abcdef ", 2, 4, 1) = ["ab", "cdef", " "]
* StringUtils.splitByLength("abcdefg", 2, 4, 0, 1) = ["ab", "cdef", "", "g"]
* StringUtils.splitByLength("abcdefg", -1) = {@link
IllegalArgumentException}
*
*
* @param str the String to parse, may be null
* @param lengths the string lengths where to cut, may be null, must not be
negative
* @return an array of splitted Strings, {@code null} if null String input
* @throws IllegalArgumentException
* if one of the lengths is negative
*/
public static String[] splitByLength(String str, int ... lengths);
/**
* Split a String into an array, using an array of fixed string lengths
repeated as
* many times as necessary to reach the String end.
*
* If not null String input, the returned array size is a multiple of the
input lengths array.
*
* A null input String returns {@code null}.
* A {@code null} or empty input lengths array returns an empty array.
* A {@code 0} in the input lengths array results in en empty string.
*
* All empty substrings other than zero length requested and following
substrings,
* are returned {@code null}.
*
*
* StringUtils.splitByLengthRepeated(null, *) = null
* StringUtils.splitByLengthRepeated("abc")= []
* StringUtils.splitByLengthRepeated("abc", null) = []
* StringUtils.splitByLengthRepeated("abc", [])= []
* StringUtils.splitByLengthRepeated("", 2, 4, 1) = [null, null, null]
*
* StringUtils.splitByLengthRepeated("abcdefghij", 2, 3) = ["ab", "cde",
"fg", "hij"]
* StringUtils.splitByLengthRepeated("abcdefgh", 2, 3) = ["ab", "cde",
"fg", "h"]
* StringUtils.splitByLengthRepeated("abcdefg", 2, 3)= ["ab", "cde",
"fg", null]
*
* StringUtils.splitByLengthRepeated(" abcdef", 2, 3)= [" a", "bcd",
"ef", null]
* StringUtils.splitByLengthRepeated("abcdef ", 2, 3)= ["ab", "cde", "f
", null]
* StringUtils.splitByLengthRepeated("abcdef", 2, 3, 0, 1) = ["ab", "cde",
"", "f"]
* StringUtils.splitByLengthRepeated("abcdefg", 2, 3, 0, 1) = ["ab", "cde",
"", "f",
* "g", null,
null, null]
* StringUtils.splitByLengthRepeated("abcdefgh", 2, 0, 1, 0) = ["ab", "", "c",
"",
* "de", "", "f",
"",
* "gh", "", null,
null]
* StringUtils.splitByLengthRepeated("abcdefg", 2, 0, 1, 0) = ["ab", "", "c",
"",
* "de", "", "f",
"",
* "g", null,
null, null]
* StringUtils.splitByLengthRepeated("abcdefg", -1) = {@link
IllegalArgumentException}
* StringUtils.splitByLengthRepeated("abcdefg", 0, 0)= {@link
IllegalArgumentException}
*
*
* @param str the String to parse, may be null
* @param lengths the string lengths where to cut, may be null, must not be
negative
* @return an array of splitted Strings, {@code null} if null String input
* @throws IllegalArgumentException
* if one of the lengths is negative or if lengths sum is less than
1
*/
public static String[] splitByLengthRepeatedly(String str, int... lengths);
{code}
See PR #75 : https://github.com/apache/commons-lang/pull/7
[jira] [Commented] (LANG-1124) Add split by length methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521137#comment-14521137
]
ASF GitHub Bot commented on LANG-1124:
--
GitHub user rikles opened a pull request:
https://github.com/apache/commons-lang/pull/75
LANG-1124: Add StringUtils split by length methods
Add methods to split a String by fixed lengths :
```java
public static String[] splitByLength(String str, int ... lengths);
public static String[] splitByLengthRepeatedly(String str, int ... lengths);
```
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rikles/commons-lang fix-LANG-1124
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-lang/pull/75.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #75
commit 029b1c2f99369f1e2fa1e5230bed9e44be819189
Author: Loic Guibert
Date: 2015-04-30T08:24:44Z
LANG-1124: Add StringUtils split by length methods
> Add split by length methods in StringUtils
> --
>
> Key: LANG-1124
> URL: https://issues.apache.org/jira/browse/LANG-1124
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Loic Guibert
>
> Add methods to split a String by fixed lengths :
> {code:java}
> public static String[] splitByLength(String str, int ... lengths);
> public static String[] splitByLengthRepeatedly(String str, int ... lengths);
> {code}
> Detail :
> {code:java}
> /**
> * Split a String into an array, using an array of fixed string
> lengths.
> *
> * If not null String input, the returned array size is same as the input
> lengths array.
> *
> * A null input String returns {@code null}.
> * A {@code null} or empty input lengths array returns an empty array.
> * A {@code 0} in the input lengths array results in en empty string.
> *
> * Extra characters are ignored (ie String length greater than sum of
> split lengths).
> * All empty substrings other than zero length requested, are returned {@code
> null}.
> *
> *
> * StringUtils.splitByLength(null, *) = null
> * StringUtils.splitByLength("abc")= []
> * StringUtils.splitByLength("abc", null) = []
> * StringUtils.splitByLength("abc", [])= []
> * StringUtils.splitByLength("", 2, 4, 1) = [null, null, null]
> *
> * StringUtils.splitByLength("abcdefg", 2, 4, 1) = ["ab", "cdef", "g"]
> * StringUtils.splitByLength("abcdefghij", 2, 4, 1) = ["ab", "cdef", "g"]
> * StringUtils.splitByLength("abcdefg", 2, 4, 5) = ["ab", "cdef", "g"]
> * StringUtils.splitByLength("abcdef", 2, 4, 1) = ["ab", "cdef", null]
> *
> * StringUtils.splitByLength(" abcdef", 2, 4, 1) = [" a", "bcde", "f"]
> * StringUtils.splitByLength("abcdef ", 2, 4, 1) = ["ab", "cdef", " "]
> * StringUtils.splitByLength("abcdefg", 2, 4, 0, 1) = ["ab", "cdef", "", "g"]
> * StringUtils.splitByLength("abcdefg", -1) = {@link
> IllegalArgumentException}
> *
> *
> * @param str the String to parse, may be null
> * @param lengths the string lengths where to cut, may be null, must not be
> negative
> * @return an array of splitted Strings, {@code null} if null String input
> * @throws IllegalArgumentException
> * if one of the lengths is negative
> */
> public static String[] splitByLength(String str, int ... lengths);
> /**
> * Split a String into an array, using an array of fixed string lengths
> repeated as
> * many times as necessary to reach the String end.
> *
> * If not null String input, the returned array size is a multiple of the
> input lengths array.
> *
> * A null input String returns {@code null}.
> * A {@code null} or empty input lengths array returns an empty array.
> * A {@code 0} in the input lengths array results in en empty string.
> *
> * All empty substrings other than zero length requested and following
> substrings,
> * are returned {@code null}.
> *
> *
> * StringUtils.splitByLengthRepeated(null, *) = null
> * StringUtils.splitByLengthRepeated("abc")= []
> * StringUtils.splitByLengthRepeated("abc", null) = []
> * StringUtils.splitByLengthRepeated("abc", [])= []
> * StringUtils.splitByLengthRepeated("", 2, 4, 1) = [null, null, null]
> *
> * StringUtils.splitByLengthRepeated("abcdefghij", 2, 3) = ["ab", "cde",
> "fg", "hij"]
> * StringUtils.splitByLengthRepeated("abcdefgh", 2, 3) = ["ab", "cde",
> "fg", "h"]
> * StringUtils.splitByLengthRepeated("abcdefg", 2, 3)= ["ab", "cde",
> "fg", null]
> *
> * StringUtils.splitByLengthRepeated(" abcdef", 2, 3)= [" a", "bcd",
> "ef", null]
> * StringUtils.splitByLengthRepeated(
[jira] [Created] (LANG-1124) Add split by length methods in StringUtils
Loic Guibert created LANG-1124:
--
Summary: Add split by length methods in StringUtils
Key: LANG-1124
URL: https://issues.apache.org/jira/browse/LANG-1124
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Loic Guibert
Add methods to split a String by fixed lengths :
{code:java}
public static String[] splitByLength(String str, int ... lengths);
public static String[] splitByLengthRepeatedly(String str, int ... lengths);
{code}
Detail :
{code:java}
/**
* Split a String into an array, using an array of fixed string lengths.
*
* If not null String input, the returned array size is same as the input
lengths array.
*
* A null input String returns {@code null}.
* A {@code null} or empty input lengths array returns an empty array.
* A {@code 0} in the input lengths array results in en empty string.
*
* Extra characters are ignored (ie String length greater than sum of split
lengths).
* All empty substrings other than zero length requested, are returned {@code
null}.
*
*
* StringUtils.splitByLength(null, *) = null
* StringUtils.splitByLength("abc")= []
* StringUtils.splitByLength("abc", null) = []
* StringUtils.splitByLength("abc", [])= []
* StringUtils.splitByLength("", 2, 4, 1) = [null, null, null]
*
* StringUtils.splitByLength("abcdefg", 2, 4, 1) = ["ab", "cdef", "g"]
* StringUtils.splitByLength("abcdefghij", 2, 4, 1) = ["ab", "cdef", "g"]
* StringUtils.splitByLength("abcdefg", 2, 4, 5) = ["ab", "cdef", "g"]
* StringUtils.splitByLength("abcdef", 2, 4, 1) = ["ab", "cdef", null]
*
* StringUtils.splitByLength(" abcdef", 2, 4, 1) = [" a", "bcde", "f"]
* StringUtils.splitByLength("abcdef ", 2, 4, 1) = ["ab", "cdef", " "]
* StringUtils.splitByLength("abcdefg", 2, 4, 0, 1) = ["ab", "cdef", "", "g"]
* StringUtils.splitByLength("abcdefg", -1) = {@link
IllegalArgumentException}
*
*
* @param str the String to parse, may be null
* @param lengths the string lengths where to cut, may be null, must not be
negative
* @return an array of splitted Strings, {@code null} if null String input
* @throws IllegalArgumentException
* if one of the lengths is negative
*/
public static String[] splitByLength(String str, int ... lengths);
/**
* Split a String into an array, using an array of fixed string lengths
repeated as
* many times as necessary to reach the String end.
*
* If not null String input, the returned array size is a multiple of the
input lengths array.
*
* A null input String returns {@code null}.
* A {@code null} or empty input lengths array returns an empty array.
* A {@code 0} in the input lengths array results in en empty string.
*
* All empty substrings other than zero length requested and following
substrings,
* are returned {@code null}.
*
*
* StringUtils.splitByLengthRepeated(null, *) = null
* StringUtils.splitByLengthRepeated("abc")= []
* StringUtils.splitByLengthRepeated("abc", null) = []
* StringUtils.splitByLengthRepeated("abc", [])= []
* StringUtils.splitByLengthRepeated("", 2, 4, 1) = [null, null, null]
*
* StringUtils.splitByLengthRepeated("abcdefghij", 2, 3) = ["ab", "cde",
"fg", "hij"]
* StringUtils.splitByLengthRepeated("abcdefgh", 2, 3) = ["ab", "cde",
"fg", "h"]
* StringUtils.splitByLengthRepeated("abcdefg", 2, 3)= ["ab", "cde",
"fg", null]
*
* StringUtils.splitByLengthRepeated(" abcdef", 2, 3)= [" a", "bcd",
"ef", null]
* StringUtils.splitByLengthRepeated("abcdef ", 2, 3)= ["ab", "cde", "f
", null]
* StringUtils.splitByLengthRepeated("abcdef", 2, 3, 0, 1) = ["ab", "cde",
"", "f"]
* StringUtils.splitByLengthRepeated("abcdefg", 2, 3, 0, 1) = ["ab", "cde",
"", "f",
* "g", null,
null, null]
* StringUtils.splitByLengthRepeated("abcdefgh", 2, 0, 1, 0) = ["ab", "", "c",
"",
* "de", "", "f",
"",
* "gh", "", null,
null]
* StringUtils.splitByLengthRepeated("abcdefg", 2, 0, 1, 0) = ["ab", "", "c",
"",
* "de", "", "f",
"",
* "g", null,
null, null]
* StringUtils.splitByLengthRepeated("abcdefg", -1) = {@link
IllegalArgumentException}
* StringUtils.splitByLengthRepeated("abcdefg", 0, 0)= {@link
IllegalArgumentException}
*
*
* @param str the String to parse, may be null
* @param lengths the string lengths where to cut, may be null, must not be
negative
* @return an array of splitted Strings, {@code null} if null String input
* @throws IllegalArgumentException
* if one of the lengths is negative or if lengths sum i
[jira] [Commented] (LANG-1123) Unit test FastDatePrinterTimeZonesTest needs a timezone set
[
https://issues.apache.org/jira/browse/LANG-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521120#comment-14521120
]
Christian P. MOMON commented on LANG-1123:
--
I confirm that this order is fine :-)
> Unit test FastDatePrinterTimeZonesTest needs a timezone set
> ---
>
> Key: LANG-1123
> URL: https://issues.apache.org/jira/browse/LANG-1123
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
> Environment: Java 6, timezone is "Europe/Paris" (GMT/UTC +01:00),
> GNU/Linux.
>Reporter: Christian P. MOMON
>Priority: Blocker
> Fix For: Review Patch
>
> Attachments: LANG-1123-fix-git.patch
>
>
> In file :
> {noformat}
> src/test/java/org/apache/commons/lang3/time/FastDatePrinterTimeZonesTest.java
> {noformat}
> The unit test testCalendarTimezoneRespected set a timezone for the
> expectedValue but none for the actualValue. Because the actualValue use
> always the default timezone, then It has to fail.
> Actually, there is no fail because of a bug in FastDatePrinter.format()
> method (see LANG-916).
> When applying the LANG-916 patch, the unit test flood more than 600 failed:
> {noformat}
> cpm > mvn test
> Failed tests:
> [...]
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[2:19PM EDT]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[2:19PM AST]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[12:19PM MDT]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[1:19PM ACT]> but was:<[6:19PM UTC]>
> [...]
> Tests run: 3544, Failures: 617, Errors: 0, Skipped: 5
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520754#comment-14520754
]
Christian P. MOMON edited comment on LANG-916 at 4/30/15 8:20 AM:
--
After applying the patch, there is a single unit test which flood ~600
failures. To fix this unit test, I created the LANG-1123 issue and uploaded a
patch file.
was (Author: cpm):
After applying the patch, there is a single unit test which flood ~600
failures. To fix this unit test, I created the LANG-1123 issue and upload a
patch file.
> CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
> certain situations
>
>
> Key: LANG-916
> URL: https://issues.apache.org/jira/browse/LANG-916
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
> Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
>Reporter: Christian P. MOMON
> Labels: patch, time
> Fix For: Patch Needed
>
> Attachments: LANG-916-B.patch, LANG-916-C.patch,
> LANG-916-final-git.patch, LANG-916.patch
>
>
> In LANG-538 issue, there is an unit test:
> {noformat}
> public void testFormat_CalendarIsoMsZulu() {
> final String dateTime = "2009-10-16T16:42:16.000Z";
> GregorianCalendar cal = new
> GregorianCalendar(TimeZone.getTimeZone("GMT-8"));
> cal.clear();
> cal.set(2009, 9, 16, 8, 42, 16);
> cal.getTime();
> FastDateFormat format =
> FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("GMT"));
> assertEquals("dateTime", dateTime, format.format(cal));
> }
> {noformat}
> This test passes successfully in lang-2.6 but failed in lang3-3.1:
> {noformat}
> org.junit.ComparisonFailure: dateTime expected:<2009-10-16T[16]:42:16.000Z>
> but was:<2009-10-16T[08]:42:16.000Z>
> {noformat}
> Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
> Moreover, I wrote another unit test showing that the timeZone parameter seems
> to be ignored :
> {noformat}
> public void test() {
> Calendar cal =
> Calendar.getInstance(TimeZone.getTimeZone("Europe/Paris"));
> cal.set(2009, 9, 16, 8, 42, 16);
> //
> System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
> System.out.println("long");
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar");
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar fast");
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/Paris")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Asia/Kolkata")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/London")).format(cal));
> }
> {noformat}
> Gives the following console logs:
> {noformat}
> long
> 2009-10-16T08:42:16+02:00
> 2009-10-16T12:12:16+05:30
> 2009-10-16T07:42:16+01:00
> calendar
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> calendar fast
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> {noformat}
> When DateFormatUtils.format takes a long parameter, the time string is good.
> When DateFormatUtils.format takes a Calendar parameter, the time string is
> wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1153) Sampling from a 'BetaDistribution' is slow
[
https://issues.apache.org/jira/browse/MATH-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521084#comment-14521084
]
Thomas Neidhart commented on MATH-1153:
---
I was probably not very clear in my comment, I just wanted to say that
different sampling methods use > 1 random sample per call to
RealDistribution.sample(), while the test assumes that it is = 1.
I am also fine with removing the test.
> Sampling from a 'BetaDistribution' is slow
> --
>
> Key: MATH-1153
> URL: https://issues.apache.org/jira/browse/MATH-1153
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Sergei Lebedev
>Priority: Minor
> Fix For: 4.0
>
> Attachments: ChengBetaSampler.java, ChengBetaSampler.java,
> ChengBetaSamplerTest.java
>
>
> Currently the `BetaDistribution#sample` uses inverse CDF method, which is
> quite slow for sampling-intensive computations. I've implemented a method
> from the R. C. H. Cheng paper and it seems to work much better. Here's a
> simple microbenchmark:
> {code}
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 1e-31000 thrpt5
> 2592200.01514391.520 ops/s
> o.j.b.s.SamplingBenchmark.algorithmBCorBB 10001000 thrpt5
> 3210800.2920.791 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion1e-31000 thrpt5
> 31034.225 438.273 ops/s
> o.j.b.s.SamplingBenchmark.commonsVersion10001000 thrpt5
> 21834.010 433.324 ops/s
> {code}
> Should I submit a patch?
> R. C. H. Cheng (1978). Generating beta variates with nonintegral shape
> parameters. Communications of the ACM, 21, 317–322.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IO-477) Exception on Mac only: Unexpected end of file from server
[
https://issues.apache.org/jira/browse/IO-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
amr lotfy resolved IO-477.
--
Resolution: Invalid
ISP related issue.
> Exception on Mac only: Unexpected end of file from server
> -
>
> Key: IO-477
> URL: https://issues.apache.org/jira/browse/IO-477
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Environment: mac os x Yosemite version 10.10.2 (14C1514)
>Reporter: amr lotfy
> Labels: osx
>
> http://stackoverflow.com/q/29853775/1356559
> http://qr.ae/L6aYM
> I am downloading mp3 and image files using "org.apache.commons.io.FileUtils"
> in the following code successfully on windows 7:
> FileUtils.copyURLToFile(new URL(urlString),myFile);
> but on mac os x Yosemite version 10.10.2 (14C1514) I get this exception after
> few downloads:
>java.net.SocketException: Unexpected end of file from server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:792)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:789)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1535)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440)
> I have tried adding a timeout
> FileUtils.copyURLToFile(new URL(url),myFile ,6,6);
> or even using other methods
> URLConnection conn = new URL(url).openConnection();
> InputStream is = conn.getInputStream();
> OutputStream outstream = new FileOutputStream(myFile);
> byte[] buffer = new byte[4096];
> int len;
> while ((len = is.read(buffer)) > 0) {
> outstream.write(buffer, 0, len);
> }
> outstream.close();
> Update:
> I tried to disable WiFi (to avoid any connectivity bugs) and used wired
> ethernet but still have the same error after few downloads, any help is
> appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[ https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521051#comment-14521051 ] Alexander Nozik commented on MATH-1143: --- This is exactly what i wat talking about. Also the same thing should be done for MultivariateDifferentiableFunction. Another thing that perhaps is not so easy to do is to create some way to define new derivative structures without using FiniteDifferencesDifferentiator. For example I've got some compex function for which I know its value in any point and all its first order derivatives in any point, but can't provide any analytical expression for it (in my case the function is obtained by integrating some other function). Now I want to work with this function and its derivatives. How can I do that? > Helper methods to FiniteDifferencesDifferentiator > - > > Key: MATH-1143 > URL: https://issues.apache.org/jira/browse/MATH-1143 > Project: Commons Math > Issue Type: Improvement >Reporter: Alexander Nozik >Priority: Trivial > > A DerivativeStructure and UnivariateDifferentiableFunction are great tools if > one needs to investigate the whole function but are not convenient if one > just needs derivative in a given point. > Perhaps you could add some helper methods to FiniteDifferencesDifferentiator > or to utility class like FunctionUtils. Also it would be good to have helper > methods to get the derivatives of UnivariateDifferentiableFunction or > MultivariateDifferentiableFunction as simple Univariate or Multivariate > functions (or vector-functions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-82) Glitch when project base url is not commons.apache.org
[ https://issues.apache.org/jira/browse/COMMONSSITE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521021#comment-14521021 ] Sergio Fernández commented on COMMONSSITE-82: - Ah, no problem, not so urgent. I was thinking you have longer development cycles on such common things on Commons. Cool! > Glitch when project base url is not commons.apache.org > -- > > Key: COMMONSSITE-82 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-82 > Project: Commons All > Issue Type: Bug > Components: Commons Skin >Reporter: Benedikt Ritter > Attachments: commons-skin-glitch.png > > > When using the commons skin for projects not located at commons.apache.org > (but for example in the incubator) the commons skin will produce a broken > side nav. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1123) Unit test FastDatePrinterTimeZonesTest needs a timezone set
[
https://issues.apache.org/jira/browse/LANG-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521018#comment-14521018
]
Benedikt Ritter commented on LANG-1123:
---
If I understand correctly this has to be fixed before LANG-916 can be fixed.
Setting this to be required by LANG-916.
> Unit test FastDatePrinterTimeZonesTest needs a timezone set
> ---
>
> Key: LANG-1123
> URL: https://issues.apache.org/jira/browse/LANG-1123
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
> Environment: Java 6, timezone is "Europe/Paris" (GMT/UTC +01:00),
> GNU/Linux.
>Reporter: Christian P. MOMON
>Priority: Blocker
> Fix For: Review Patch
>
> Attachments: LANG-1123-fix-git.patch
>
>
> In file :
> {noformat}
> src/test/java/org/apache/commons/lang3/time/FastDatePrinterTimeZonesTest.java
> {noformat}
> The unit test testCalendarTimezoneRespected set a timezone for the
> expectedValue but none for the actualValue. Because the actualValue use
> always the default timezone, then It has to fail.
> Actually, there is no fail because of a bug in FastDatePrinter.format()
> method (see LANG-916).
> When applying the LANG-916 patch, the unit test flood more than 600 failed:
> {noformat}
> cpm > mvn test
> Failed tests:
> [...]
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[2:19PM EDT]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[2:19PM AST]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[12:19PM MDT]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[1:19PM ACT]> but was:<[6:19PM UTC]>
> [...]
> Tests run: 3544, Failures: 617, Errors: 0, Skipped: 5
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1123) Unit test FastDatePrinterTimeZonesTest needs a timezone set
[
https://issues.apache.org/jira/browse/LANG-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1123:
--
Fix Version/s: Review Patch
> Unit test FastDatePrinterTimeZonesTest needs a timezone set
> ---
>
> Key: LANG-1123
> URL: https://issues.apache.org/jira/browse/LANG-1123
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
> Environment: Java 6, timezone is "Europe/Paris" (GMT/UTC +01:00),
> GNU/Linux.
>Reporter: Christian P. MOMON
>Priority: Blocker
> Fix For: Review Patch
>
> Attachments: LANG-1123-fix-git.patch
>
>
> In file :
> {noformat}
> src/test/java/org/apache/commons/lang3/time/FastDatePrinterTimeZonesTest.java
> {noformat}
> The unit test testCalendarTimezoneRespected set a timezone for the
> expectedValue but none for the actualValue. Because the actualValue use
> always the default timezone, then It has to fail.
> Actually, there is no fail because of a bug in FastDatePrinter.format()
> method (see LANG-916).
> When applying the LANG-916 patch, the unit test flood more than 600 failed:
> {noformat}
> cpm > mvn test
> Failed tests:
> [...]
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[2:19PM EDT]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[2:19PM AST]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[12:19PM MDT]> but was:<[6:19PM UTC]>
> FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected:61
> expected:<[1:19PM ACT]> but was:<[6:19PM UTC]>
> [...]
> Tests run: 3544, Failures: 617, Errors: 0, Skipped: 5
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-82) Glitch when project base url is not commons.apache.org
[ https://issues.apache.org/jira/browse/COMMONSSITE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521011#comment-14521011 ] Benedikt Ritter commented on COMMONSSITE-82: [~sergio.fernandes], yes, it's on my list. I'm not sure when I will have the time to create an RC. Maybe I'll get to it this Sunday. > Glitch when project base url is not commons.apache.org > -- > > Key: COMMONSSITE-82 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-82 > Project: Commons All > Issue Type: Bug > Components: Commons Skin >Reporter: Benedikt Ritter > Attachments: commons-skin-glitch.png > > > When using the commons skin for projects not located at commons.apache.org > (but for example in the incubator) the commons skin will produce a broken > side nav. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
