[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=14520985#comment-14520985
]
Sergio Fernández commented on COMMONSSITE-82:
-
[~britter], any plan to get this patch released in the {{commons-skin}}?
> 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] (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=14520923#comment-14520923
]
Martin Lindgren commented on CONFIGURATION-599:
---
Thank you for your answer.
{{UnionCombiner}} gives me the expected result for the given example, but I am
not sure yet if I can change to that because many of our projects are currently
using the {{MergeCombiner}} and changing may have unexpected results on other
projects.
I am not sure that I am using the correct node combiner, but it seems strange
to me that my provided example wouldn't work with a {{MergeCombiner}}.
I would like to know if the {{MergeCombiner}} works as intended with the
provided example. If so, I will have to investigate if I can change to the
{{UnionCombiner}} without breaking any functionality.
Thanks!
> 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] [Comment Edited] (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=14520897#comment-14520897
]
Thomas Neidhart edited comment on MATH-1220 at 4/30/15 5:49 AM:
{quote}
Furthermore, I would allow the exponent to be non-negative. Currently, it is
restricted to positive values.
{quote}
I am not sure if we should do this. Normally in literature and implementations,
the exponent is even further restricted (exp > 1), and if you look at the pmf
and cdf functions for exponents < 1 you can see that the resulting distribution
is quite distorted. I guess the typical implementation uses the Riemann zeta
function which does not converge for exponents < 1.
btw. there is something in your implementation that I do not understand:
{code}
* An instrumental distribution g(k) is used to generate random values by
rejection sampling.
* g(k) is defined as g(1):= 1 and g(k) := I(-s,k-1/2,k+1/2) for k larger
than 1,
* where s denotes the exponent of the Zipf distribution and I(r,a,b) is
the integral of x^r for x from a to b.
* Since 1^x^s is a convex function, Jensens's inequality gives
* I(-s,k-1/2,k+1/2) >= 1/k^s for all positive k and non-negative s.
* In order to limit the rejection rate for large exponents s,
* the instrumental distribution weight is differently defined for value 1.
*/
@Override
public int sample() {
if (Double.isNaN(instrumentalDistributionTailWeight)) {
instrumentalDistributionTailWeight =
integratePowerFunction(-exponent, 1.5, numberOfElements+0.5);
}
{code}
talks about integrating the power function in the range [k-0.5, k+0.5] but in
fact uses 1.5 and k+0.5 as bounds. Where does the 1.5 come from?
Is it because you evaluate the tail in the range [2, N]?
was (Author: tn):
{quote}
Furthermore, I would allow the exponent to be non-negative. Currently, it is
restricted to positive values.
{quote}
I am not sure if we should do this. Normally in literature and implementations,
the exponent is even further restricted (exp > 1), and if you look at the pmf
and cdf functions for exponents < 1 you can see that the resulting distribution
is quite distorted. I guess the typical implementation uses the Riemann zeta
function which does not converge for exponents < 1.
btw. there is something in your implementation that I do not understand:
{code}
* An instrumental distribution g(k) is used to generate random values by
rejection sampling.
* g(k) is defined as g(1):= 1 and g(k) := I(-s,k-1/2,k+1/2) for k larger
than 1,
* where s denotes the exponent of the Zipf distribution and I(r,a,b) is
the integral of x^r for x from a to b.
* Since 1^x^s is a convex function, Jensens's inequality gives
* I(-s,k-1/2,k+1/2) >= 1/k^s for all positive k and non-negative s.
* In order to limit the rejection rate for large exponents s,
* the instrumental distribution weight is differently defined for value 1.
*/
@Override
public int sample() {
if (Double.isNaN(instrumentalDistributionTailWeight)) {
instrumentalDistributionTailWeight =
integratePowerFunction(-exponent, 1.5, numberOfElements+0.5);
}
{code}
talks about integrating the power function in the range [k-0.5, k+0.5] but in
fact uses 1.5 and k+0.5 as bounds. Where does the 1.5 come from?
> 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)
[jira] [Comment Edited] (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=14520897#comment-14520897
]
Thomas Neidhart edited comment on MATH-1220 at 4/30/15 5:37 AM:
{quote}
Furthermore, I would allow the exponent to be non-negative. Currently, it is
restricted to positive values.
{quote}
I am not sure if we should do this. Normally in literature and implementations,
the exponent is even further restricted (exp > 1), and if you look at the pmf
and cdf functions for exponents < 1 you can see that the resulting distribution
is quite distorted. I guess the typical implementation uses the Riemann zeta
function which does not converge for exponents < 1.
btw. there is something in your implementation that I do not understand:
{code}
* An instrumental distribution g(k) is used to generate random values by
rejection sampling.
* g(k) is defined as g(1):= 1 and g(k) := I(-s,k-1/2,k+1/2) for k larger
than 1,
* where s denotes the exponent of the Zipf distribution and I(r,a,b) is
the integral of x^r for x from a to b.
* Since 1^x^s is a convex function, Jensens's inequality gives
* I(-s,k-1/2,k+1/2) >= 1/k^s for all positive k and non-negative s.
* In order to limit the rejection rate for large exponents s,
* the instrumental distribution weight is differently defined for value 1.
*/
@Override
public int sample() {
if (Double.isNaN(instrumentalDistributionTailWeight)) {
instrumentalDistributionTailWeight =
integratePowerFunction(-exponent, 1.5, numberOfElements+0.5);
}
{code}
talks about integrating the power function in the range [k-0.5, k+0.5] but in
fact uses 1.5 and k+0.5 as bounds. Where does the 1.5 come from?
was (Author: tn):
{comment}
Furthermore, I would allow the exponent to be non-negative. Currently, it is
restricted to positive values.
{comment}
I am not sure if we should do this. Normally in literature and implementations,
the exponent is even further restricted (exp > 1), and if you look at the pmf
and cdf functions for exponents < 1 you can see that the resulting distribution
is quite distorted. I guess the typical implementation uses the Riemann zeta
function which does not converge for exponents < 1.
btw. there is something in your implementation that I do not understand:
{code}
* An instrumental distribution g(k) is used to generate random values by
rejection sampling.
* g(k) is defined as g(1):= 1 and g(k) := I(-s,k-1/2,k+1/2) for k larger
than 1,
* where s denotes the exponent of the Zipf distribution and I(r,a,b) is
the integral of x^r for x from a to b.
* Since 1^x^s is a convex function, Jensens's inequality gives
* I(-s,k-1/2,k+1/2) >= 1/k^s for all positive k and non-negative s.
* In order to limit the rejection rate for large exponents s,
* the instrumental distribution weight is differently defined for value 1.
*/
@Override
public int sample() {
if (Double.isNaN(instrumentalDistributionTailWeight)) {
instrumentalDistributionTailWeight =
integratePowerFunction(-exponent, 1.5, numberOfElements+0.5);
}
{code}
talks about integrating the power function in the range [k-0.5, k+0.5] but in
fact uses 1.5 and k+0.5 as bounds. Where does the 1.5 come from?
> 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)
[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=14520897#comment-14520897
]
Thomas Neidhart commented on MATH-1220:
---
{comment}
Furthermore, I would allow the exponent to be non-negative. Currently, it is
restricted to positive values.
{comment}
I am not sure if we should do this. Normally in literature and implementations,
the exponent is even further restricted (exp > 1), and if you look at the pmf
and cdf functions for exponents < 1 you can see that the resulting distribution
is quite distorted. I guess the typical implementation uses the Riemann zeta
function which does not converge for exponents < 1.
btw. there is something in your implementation that I do not understand:
{code}
* An instrumental distribution g(k) is used to generate random values by
rejection sampling.
* g(k) is defined as g(1):= 1 and g(k) := I(-s,k-1/2,k+1/2) for k larger
than 1,
* where s denotes the exponent of the Zipf distribution and I(r,a,b) is
the integral of x^r for x from a to b.
* Since 1^x^s is a convex function, Jensens's inequality gives
* I(-s,k-1/2,k+1/2) >= 1/k^s for all positive k and non-negative s.
* In order to limit the rejection rate for large exponents s,
* the instrumental distribution weight is differently defined for value 1.
*/
@Override
public int sample() {
if (Double.isNaN(instrumentalDistributionTailWeight)) {
instrumentalDistributionTailWeight =
integratePowerFunction(-exponent, 1.5, numberOfElements+0.5);
}
{code}
talks about integrating the power function in the range [k-0.5, k+0.5] but in
fact uses 1.5 and k+0.5 as bounds. Where does the 1.5 come from?
> 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)
[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=14520761#comment-14520761
]
Christian P. MOMON commented on LANG-1123:
--
LANG-1123 bug appears now because it was hidden by LANG-916 bug.
> 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
> 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=14520754#comment-14520754
]
Christian P. MOMON commented on LANG-916:
-
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] [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
]
Christian P. MOMON updated LANG-1123:
-
Attachment: LANG-1123-fix-git.patch
Git patch to fix missing timezone set in actualValue
> 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
> 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
]
Christian P. MOMON updated LANG-1123:
-
Description:
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. As 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}
was:
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. 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}
> 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
>
> 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. As 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
]
Christian P. MOMON updated LANG-1123:
-
Description:
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}
was:
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. As 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}
> 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
>
> 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] [Created] (LANG-1123) Unit test FastDatePrinterTimeZonesTest needs a timezone set
Christian P. MOMON created LANG-1123:
Summary: 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
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. 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=14520688#comment-14520688
]
Christian P. MOMON commented on LANG-916:
-
Git is welcome. :-) GitHub is not a free software so I do not use it.
On this JIRA, I uploaded an attachment patch file in git format:
LANG-916-final-git.patch
It contains fix and unit test reproducing the problem.
FYI, my ICLA is sent.
Let me know if all is good. :-)
> 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] [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=14520684#comment-14520684
]
Christian P. MOMON edited comment on LANG-916 at 4/30/15 1:44 AM:
--
Final patch containing fix and unit test reproducing the problem.
was (Author: cpm):
Final patch containing fix and unit test.
> 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] [Updated] (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
]
Christian P. MOMON updated LANG-916:
Attachment: LANG-916-final-git.patch
Final patch containing fix and unit test.
> 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=14520632#comment-14520632
]
Phil Steitz commented on MATH-1153:
---
See my comment above on the testNextInversionDeviate failure. I remain +1 for
just dropping the test, as it is just a test of the default inversion-based
sampling. There is no reason to expect that it will succeed for non-inversion
based samplers. If there are no objections, I will drop it. If we really want
to retain it, we should create a dummy distribution that will *always* use
inversion-based sampling and replace the Beta instance with that (or come up
with a better test somehow).
I am not sure I understand your comments, Thomas, about "consuming more
randomness" for other distributions. What tests, exactly would fail and why?
The failing test is from the RandomDataGenerator and it is designed just to
test the default inversion-based sampler that distributions that do not supply
a custom sampler use. It was implemented (stupidly, in retrospect) using a
Beta distribution when at the time that distribution did not override the
default. Given the current code structure (with samplers moved to the dist
package) it would probably also be better to move this test to
AbstractRealDistributionTest if we decide to rectify and retain it.
> 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-1143) Helper methods to FiniteDifferencesDifferentiator
[
https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520131#comment-14520131
]
Thomas Neidhart commented on MATH-1143:
---
Examples:
evaluation
{code}
public static double derivative(UnivariateDifferentiableFunction f, double
x, int order) {
DerivativeStructure ds = f.value(new DerivativeStructure(1, order, 0,
x));
return ds.getPartialDerivative(order);
}
{code}
derivative function
{code}
public static UnivariateFunction derivative(final
UnivariateDifferentiableFunction f, final int order) {
return new UnivariateFunction() {
@Override
public double value(double x) {
DerivativeStructure ds = f.value(new DerivativeStructure(1,
order, 0, x));
return ds.getPartialDerivative(order);
}
};
}
{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-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=14520123#comment-14520123 ] Otmar Ertl commented on MATH-1220: -- Caching generalizedHarmonic(numberOfElements, exponent) makes sense. The inverse cumulative probability would be more efficient by simply summing up the probabilities of points until the searched probability is met. Furthermore, I would allow the exponent to be non-negative. Currently, it is restricted to positive values. I have developed the method by myself. I do not know if a similar method can be found in literature. So far, apart from this math library, I have no plans to publish it somewhere else. I am not sure, if I could bring up the time to write some paper. > 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)
[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=14520101#comment-14520101
]
Oliver Heger commented on CONFIGURATION-599:
Are you sure you are using the correct node combiner for your use case?
{{MergeCombiner}} implements some pretty special merging rules; have a look at
the Javadocs at
http://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/tree/MergeCombiner.html.
Try UnionCombiner; this class always generates a union of the configurations
involved. Examples for the different combiners can be found in the user's
guide:
http://commons.apache.org/proper/commons-configuration/userguide/howto_combinedconfiguration.html#Node_combiners
> 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] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[ https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520099#comment-14520099 ] Thomas Neidhart commented on MATH-1143: --- What helper methods do you have in mind? For example to get the first / second order derivative of a univariate function? > 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] (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=14520093#comment-14520093
]
Benedikt Ritter commented on CLI-249:
-
[~dfg] I don't understand the difference. Have a look at the code in
OptionValidator:
{code:java}
if (opt.length() == 1)
{
char ch = opt.charAt(0);
if (!isValidOpt(ch))
{
throw new IllegalArgumentException("Illegal option name '" + ch
+ "'");
}
}
{code}
In this case opt and ch contain the came charater (because opt has length == 1).
> 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] [Comment Edited] (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=14519052#comment-14519052 ] Thomas Neidhart edited comment on MATH-1220 at 4/29/15 7:39 PM: btw. is the implemented rejection method published anywhere? The most recent paper about sampling from a Zipf distribution that I could find is available here: http://epub.wu.ac.at/1176/ which refers to two older methods from Devroye and Dagpunar. Edit: I did a lot of tests and research already on the topic, and it seems that the proposed method improves the current state of the art, but I could not find any reference or published version of the algorithm. Do you plan to publish it? was (Author: tn): btw. is the implemented rejection method published anywhere? The most recent paper about sampling from a Zipf distribution that I could find is available here: http://epub.wu.ac.at/1176/ which refers to two older methods from Devroye and Dagpunar. > 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)
[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=14520038#comment-14520038
]
Thomas Neidhart commented on MATH-1153:
---
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] [Updated] (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
]
Benedikt Ritter updated LANG-1116:
--
Fix Version/s: (was: Review Patch)
Discussion
> 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] [Updated] (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
]
Benedikt Ritter updated LANG-1116:
--
Description:
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.
was:
Unit test for testLang530 fails when the isoDateStr comes out with just a Z
instead of +00:00.
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)
On a Linux machine where this test passes, isoDateStr is
2015-04-17T19:26:03+00:00.
> 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) testLang530 fails for some timezones
[
https://issues.apache.org/jira/browse/LANG-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520015#comment-14520015
]
Benedikt Ritter commented on LANG-1116:
---
[~asheldon] Thank you! I found out that testLang530 seems to fail when you're
in UTC! So modifing the test like so:
{code:java}
@Test
public void testLang530() throws ParseException {
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
final Date d = new Date();
final String isoDateStr =
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(d);
final Date d2 = DateUtils.parseDate(isoDateStr, new String[] {
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern() });
// the format loses milliseconds so have to reintroduce them
assertEquals("Date not equal to itself ISO formatted and parsed",
d.getTime(), d2.getTime() + d.getTime() % 1000);
}
{code}
Will make it fail on my machine. I'll update the description of this ticket.
Now we have to find a fix that works on your machine and on my machine :-) I'm
currently in CEST.
> 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: Review Patch
>
> 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.
> 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)
> 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] [Updated] (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 ] Benedikt Ritter updated LANG-1116: -- Summary: DateUtilsTest.testLang530 fails for some timezones (was: testLang530 fails for some timezones) > 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: Review Patch > > 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. > 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) > 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] (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=14519972#comment-14519972 ] EMR commented on DBUTILS-125: - Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production > 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] [Closed] (EMAIL-153) Not Applicable
[ https://issues.apache.org/jira/browse/EMAIL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] first closed EMAIL-153. --- Resolution: Invalid > Not Applicable > -- > > Key: EMAIL-153 > URL: https://issues.apache.org/jira/browse/EMAIL-153 > Project: Commons Email > Issue Type: Bug >Reporter: first >Priority: Blocker > > Not applicable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (EMAIL-153) Not Applicable
[
https://issues.apache.org/jira/browse/EMAIL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
first updated EMAIL-153:
Description: Not applicable (was: Reporting for the first time.Please let
me know if I missed anything.
When I send an email with code :
private JavaMailSender mailSender;
mailSender.send(new MimeMessagePreparator() {
@Override
public void prepare(MimeMessage
mimeMessage) throws MessagingException {
try{
MimeMessageHelper
mailMessage = new MimeMessageHelper(mimeMessage, true, "UTF-8");
mailMessage.setFrom(from);
mailMessage.setSubject(subject);
mailMessage.setTo(to);
if(cc!=null)
mailMessage.setCc(cc);
if(fileAttachments!=null && !fileAttachments.isEmpty()){
..
mailMessage.addAttachment(fileAttachment.getFileName(), contentsAsResource);
}
if(img!=null &&
!img.isEmpty())
getBodyWithImg(mailMessage,imgs, body);
}catch(Exception e){
_logger.error("Error in
prepare(..)",e);
}
}
private void
getBodyWithImgs(MimeMessageHelper mailMessage,List imgs,String body)
throws MessagingException {
StringBuffer images = new StringBuffer();
for
(final Img im: imgs)
images.append("
[jira] [Reopened] (EMAIL-153) Email with body only test give garbage value
[
https://issues.apache.org/jira/browse/EMAIL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
first reopened EMAIL-153:
-
> Email with body only test give garbage value
>
>
> Key: EMAIL-153
> URL: https://issues.apache.org/jira/browse/EMAIL-153
> Project: Commons Email
> Issue Type: Bug
>Reporter: first
>Priority: Blocker
>
> Reporting for the first time.Please let me know if I missed anything.
> When I send an email with code :
> private JavaMailSender mailSender;
> mailSender.send(new MimeMessagePreparator() {
> @Override
> public void prepare(MimeMessage
> mimeMessage) throws MessagingException {
> try{
> MimeMessageHelper
> mailMessage = new MimeMessageHelper(mimeMessage, true, "UTF-8");
>
> mailMessage.setFrom(from);
>
> mailMessage.setSubject(subject);
> mailMessage.setTo(to);
> if(cc!=null)
>
> mailMessage.setCc(cc);
>
>
> if(fileAttachments!=null && !fileAttachments.isEmpty()){
> ..
>
> mailMessage.addAttachment(fileAttachment.getFileName(), contentsAsResource);
>
> }
>
> if(img!=null &&
> !img.isEmpty())
>
> getBodyWithImg(mailMessage,imgs, body);
> }catch(Exception e){
> _logger.error("Error in
> prepare(..)",e);
> }
> }
>
> private void
> getBodyWithImgs(MimeMessageHelper mailMessage,List imgs,String
> body) throws MessagingException {
>
> StringBuffer images = new StringBuffer();
>
>
> for
> (final Img im: imgs)
>
> images.append("
[jira] [Updated] (EMAIL-153) Not Applicable
[
https://issues.apache.org/jira/browse/EMAIL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
first updated EMAIL-153:
Summary: Not Applicable (was: Email with body only test give garbage value)
> Not Applicable
> --
>
> Key: EMAIL-153
> URL: https://issues.apache.org/jira/browse/EMAIL-153
> Project: Commons Email
> Issue Type: Bug
>Reporter: first
>Priority: Blocker
>
> Reporting for the first time.Please let me know if I missed anything.
> When I send an email with code :
> private JavaMailSender mailSender;
> mailSender.send(new MimeMessagePreparator() {
> @Override
> public void prepare(MimeMessage
> mimeMessage) throws MessagingException {
> try{
> MimeMessageHelper
> mailMessage = new MimeMessageHelper(mimeMessage, true, "UTF-8");
>
> mailMessage.setFrom(from);
>
> mailMessage.setSubject(subject);
> mailMessage.setTo(to);
> if(cc!=null)
>
> mailMessage.setCc(cc);
>
>
> if(fileAttachments!=null && !fileAttachments.isEmpty()){
> ..
>
> mailMessage.addAttachment(fileAttachment.getFileName(), contentsAsResource);
>
> }
>
> if(img!=null &&
> !img.isEmpty())
>
> getBodyWithImg(mailMessage,imgs, body);
> }catch(Exception e){
> _logger.error("Error in
> prepare(..)",e);
> }
> }
>
> private void
> getBodyWithImgs(MimeMessageHelper mailMessage,List imgs,String
> body) throws MessagingException {
>
> StringBuffer images = new StringBuffer();
>
>
> for
> (final Img im: imgs)
>
> images.append("
[jira] [Closed] (EMAIL-153) Email with body only test give garbage value
[
https://issues.apache.org/jira/browse/EMAIL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
first closed EMAIL-153.
---
> Email with body only test give garbage value
>
>
> Key: EMAIL-153
> URL: https://issues.apache.org/jira/browse/EMAIL-153
> Project: Commons Email
> Issue Type: Bug
>Reporter: first
>Priority: Blocker
>
> Reporting for the first time.Please let me know if I missed anything.
> When I send an email with code :
> private JavaMailSender mailSender;
> mailSender.send(new MimeMessagePreparator() {
> @Override
> public void prepare(MimeMessage
> mimeMessage) throws MessagingException {
> try{
> MimeMessageHelper
> mailMessage = new MimeMessageHelper(mimeMessage, true, "UTF-8");
>
> mailMessage.setFrom(from);
>
> mailMessage.setSubject(subject);
> mailMessage.setTo(to);
> if(cc!=null)
>
> mailMessage.setCc(cc);
>
>
> if(fileAttachments!=null && !fileAttachments.isEmpty()){
> ..
>
> mailMessage.addAttachment(fileAttachment.getFileName(), contentsAsResource);
>
> }
>
> if(img!=null &&
> !img.isEmpty())
>
> getBodyWithImg(mailMessage,imgs, body);
> }catch(Exception e){
> _logger.error("Error in
> prepare(..)",e);
> }
> }
>
> private void
> getBodyWithImgs(MimeMessageHelper mailMessage,List imgs,String
> body) throws MessagingException {
>
> StringBuffer images = new StringBuffer();
>
>
> for
> (final Img im: imgs)
>
> images.append("
[jira] [Resolved] (EMAIL-153) Email with body only test give garbage value
[
https://issues.apache.org/jira/browse/EMAIL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved EMAIL-153.
---
Resolution: Invalid
The bug report does not explain the actual problem, uses spring instead of
commons-email and is simply incomprehensible.
> Email with body only test give garbage value
>
>
> Key: EMAIL-153
> URL: https://issues.apache.org/jira/browse/EMAIL-153
> Project: Commons Email
> Issue Type: Bug
>Reporter: first
>Priority: Blocker
>
> Reporting for the first time.Please let me know if I missed anything.
> When I send an email with code :
> private JavaMailSender mailSender;
> mailSender.send(new MimeMessagePreparator() {
> @Override
> public void prepare(MimeMessage
> mimeMessage) throws MessagingException {
> try{
> MimeMessageHelper
> mailMessage = new MimeMessageHelper(mimeMessage, true, "UTF-8");
>
> mailMessage.setFrom(from);
>
> mailMessage.setSubject(subject);
> mailMessage.setTo(to);
> if(cc!=null)
>
> mailMessage.setCc(cc);
>
>
> if(fileAttachments!=null && !fileAttachments.isEmpty()){
> ..
>
> mailMessage.addAttachment(fileAttachment.getFileName(), contentsAsResource);
>
> }
>
> if(img!=null &&
> !img.isEmpty())
>
> getBodyWithImg(mailMessage,imgs, body);
> }catch(Exception e){
> _logger.error("Error in
> prepare(..)",e);
> }
> }
>
> private void
> getBodyWithImgs(MimeMessageHelper mailMessage,List imgs,String
> body) throws MessagingException {
>
> StringBuffer images = new StringBuffer();
>
>
> for
> (final Img im: imgs)
>
> images.append("
[jira] [Updated] (EMAIL-153) Email with body only test give garbage value
[
https://issues.apache.org/jira/browse/EMAIL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
first updated EMAIL-153:
Summary: Email with body only test give garbage value (was: Email with ltd
test give garbage value)
> Email with body only test give garbage value
>
>
> Key: EMAIL-153
> URL: https://issues.apache.org/jira/browse/EMAIL-153
> Project: Commons Email
> Issue Type: Bug
>Reporter: first
>Priority: Blocker
>
> Reporting for the first time.Please let me know if I missed anything.
> When I send an email with code :
> private JavaMailSender mailSender;
> mailSender.send(new MimeMessagePreparator() {
> @Override
> public void prepare(MimeMessage
> mimeMessage) throws MessagingException {
> try{
> MimeMessageHelper
> mailMessage = new MimeMessageHelper(mimeMessage, true, "UTF-8");
>
> mailMessage.setFrom(from);
>
> mailMessage.setSubject(subject);
> mailMessage.setTo(to);
> if(cc!=null)
>
> mailMessage.setCc(cc);
>
>
> if(fileAttachments!=null && !fileAttachments.isEmpty()){
> ..
>
> mailMessage.addAttachment(fileAttachment.getFileName(), contentsAsResource);
>
> }
>
> if(img!=null &&
> !img.isEmpty())
>
> getBodyWithImg(mailMessage,imgs, body);
> }catch(Exception e){
> _logger.error("Error in
> prepare(..)",e);
> }
> }
>
> private void
> getBodyWithImgs(MimeMessageHelper mailMessage,List imgs,String
> body) throws MessagingException {
>
> StringBuffer images = new StringBuffer();
>
>
> for
> (final Img im: imgs)
>
> images.append("
[jira] [Updated] (EMAIL-153) Email with ltd test give garbage value
[
https://issues.apache.org/jira/browse/EMAIL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
first updated EMAIL-153:
Description:
Reporting for the first time.Please let me know if I missed anything.
When I send an email with code :
private JavaMailSender mailSender;
mailSender.send(new MimeMessagePreparator() {
@Override
public void prepare(MimeMessage
mimeMessage) throws MessagingException {
try{
MimeMessageHelper
mailMessage = new MimeMessageHelper(mimeMessage, true, "UTF-8");
mailMessage.setFrom(from);
mailMessage.setSubject(subject);
mailMessage.setTo(to);
if(cc!=null)
mailMessage.setCc(cc);
if(fileAttachments!=null && !fileAttachments.isEmpty()){
..
mailMessage.addAttachment(fileAttachment.getFileName(), contentsAsResource);
}
if(img!=null &&
!img.isEmpty())
getBodyWithImg(mailMessage,imgs, body);
}catch(Exception e){
_logger.error("Error in
prepare(..)",e);
}
}
private void
getBodyWithImgs(MimeMessageHelper mailMessage,List imgs,String body)
throws MessagingException {
StringBuffer images = new StringBuffer();
for
(final Img im: imgs)
images.append(""+body, true);
for
(final Img im: imgs)
attachInline(logo,mailMessage);
private void attachInline(final
Imgs img,MimeMessageHelper mailMessage) throws MessagingException {
AbstractResource
contentsAsResource = new
ByteArrayResource(Base64.decode(logo.getLogoImg().split(",")[1])){
@Override
public String
getFilename(){
return
img.getName();
}
};
mailMessage.addInline(img.getName(),contentsAsResource);
}
});
}catch(Exception ex){
_logger.error("Error occured while sending mail. Error
: "+ex.getMessage());
}
> Email with ltd test give garbage value
> --
>
> Key: EMAIL-153
> URL: https://issues.apache.org/jira/browse/EMAIL-153
> Project: Commons Email
> Issue Type: Bug
>Reporter: first
>Priority: Blocker
>
> Reporting for the first time.Please let me know if I missed anything.
> When I send an email with code :
> private JavaMailSender mailSender;
> mailSender.send(new MimeMessagePreparator() {
> @Override
>
[jira] [Updated] (EMAIL-153) Email with ltd test give garbage value
[
https://issues.apache.org/jira/browse/EMAIL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
first updated EMAIL-153:
Description:
Reporting for the first time.Please let me know if I missed anything.
When I send an email with code :
private JavaMailSender mailSender;
mailSender.send(new MimeMessagePreparator() {
@Override
public void prepare(MimeMessage
mimeMessage) throws MessagingException {
try{
MimeMessageHelper
mailMessage = new MimeMessageHelper(mimeMessage, true, "UTF-8");
mailMessage.setFrom(from);
mailMessage.setSubject(subject);
mailMessage.setTo(to);
if(cc!=null)
mailMessage.setCc(cc);
if(fileAttachments!=null && !fileAttachments.isEmpty()){
..
mailMessage.addAttachment(fileAttachment.getFileName(), contentsAsResource);
}
if(img!=null &&
!img.isEmpty())
getBodyWithImg(mailMessage,imgs, body);
}catch(Exception e){
_logger.error("Error in
prepare(..)",e);
}
}
private void
getBodyWithLogos(MimeMessageHelper mailMessage,List imgs,String body)
throws MessagingException {
StringBuffer images = new StringBuffer();
for
(final Img im: imgs)
images.append("");
mailMessage.setText(images.toString()+""+body, true);
for
(final CpsLogo logo : logos)
attachInline(logo,mailMessage);
break;
case TOP_LEFT:
for
(final CpsLogo logo : logos)
images.append("");
mailMessage.setText(images.toString()+""+body, true);
for
(final CpsLogo logo : logos)
attachInline(logo,mailMessage);
break;
case
BOTTOM_LEFT:
for
(final CpsLogo logo : logos)
images.append("");
mailMessage.setText(body+""+images.toString(), true);
[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=14519939#comment-14519939 ] Michael Osipov commented on DBUTILS-125: What database version do you use? If you can prepare a minimal working example for me, I will retry this at work. I have 11.2g at hand here. > 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] [Created] (EMAIL-153) Email with ltd test give garbage value
first created EMAIL-153:
---
Summary: Email with ltd test give garbage value
Key: EMAIL-153
URL: https://issues.apache.org/jira/browse/EMAIL-153
Project: Commons Email
Issue Type: Bug
Reporter: first
Priority: Blocker
Reporting for the first time.Please let me know if I missed anything.
When I send an email with code :
private JavaMailSender mailSender;
mailSender.send(new MimeMessagePreparator() {
@Override
public void prepare(MimeMessage
mimeMessage) throws MessagingException {
try{
MimeMessageHelper
mailMessage = new MimeMessageHelper(mimeMessage, true, "UTF-8");
mailMessage.setFrom(from);
mailMessage.setSubject(subject);
mailMessage.setTo(to);
if(cc!=null)
mailMessage.setCc(cc);
if(fileAttachments!=null && !fileAttachments.isEmpty()){
for (final
CpsFileAttachment fileAttachment : fileAttachments) {
AbstractResource contentsAsResource = new
ByteArrayResource(Base64.decode(fileAttachment.getFileData().split(",")[1])){
@Override
public String getFilename(){
return fileAttachment.getFileName();
}
};
mailMessage.addAttachment(fileAttachment.getFileName(), contentsAsResource);
}
}
if(logos!=null &&
!logos.isEmpty())
getBodyWithLogos(mailMessage,logos, body);
}catch(Exception e){
_logger.error("Error in
prepare(..)",e);
}
}
private void
getBodyWithLogos(MimeMessageHelper mailMessage,List logos,String body)
throws MessagingException {
CPSEmailConfigLogoPositionEnum position = logos.get(0).getLogoPosition();
StringBuffer images =
new StringBuffer();
switch (position) {
case TOP_RIGHT:
for
(final CpsLogo logo : logos)
images.append("");
mailMessage.setText(images.toString()+""+body, true);
for
(final CpsLogo logo : logos)
attachInline(logo,mailMessage);
break;
case TOP_LEFT:
for
(final CpsLogo logo : logos)
images.append("");
mailMessage.setText(images.toString()+""+body, true);
[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=14519903#comment-14519903 ] EMR commented on DBUTILS-125: - Modified the sql statement to use parameter "?"'s and changed the code to: pstmt = conn.prepareStatement(ePersonSql1); pstmt.setString(1, "xx1"); pstmt.setString(2, "xx1"); ResultSet rs = pstmt.executeQuery(); Same problem. Is there a way that I can turn on verbose debugging in the dbutils library? > 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] [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=14519883#comment-14519883 ] Michael Osipov commented on DBUTILS-125: This isn't equivalent. DbUtils does a prepared statement. Here you did a regular one. > 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] [Resolved] (LANG-1114) TypeUtils.ParameterizedType#equals doesn't work with wildcard types
[
https://issues.apache.org/jira/browse/LANG-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-1114.
---
Resolution: Fixed
Fix Version/s: (was: Review Patch)
3.5
Fixed in 640953167adf3580a2c21077d78e7e7ce84ead03
> TypeUtils.ParameterizedType#equals doesn't work with wildcard types
> ---
>
> Key: LANG-1114
> URL: https://issues.apache.org/jira/browse/LANG-1114
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.3.2, 3.4
>Reporter: andrew coates
>Assignee: Benedikt Ritter
> Fix For: 3.5
>
>
> There is a bug in TypeUtils.equals(WilcardType, Type). It returns true if
> the other type is not a WildcardType, it should return false. See
> TypeUtils@1629 for v3.3.2 and TypeUtils@791 for v3.4
> Bug can be seen with the following test:
> {code}
> @Test
> public void shouldHandleEqualityOfParameterizedTypesWithWildcards()
> throws Exception {
> // Given:
> class SomeType {
> Collection field;
> }
> final ParameterizedType wildcardCollectionType = (ParameterizedType)
> SomeType.class.getDeclaredField("field").getGenericType();
> final WildcardType wildcard = (WildcardType)
> wildcardCollectionType.getActualTypeArguments()[0];
> final ParameterizedType ptWithWildcard =
> TypeUtils.parameterize(Collection.class, wildcard);
> final ParameterizedType otherPt =
> TypeUtils.parameterize(Collection.class, String.class);
> // Then:
> assertThat(otherPt, is(not(equalTo(ptWithWildcard; // Passes
> assertThat(ptWithWildcard, is(not(equalTo(otherPt; // Fails
> }
> {code}
--
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=14519794#comment-14519794 ] ASF GitHub Bot commented on LANG-1122: -- Github user britter commented on the pull request: https://github.com/apache/commons-lang/pull/47#issuecomment-97514318 Hello @beradrian, sorry for being so oblivious. Yes it would be best to create a separate PR for this issue. I've already created a new jira issue for tracking this: https://issues.apache.org/jira/browse/LANG-1122 > 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] [Created] (LANG-1122) Inconsistent behavior of swap for malformed inputs
Benedikt Ritter created LANG-1122: - Summary: 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] [Commented] (VFS-531) Cannot "copyFrom" without access to create parent folder even if folder exists
[
https://issues.apache.org/jira/browse/VFS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519764#comment-14519764
]
Pascal Pochet commented on VFS-531:
---
Execute access is not enough due to the walking up algorithm, if you have a
hierarchy like this:
../noread/canwrite/
where noread is drwx--x--x 3 root root
and canwrite is drwxr-xr-x 2 someuser someuser
you will never be able to write anything into "canwrite" folder as user
"someuser" because the absurd logic of walking from parent to parent folder to
see if each path segment exists, while of course using any other FTP client
works.
Of course doing the copy step directly with the full path to the target, works.
> Cannot "copyFrom" without access to create parent folder even if folder exists
> --
>
> Key: VFS-531
> URL: https://issues.apache.org/jira/browse/VFS-531
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Linux
>Reporter: Laplie Anderson
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Using copyFrom when you don't have access to create the parent folder fails
> even when the parent folder exists.
> I have the folder structure of:
> /home/usera/subfolder
> Userb has r/w access to the subfolder and read access to the parent folders.
> CopyFrom with a destination of "/home/usera/subfolder/file" fails
> {code:borderStyle=solid}
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not create
> folder "file:///home/usera/subfolder".
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.createFolder(AbstractFileObject.java:999)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1424)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:461)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:441)
> at org.apache.commons.vfs2.FileUtil.copyContent(FileUtil.java:111)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:1053)
> ... 2 more
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not create
> directory "/home/usera/subfolder".
> at
> org.apache.commons.vfs2.provider.local.LocalFile.doCreateFolder(LocalFile.java:153)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.createFolder(AbstractFileObject.java:988)
> ... 7 more
> {code}
> It looks like the issue is that the code doesn't check if the destination
> folder exists before calling create. Create throws an exception any time the
> folder is not created (even if it didn't have to create the folder.)
--
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=14519716#comment-14519716
]
EMR commented on DBUTILS-125:
-
Using dbutils, it fails with v12 drivers, while working with v11 drivers. (both
ojdbc6 and 7.jar)
Doing it the old fashioned way it works with v11 and v12 drivers.
// old fashioned way
Connection conn = null;
Properties connectionProps = new Properties();
connectionProps.put("user", "myuser");
connectionProps.put("password", "mypassword");
conn =
DriverManager.getConnection("jdbc:oracle:thin:@server:1521/foo",
connectionProps);
_log.debug("Got conn: "+conn.toString());
DatabaseMetaData meta = conn.getMetaData();
_log.warn("JDBC driver version is " + meta.getDriverVersion());
String ePersonSql1 = " SELECT DISTINCT * FROM schema1.reader_vw
WHERE user_id = 'xx1' OR barcode = 'xx1' ";
stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(ePersonSql1);
while(rs.next()) {
_log.debug("GOT DATA: "+
rs.getString(1) + "|" +
rs.getString(2) + "|" +
rs.getString(3) + "|" +
rs.getString(4) + "|" +
rs.getString(5) + "|" +
rs.getString(6) + "|" +
rs.getString(7)
);
}
> 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] [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=14519684#comment-14519684 ] Michael Osipov commented on DBUTILS-125: Are you able to reproduce the issue with plain JDBC calls? Yes, I know that is pain in the ass but still. > 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] [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=14519655#comment-14519655 ] EMR commented on DBUTILS-125: - Well, I can confirm that the version 12 drivers work fine against the database (using Netbeans builtin db browser), but not with dbutils, so I am at a loss. I did an lsof grep'ed for any ojdbc and the only thing that was open was ojdbc7.jar from the instantclient 12. > 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] [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=14519564#comment-14519564 ] EMR commented on DBUTILS-125: - So I ran a test. It seems to be something wrong with the 12.x driver. Since I got no where putting the query into the application, I created the complex query as a view on the server. I figured that this would at least work around the problem. However, it seems like there are still problems with the 12.x instant client... The driver version is in the paragraph/snippets. See my testing below: ojdbc6.jar: DEBUG (JavaApplication33.java:91) - Got query runner: org.apache.commons.dbutils.QueryRunner@114b6c2 JDBC driver version is > 11.2.0.2.0 < DEBUG (JavaApplication33.java:104) - Exec Query ERROR (JavaApplication33.java:110) - ORA-00904: "barcode": invalid identifier Query: SELECT DISTINCT * FROM schema1.reader_vw WHERE user_id = ? OR barcode = ? Parameters: [xx1, xx1] DEBUG (JavaApplication33.java:91) - Got query runner: org.apache.commons.dbutils.QueryRunner@1d016c9 JDBC driver version is > 12.1.0.2.0 < DEBUG (JavaApplication33.java:104) - Exec Query ERROR (JavaApplication33.java:110) - ORA-00942: table or view does not exist Query: SELECT DISTINCT * FROM schema1.reader_vw WHERE user_id = ? OR barcode = ? Parameters: [xx1, xx1] ## ojdbc7.jar (7 not available for v11.x): DEBUG (JavaApplication33.java:91) - Got query runner: org.apache.commons.dbutils.QueryRunner@d1993a JDBC driver version is > 12.1.0.2.0 < DEBUG (JavaApplication33.java:104) - Exec Query ERROR (JavaApplication33.java:110) - ORA-00942: table or view does not exist Query: SELECT DISTINCT * FROM schema1.reader_vw WHERE user_id = ? OR barcode = ? Parameters: [xx1, xx1] ## After correcting the query, with ojdbc6: DEBUG (JavaApplication33.java:89) - Got query runner: org.apache.commons.dbutils.QueryRunner@114b6c2 JDBC driver version is > 11.2.0.2.0 < DEBUG (JavaApplication33.java:102) - Exec Query DEBUG (EPerson.java:47) - EPerson() DEBUG (JavaApplication33.java:106) - xx1|IF88RAN|John Smith|null|Medical|D1381072|Infrastructure|D138108F DEBUG (JavaApplication33.java:89) - Got query runner: org.apache.commons.dbutils.QueryRunner@1d016c9 JDBC driver version is > 12.1.0.2.0 < DEBUG (JavaApplication33.java:102) - Exec Query ERROR (JavaApplication33.java:108) - ORA-00942: table or view does not exist Query: SELECT DISTINCT * FROM schema1.reader_vw WHERE user_id = ? OR barcode_id = ? Parameters: [xx1, xx1] > 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] [Commented] (LANG-1051) Add GitHub patch contribution advice to web page
[ https://issues.apache.org/jira/browse/LANG-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519320#comment-14519320 ] Benedikt Ritter commented on LANG-1051: --- Let's do this on a feature branch in git or even as PR on github. That's easier for reviewing IMHO. > Add GitHub patch contribution advice to web page > > > Key: LANG-1051 > URL: https://issues.apache.org/jira/browse/LANG-1051 > Project: Commons Lang > Issue Type: Improvement > Components: Website >Reporter: Duncan Jones >Assignee: Duncan Jones >Priority: Minor > Attachments: LANG-1051-V1.xml > > > We should extend our "Contributing Patches" web page to provide some advice > for users of GitHub. The Apache Karaf project [provides some good > advice|http://karaf.apache.org/manual/latest-2.3.x/developers-guide/github-contributions.html] > which might form a basis for our own. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CONFIGURATION-599) CombinedConfiguration fails to merge correctly when one configuration only contains one property
Martin Lindgren created CONFIGURATION-599:
-
Summary: 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] [Updated] (LANG-1051) Add GitHub patch contribution advice to web page
[ https://issues.apache.org/jira/browse/LANG-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated LANG-1051: - Attachment: LANG-1051-V1.xml First try at creating a Patch for this. Please notice that the JUnit link has been replaced by a Wikipedia article as it is leads to a 404. > Add GitHub patch contribution advice to web page > > > Key: LANG-1051 > URL: https://issues.apache.org/jira/browse/LANG-1051 > Project: Commons Lang > Issue Type: Improvement > Components: Website >Reporter: Duncan Jones >Assignee: Duncan Jones >Priority: Minor > Attachments: LANG-1051-V1.xml > > > We should extend our "Contributing Patches" web page to provide some advice > for users of GitHub. The Apache Karaf project [provides some good > advice|http://karaf.apache.org/manual/latest-2.3.x/developers-guide/github-contributions.html] > which might form a basis for our own. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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
]
Benedikt Ritter updated LANG-1121:
--
Fix Version/s: Patch Needed
> 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
>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] [Commented] (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:comment-tabpanel&focusedCommentId=14518798#comment-14518798
]
Benedikt Ritter commented on LANG-1121:
---
Patches welcome! Don't forget to include a junit test :-)
> 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
>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] [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=14519052#comment-14519052 ] Thomas Neidhart commented on MATH-1220: --- btw. is the implemented rejection method published anywhere? The most recent paper about sampling from a Zipf distribution that I could find is available here: http://epub.wu.ac.at/1176/ which refers to two older methods from Devroye and Dagpunar. > 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)
