[jira] [Commented] (LANG-781) Null-Check to variable Object parameters - ObjectUtils.isAnyNull
[ https://issues.apache.org/jira/browse/LANG-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022695#comment-15022695 ] ASF GitHub Bot commented on LANG-781: - Github user vanta commented on the pull request: https://github.com/apache/commons-lang/pull/108#issuecomment-159023629 Any update on this? > Null-Check to variable Object parameters - ObjectUtils.isAnyNull > > > Key: LANG-781 > URL: https://issues.apache.org/jira/browse/LANG-781 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 3.1 >Reporter: Sandro Lehmann >Priority: Minor > Labels: patch > Fix For: Discussion > > Attachments: ObjectUtils.java.patch, ObjectUtilsTest.java.patch > > > Sometimes it would be very comfortable, to test a few objects to null. > Instead of writing if(obj1==null || obj2==null || ...), using a method like > isAnyNull(obj1, obj2, ...) would be much better. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang pull request: LANG-781 Added methods to ObjectUtils c...
Github user vanta commented on the pull request: https://github.com/apache/commons-lang/pull/108#issuecomment-159023629 Any update on this? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (CSV-164) Support duplicate header names
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021800#comment-15021800 ] Michael Osipov commented on CSV-164: How is get is supposed to work on a map when the column name is not unique? > Support duplicate header names > -- > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-164) Support duplicate header names
[
https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021924#comment-15021924
]
Romain Manni-Bucau commented on CSV-164:
This is what I proposed early: if you do get("duplicatedColumnName") then you
should fail but get("uniqueColumnName") should still work. Doesnt remove the
access (parse) feature since you can still access it by index.
Typically in batchee mapping we have a thin layer on top of [csv] where you can
map CSV on an object either by index or name. If you use name then you define
header names but index access is priviledged over name access which makes this
case pretty smooth: in
https://github.com/apache/incubator-batchee/blob/master/extensions/commons-csv/src/main/java/org/apache/batchee/csv/mapper/DefaultMapper.java#L89
the values of fieldByPosition and fieldByName are unique (ie fieldByName
doesnt have any duplicate with fieldByPosition) to guaratee all of this to work.
The access by header name is a nice API most of the time but not the way CSV
really works (column index by definition) so I like this API but it has some
limits we hit with this issue.
> Support duplicate header names
> --
>
> Key: CSV-164
> URL: https://issues.apache.org/jira/browse/CSV-164
> Project: Commons CSV
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> nothing prevents a CSV to have the same time the same header name so
> validation at the end of org.apache.commons.csv.CSVFormat#validate should
> likely disappear or should support a flag to disable it
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-164) Support duplicate header names
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CSV-164: --- Affects Version/s: 1.2 > Support duplicate header names > -- > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-164) Support duplicate header names
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated CSV-164: --- Summary: Support duplicate header names (was: support duplicate headers) > Support duplicate header names > -- > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CSV-164) Support duplicate header names
[
https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021800#comment-15021800
]
Michael Osipov edited comment on CSV-164 at 11/23/15 9:10 AM:
--
How is {{get}} is supposed to work on a map when the column name is not unique?
was (Author: michael-o):
How is get is supposed to work on a map when the column name is not unique?
> Support duplicate header names
> --
>
> Key: CSV-164
> URL: https://issues.apache.org/jira/browse/CSV-164
> Project: Commons CSV
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> nothing prevents a CSV to have the same time the same header name so
> validation at the end of org.apache.commons.csv.CSVFormat#validate should
> likely disappear or should support a flag to disable it
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-164) support duplicate headers
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021734#comment-15021734 ] Romain Manni-Bucau commented on CSV-164: Format is used for both parsing and printing. In the issue description I didnt specifically spoke about parsing. I have a chain where i read, change few field values then write the file using the same format for instance. > support duplicate headers > - > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-309) ThreadLocal memory leak in DefaultFileContent
[ https://issues.apache.org/jira/browse/VFS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022182#comment-15022182 ] Carl Krick commented on VFS-309: Hello, Do we know when this is going to be released? Regards > ThreadLocal memory leak in DefaultFileContent > - > > Key: VFS-309 > URL: https://issues.apache.org/jira/browse/VFS-309 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: Tomcat servlet container >Reporter: jontro >Assignee: Bernd Eckenfels >Priority: Blocker > Fix For: 2.1 > > Attachments: close-on-close_v02.patch, > threadlocal_setNull_vs_remove_bug.patch > > > When using commons vfs in a servlet container the ThreadLocal values stored > will not be released once the request finishes. > There needs to be a method to clear these values otherwise the data will leak > into the next request. > This was detected with tomcat 6.0.26. Upon undeploying an app that uses > commons vfs tomcat detects the leaks with a huge amount of the following > messages: > A web application created a ThreadLocal with key of type > [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@52fb241d]) and a value > of type [org.apache.commons.vfs.provider.FileContentThreadData] (value > [org.apache.commons.vfs.provider.FileContentThreadData@6600167a]) but failed > to remove it when the web application was stopped. To prevent a memory leak, > the ThreadLocal has been forcibly removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1294) Data race PolynomialUtils::buildPolynomial
[ https://issues.apache.org/jira/browse/MATH-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1294. --- Resolution: Fixed Fix Version/s: 3.6 4.0 Thanks for the report. It has been fixed in the following commits: * 3.6: fe23c9b04 * 4.0: 487ac1980 The synchronization is now also on the coefficient list itself (which must be non-null), and thus there should be a slight performance improvement when creating different polynomials in multiple threads. > Data race PolynomialUtils::buildPolynomial > -- > > Key: MATH-1294 > URL: https://issues.apache.org/jira/browse/MATH-1294 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Kamil Włodarczyk >Priority: Minor > Labels: easyfix, performance > Fix For: 4.0, 3.6 > > > If you run PolynomialUtilsTest methods concurrently there will occur problem > with ComparisonFailure due to incorrect building of coefficient list. > https://github.com/apache/commons-math/blob/master/src/main/java/org/apache/commons/math4/analysis/polynomials/PolynomialsUtils.java#L368 > should be in synchronized block. Explanation: polynomial of given degree can > be created by other thread and when primary thread access synchronized > block, there is already created coefficients for this degree, therefore no > coefficients should be added to coefficients list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1254) Unit test CorrelatedRandomVectorGeneratorTest is flaky
[ https://issues.apache.org/jira/browse/MATH-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023247#comment-15023247 ] Thomas Neidhart commented on MATH-1254: --- Luc has already changed the test to use a fixed seed. Increasing the number of samples also improves the robustness of the test. > Unit test CorrelatedRandomVectorGeneratorTest is flaky > -- > > Key: MATH-1254 > URL: https://issues.apache.org/jira/browse/MATH-1254 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Otmar Ertl >Priority: Minor > Attachments: seed628.patch > > > CorrelatedRandomVectorGeneratorTest.testSampleWithZeroCovariance sometimes > fails. The failure can be reproduced by setting the seed of the > JDKRandomGenerator in createSampler equal to 628. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-163) add a basic mapping feature
[
https://issues.apache.org/jira/browse/CSV-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023197#comment-15023197
]
Romain Manni-Bucau commented on CSV-163:
so what would be a good place @asf since it is not a single project need (= it
is a "commons" need)? Very few modern application use low level API (get()).
> add a basic mapping feature
> ---
>
> Key: CSV-163
> URL: https://issues.apache.org/jira/browse/CSV-163
> Project: Commons CSV
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> would be neat to be able to map records instead of using string based access:
> {code}
> public class MyRecored {
> @Csv(position = 1) String name;
> @Csv(name = "city") String city;
> // ...
> }
> {code}
> Think it is acceptable to support only basic types (primitives + String/Date
> to start). This constraint would keep the code light and simple - no
> converter - but easier to use than "map"-like API .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DAEMON-339) Patch for commons-daemon 1.0.15 to avoid shutdown failures
John Wehle created DAEMON-339: - Summary: Patch for commons-daemon 1.0.15 to avoid shutdown failures Key: DAEMON-339 URL: https://issues.apache.org/jira/browse/DAEMON-339 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.15 Environment: Multiple UNIX platforms ... E.g.: Red Hat ES 6 Solaris 10 x64 Reporter: John Wehle Priority: Minor We've seen situations on UNIX where JSVC will fail to shutdown when requested ... in at least one case this caused the machine to hang during shutdown. On UNIX JSVC automatically restarts the JVM if it crashes. Currently this means that if the JVM crashes after receiving a shutdown request (i.e. a SIGINT), then it's restarted by the controller which is not what's desired. The enclosed patch propagates the termination request from the JVM to the controller so that the controller knows not to schedule a restart thus allowing JSVC to actually terminate. Granted this doesn't fix the underlying problem of the JVM crashing during shutdown, however that's a separate (potentially application specific) issue. Tested by using a dummy JAVA service containing an endless loop in the shutdown code. Test sequence was: jsvc ... -verbose -debug hello.MyDaemon kill -INT `cat pidfile` # notice that output showed shutdown running kill -BUS `cat pidfile` # notice that prior to patch output showed restart being scheduled -- John Wehle -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DAEMON-339) Patch for commons-daemon 1.0.15 to avoid shutdown failures
[ https://issues.apache.org/jira/browse/DAEMON-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wehle updated DAEMON-339: -- Attachment: jsvc-shutdown.txt Patch for the problem. > Patch for commons-daemon 1.0.15 to avoid shutdown failures > -- > > Key: DAEMON-339 > URL: https://issues.apache.org/jira/browse/DAEMON-339 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.15 > Environment: Multiple UNIX platforms ... E.g.: > Red Hat ES 6 > Solaris 10 x64 >Reporter: John Wehle >Priority: Minor > Attachments: jsvc-shutdown.txt > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > We've seen situations on UNIX where JSVC will fail to shutdown when > requested ... in at least one case this caused the machine to hang > during shutdown. > On UNIX JSVC automatically restarts the JVM if it crashes. Currently > this means that if the JVM crashes after receiving a shutdown request > (i.e. a SIGINT), then it's restarted by the controller which is not > what's desired. > The enclosed patch propagates the termination request from the JVM to > the controller so that the controller knows not to schedule a restart > thus allowing JSVC to actually terminate. > Granted this doesn't fix the underlying problem of the JVM crashing > during shutdown, however that's a separate (potentially application > specific) issue. > Tested by using a dummy JAVA service containing an endless loop in > the shutdown code. Test sequence was: > jsvc ... -verbose -debug hello.MyDaemon > kill -INT `cat pidfile` > # notice that output showed shutdown running > kill -BUS `cat pidfile` > # notice that prior to patch output showed restart being scheduled > -- John Wehle -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty
[ https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023175#comment-15023175 ] Michael Osipov commented on JXPATH-183: --- Did you some micro-benchmarks with an appropriate file? Can you share where the bottleneck is? Did you check it with VisualVM or alike? > XMLGregorianCalendar existence adding a lot of performance penalty > -- > > Key: JXPATH-183 > URL: https://issues.apache.org/jira/browse/JXPATH-183 > Project: Commons JXPath > Issue Type: Improvement >Affects Versions: 1.3 > Environment: Windows 7, Amazon Unix, Weblogic >Reporter: Ganna Shmatova > Labels: performance > > We're using JXPath to parse some input from a client. When they give us a > valid date it gets transformed from a SOAP message into Java objects. When > this happens JXPath queries suddenly take 1-8 seconds more (depending on > system -- the optimized system it's 1 second, dev & test machines it's 8). > Kicker is, we don't even look for this field. Just its existence does it. > (we've quickfixed to omit the xml tags before the string is parsed into Java > for now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1253) Skewness could get more precision from slightly reordered code.
[
https://issues.apache.org/jira/browse/MATH-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023289#comment-15023289
]
Thomas Neidhart commented on MATH-1253:
---
just ftr: I did some tests with octave and scipy, and both return NaN or
overflow for the input.
> Skewness could get more precision from slightly reordered code.
> ---
>
> Key: MATH-1253
> URL: https://issues.apache.org/jira/browse/MATH-1253
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Bill Murphy
>Priority: Minor
>
> In Skewness.java, approx line 180, there is code like:
> {noformat}
> double accum3 = 0.0;
> for (int i = begin; i < begin + length; i++) {
> final double d = values[i] - m;
> accum3 += d * d * d;
> }
> accum3 /= variance * FastMath.sqrt(variance);
> {noformat}
> If the division was moved into the for loop, accum3 would be less likely to
> overflow to Infinity (or -Infinity). This might allow computation to return a
> result in a case such as:
> {noformat}
> double[] numArray = { 1.234E11, 1.234E51, 1.234E101, 1.234E151 };
> Skewnessskew = new Skewness();
> doublesk = skew.evaluate( numArray );
> {noformat}
> Currently, this returns NaN, but I'd prefer it returned approx
> 1.154700538379252.
> The change I'm proposing would have the code instead read like:
> {noformat}
> double accum3 = 0.0;
> double divisor = variance * FastMath.sqrt(variance);
> for (int i = begin; i < begin + length; i++) {
> final double d = values[i] - m;
> accum3 += d * d * d / divisor;
> }
> {noformat}
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-163) add a basic mapping feature
[
https://issues.apache.org/jira/browse/CSV-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023172#comment-15023172
]
Michael Osipov commented on CSV-163:
I truly share your opinion. Everyone can write a shim between JPA and CSV.
> add a basic mapping feature
> ---
>
> Key: CSV-163
> URL: https://issues.apache.org/jira/browse/CSV-163
> Project: Commons CSV
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> would be neat to be able to map records instead of using string based access:
> {code}
> public class MyRecored {
> @Csv(position = 1) String name;
> @Csv(name = "city") String city;
> // ...
> }
> {code}
> Think it is acceptable to support only basic types (primitives + String/Date
> to start). This constraint would keep the code light and simple - no
> converter - but easier to use than "map"-like API .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-184) Update to Java 7
[ https://issues.apache.org/jira/browse/JXPATH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023162#comment-15023162 ] Michael Osipov commented on JXPATH-184: --- Very good issue, we should start with generics first.. > Update to Java 7 > > > Key: JXPATH-184 > URL: https://issues.apache.org/jira/browse/JXPATH-184 > Project: Commons JXPath > Issue Type: Task >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JXPATH-184) Update to Java 7
[ https://issues.apache.org/jira/browse/JXPATH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023162#comment-15023162 ] Michael Osipov edited comment on JXPATH-184 at 11/23/15 9:54 PM: - Very good issue, we should start with generics first...but do not introduce such breaking changes in a minor release. This is work for 2.0. was (Author: michael-o): Very good issue, we should start with generics first.. > Update to Java 7 > > > Key: JXPATH-184 > URL: https://issues.apache.org/jira/browse/JXPATH-184 > Project: Commons JXPath > Issue Type: Task >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JXPATH-184) Update to Java 7
[ https://issues.apache.org/jira/browse/JXPATH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated JXPATH-184: -- Fix Version/s: (was: 1.4) > Update to Java 7 > > > Key: JXPATH-184 > URL: https://issues.apache.org/jira/browse/JXPATH-184 > Project: Commons JXPath > Issue Type: Task >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
