[jira] [Closed] (MATH-747) Several Constructors for PoissonDistributionImpl are broken
[ https://issues.apache.org/jira/browse/MATH-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-747. -- changing status to closed as 3.0 has been released > Several Constructors for PoissonDistributionImpl are broken > --- > > Key: MATH-747 > URL: https://issues.apache.org/jira/browse/MATH-747 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Steve Appling >Priority: Critical > Fix For: 3.0 > > > Only the constructor PoissonDistributionImpl(double) seems to actually work. > All of the others cause a NullPointerException. The working one creates a > default NormalDistribution, but all of the others just leave the member > "normal" set to null and cause an NPE in the constructor. > I can't even find a work around to construct a PoissonDistributionImpl with > both a specified mean and an epsilon, since there is no way to set epsilon > after creation and the constructor PoissonDistributionImpl(double p, double > epsilon) does not work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe closed MATH-725.
--
changing status to closed as 3.0 has been released
> use initialized static final arrays, instead of initializing it in
> constructors
> ---
>
> Key: MATH-725
> URL: https://issues.apache.org/jira/browse/MATH-725
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Eldar Agalarov
>Priority: Minor
> Fix For: 3.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
> these arrays are unmodifiable, so we can replace this arrays initialization
> block
> final int w = 32;
> final int r = (k + w - 1) / w;
> this.v = new int[r];
> this.index = 0;
>
> // precompute indirection index tables. These tables are used for
> optimizing access
> // they allow saving computations like "(j + r - 2) % r" with costly
> modulo operations
> iRm1 = new int[r];
> iRm2 = new int[r];
> i1 = new int[r];
> i2 = new int[r];
> i3 = new int[r];
> for (int j = 0; j < r; ++j) {
> iRm1[j] = (j + r - 1) % r;
> iRm2[j] = (j + r - 2) % r;
> i1[j] = (j + m1) % r;
> i2[j] = (j + m2) % r;
> i3[j] = (j + m3) % r;
> }
> with inline initialized static final arrays.
> This is much better and faster implementation, freed from unnecessary costly
> calculations (such as %).
> Another solution: leave as is, but make all these arrays static.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-571) make FieldVector generic
[
https://issues.apache.org/jira/browse/MATH-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe closed MATH-571.
--
changing status to closed as 3.0 has been released
> make FieldVector generic
>
>
> Key: MATH-571
> URL: https://issues.apache.org/jira/browse/MATH-571
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Arne Plöse
>Priority: Minor
> Fix For: 3.0
>
>
> make FieldVector generic, so one can extend i.e. ArrayVieldVector to
> ArrayComplexVector an introduce new methoids (getReal())...
> if one has an equation complexvector.copy the original type
> ArrayComplexVector is lost thus access to getReal() is not possible.
> solution:
> public class InheritationTest {
> public static interface FieldVector, R extends
> FieldVector> {
> R copy();
> }
> public abstract static class ArrayFieldVectorExtendable FieldElement, R extends FieldVector> implements FieldVector,
> Serializable {
> protected T[] data;
> @Override
> public R copy() {
> return createVector(data);
> }
> abstract protected R createVector(T[] data);
> }
> public static class ArrayFieldVector> extends
> ArrayFieldVectorExtendable {
> @Override
> protected ArrayFieldVector createVector(T[] data) {
> ArrayFieldVector result = new ArrayFieldVector();
> result.data = data;
> return result;
> }
> }
> public static class ArrayComplexVector extends
> ArrayFieldVectorExtendable {
> @Override
> protected ArrayComplexVector createVector(Complex[] data) {
> ArrayComplexVector result = new ArrayComplexVector();
> result.data = data;
> return result;
> }
> public double[] getReal() {
> return null;
> }
> public double[] getImaginary() {
> return null;
> }
> }
> public void test() {
> ArrayComplexVector v = new ArrayComplexVector();
> ArrayComplexVector v1 = v.copy(); // FiledVector type survives ...
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-754) Additional Fraction Constructor
[ https://issues.apache.org/jira/browse/MATH-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-754. -- changing status to closed as 3.0 has been released > Additional Fraction Constructor > --- > > Key: MATH-754 > URL: https://issues.apache.org/jira/browse/MATH-754 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 > Environment: All >Reporter: Travis Hanna >Priority: Minor > Labels: features, newbie, patch > Fix For: 3.0 > > Attachments: math.patch > > > I'm writing some code which outputs fractional measurements meant for human > consumption. I need a constructor for Fraction which allows you to restrict > the denominators to a finite set. This is necessary due to the fact that > real-world tools are only available with certain fractions. For example, it's > next to impossible to find a ruler with 1/7 inch marked :). > I'm attaching a patch which implements the functionality. I've attempted to > mimic the style of the existing code as much as possible. One caveat: I don't > speak French so the french error message is a computer-generated translation > and probably very poor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-657) Division by zero
[
https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe closed MATH-657.
--
changing status to closed as 3.0 has been released
> Division by zero
>
>
> Key: MATH-657
> URL: https://issues.apache.org/jira/browse/MATH-657
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> In class {{Complex}}, division by zero always returns NaN. I think that it
> should return NaN only when the numerator is also {{ZERO}}, otherwise the
> result should be {{INF}}. See
> [here|http://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-632) NaN: Method "equals" in Complex not consistent with "==" for "double" primitive type
[
https://issues.apache.org/jira/browse/MATH-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe closed MATH-632.
--
changing status to closed as 3.0 has been released
> NaN: Method "equals" in Complex not consistent with "==" for "double"
> primitive type
>
>
> Key: MATH-632
> URL: https://issues.apache.org/jira/browse/MATH-632
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> The following tests show several contradictions:
> {code}
> final double a = Double.NaN;
> final double b = Double.NaN;
> Assert.assertFalse("a == b", a == b); // (1)
> Assert.assertEquals("a != b", a, b, Double.MIN_VALUE); // (2)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (3)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (4)
> final Double dA = Double.valueOf(a);
> final Double dB = Double.valueOf(b);
> Assert.assertFalse("dA == dB", dA.doubleValue() == dB.doubleValue()); // (5)
> Assert.assertTrue("!dA.equals(dB)", dA.equals(dB)); // (6)
> final Complex cA = new Complex(a, 0);
> final Complex cB = new Complex(b, 0);
> Assert.assertTrue("!cA.equals(cB)", cA.equals(cB)); // (7)
> {code}
> They all pass; thus:
> # "Double" does not behave as "double": (1) and (5) vs (6)
> # Two NaNs are almost equal for Junit: (2)
> # Two NaNs are never equal for MathUtils: (3) and (4)
> # Complex.NaN is consistent with Object "Double.valueOf(NaN)" (hence not with
> primitive "Double.NaN"): (7)
> This is quite confusing.
> In MathUtils, we chose to follow IEEE754 (and Java for primitive "double"),
> i.e. it is "correct" that assertion (1) is false. Do we want "Complex" to
> conform with this or with the inconsistent behaviour of "Double"?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-510) ParametricGaussianFunction Math > FastMath
[ https://issues.apache.org/jira/browse/MATH-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-510. -- changing status to closed as 3.0 has been released > ParametricGaussianFunction Math > FastMath > -- > > Key: MATH-510 > URL: https://issues.apache.org/jira/browse/MATH-510 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Ole Ersoy >Priority: Trivial > Fix For: 3.0 > > Attachments: ParametricGaussianFunction.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-549) Suggestion: Make PearsonsCorrelation.correlation(double[], double[]) static
[ https://issues.apache.org/jira/browse/MATH-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-549. -- changing status to closed as 3.0 has been released > Suggestion: Make PearsonsCorrelation.correlation(double[], double[]) static > --- > > Key: MATH-549 > URL: https://issues.apache.org/jira/browse/MATH-549 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Tomas Salfischberger >Priority: Minor > Fix For: 3.0 > > > Making PearsonsCorrelation.correlation(double[], double[]) static would allow > for calculating a correlation without instantiating a PearsonsCorrelation > object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-508) GaussianFunction - Math > FastMath
[ https://issues.apache.org/jira/browse/MATH-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-508. -- changing status to closed as 3.0 has been released > GaussianFunction - Math > FastMath > -- > > Key: MATH-508 > URL: https://issues.apache.org/jira/browse/MATH-508 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Ole Ersoy >Priority: Trivial > Fix For: 3.0 > > Attachments: GaussianFunction.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > Just changed Math to FastMath in the GaussianFunction implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-509) GaussianDerivativeFunction Math > FastMath
[ https://issues.apache.org/jira/browse/MATH-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe closed MATH-509. -- changing status to closed as 3.0 has been released > GaussianDerivativeFunction Math > FastMath > -- > > Key: MATH-509 > URL: https://issues.apache.org/jira/browse/MATH-509 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Ole Ersoy >Priority: Trivial > Fix For: 3.0 > > Attachments: GaussianDerivativeFunction.patch > > Original Estimate: 0h > Remaining Estimate: 0h > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-772) Change genetics component API to allow for different types of CrossoverPolicys and SelectionPolicys.
[ https://issues.apache.org/jira/browse/MATH-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237583#comment-13237583 ] Thomas Neidhart commented on MATH-772: -- Hi Reid, thanks again for your interest and contribution. We have to be a bit more careful with something like this, as this would affect the API, and we have just released version 3.0. Do you have a use-case where you would do a crossover from multiple parents? From my understanding this would be at least different from the general definition of a genetic algorithm. Thomas > Change genetics component API to allow for different types of > CrossoverPolicys and SelectionPolicys. > > > Key: MATH-772 > URL: https://issues.apache.org/jira/browse/MATH-772 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds >Reporter: Reid Hochstedler > Labels: api-change > Attachments: MATH-772.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-773) You should be able to run evolution simulation for a certain amount of time.
[ https://issues.apache.org/jira/browse/MATH-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237578#comment-13237578 ] Thomas Neidhart commented on MATH-773: -- Hi Reid, thanks for your contribution, this looks like a reasonable addition to the genetics package. After a short review of the patch, I think the endtime should not be determined at initialization time as this might lead to wrong results (as there might be a delay between creating the stopping condition and actually using it). Thomas > You should be able to run evolution simulation for a certain amount of time. > > > Key: MATH-773 > URL: https://issues.apache.org/jira/browse/MATH-773 > Project: Commons Math > Issue Type: Improvement >Reporter: Reid Hochstedler > Labels: genetics > Attachments: MATH-773.txt > > Original Estimate: 2h > Remaining Estimate: 2h > > You should be able to run your GeneticAlgorithm for a fixed amount of time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-247) [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error?
[ https://issues.apache.org/jira/browse/DAEMON-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237577#comment-13237577 ] Nick Williams commented on DAEMON-247: -- I can agree with that completely. It would certainly be the preferable behavior in our environment. And I imagine most other administrators of enterprise production systems would prefer it to fail loudly and obtrusively, instead of silently, when it has been configured incorrectly. > [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error? > -- > > Key: DAEMON-247 > URL: https://issues.apache.org/jira/browse/DAEMON-247 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.9 > Environment: Windows Server 2008 Service Pack 2, Java 6 update 31 and > 7 update 3 installed on same machine. > Tomcat 7.0.26 (which uses Daemon 1.0.9). >Reporter: Nick Williams >Assignee: Mladen Turk > Original Estimate: 1h > Remaining Estimate: 1h > > When running Tomcat as a service under Windows (thus using Daemon/procrun), > if you mess up the Java Virtual Machine path in the service configurator, it > defaults to the JAVA_HOME JRE, which I suppose is okay (but can wreak havoc > when you have multiple Java versions installed), except that it doesn't warn > you about it. It tells you about it through a DEBUG message, instead, so you > have to actually increase the logging detail and wade through more messages > to even realize it happened: > > [2012-03-20 16:32:41] [debug] ( prunsrv.c:1644) Commons Daemon procrun log > initialized > [2012-03-20 16:32:41] [info] ( prunsrv.c:1648) Commons Daemon procrun > (1.0.9.0 64-bit) started > [2012-03-20 16:32:41] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' > Service... > [2012-03-20 16:32:41] [debug] ( prunsrv.c:1345) Inside ServiceMain... > [2012-03-20 16:32:41] [info] ( prunsrv.c:1089) Starting service... > [2012-03-20 16:32:41] [debug] ( javajni.c:195 ) Invalid RuntimeLib > 'D:\Java\jdk6\jre\bin\server\jvm.dll' > [2012-03-20 16:32:41] [debug] ( javajni.c:197 ) Using Jre JavaHome > 'C:\Program Files\Java\jre7' > [2012-03-20 16:32:41] [debug] ( javajni.c:206 ) loading jvm 'C:\Program > Files\Java\jre7\bin\server\jvm.dll' > > After correcting the JVM path: > > [2012-03-20 16:46:13] [debug] ( prunsrv.c:1644) Commons Daemon procrun log > initialized > [2012-03-20 16:46:13] [info] ( prunsrv.c:1648) Commons Daemon procrun > (1.0.9.0 64-bit) started > [2012-03-20 16:46:13] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' > Service... > [2012-03-20 16:46:13] [debug] ( prunsrv.c:1345) Inside ServiceMain... > [2012-03-20 16:46:13] [info] ( prunsrv.c:1089) Starting service... > [2012-03-20 16:46:13] [debug] ( javajni.c:206 ) loading jvm 'C:\Program > Files\Java\jre6\bin\server\jvm.dll' > IMO, this message should be a warning or even an error (preferable) so that > server admins know right off the bat that they've done something wrong. > Otherwise bad things might happen. > Whether or not it should quit instead of defaulting to the system default JRE > is a different discussion, but I think the message should at least be changed > to a warning or an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-85) Allow comments to be returned in CSVRecord
Allow comments to be returned in CSVRecord -- Key: CSV-85 URL: https://issues.apache.org/jira/browse/CSV-85 Project: Commons CSV Issue Type: Improvement Reporter: Sebb It might be useful to provide a comment field in the CSVRecord class. This would be null if no comment is present for that record. A line consisting of only a comment would have a size() of 0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-84) Comment handling
[
https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237549#comment-13237549
]
Sebb commented on CSV-84:
-
At present (r1304503), the comment introducer is not recognised whilst
processing a value.
It is only recognised at the start of a value.
This seems wrong, as it makes it impossible to add a trailing comment to the
end of a record without adding a preceeding delimiter. This is not consistent,
see below:
{code}
# No comment following, 4 values found
a,b,c,d
d,e,f,g# comment treated as part of 4th value
h,i,j,k,# this will be recognised as a comment following 4 fields
l,m,n,o,
# previous line should have 5 fields but actually gets merged to previous line.
{code}
Comments currently only work correctly at the start of a record.
> Comment handling
>
>
> Key: CSV-84
> URL: https://issues.apache.org/jira/browse/CSV-84
> Project: Commons CSV
> Issue Type: New Feature
>Reporter: Sebb
>
> Comment handling is not currently fully documented / tested.
> There are several possible situations:
> 1) trailing comment following one or more values
> 2) comment marker starts in the first column
> 3) comment marker starts in the first non-whitespace column
> How should these be handled?
> 1) The trailing comment should be ignored
> 2) Entire line should be ignored, i.e. don't treat it as a blank line
> 3) This is trickier: if whitespace is being trimmed, treat as 2, else treat
> as 1, i.e. there is a single value containing whitespace
> It might also be useful to consider returning comments to the application
> program as part of CSVRecord.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-247) [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error?
[ https://issues.apache.org/jira/browse/DAEMON-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237540#comment-13237540 ] Mladen Turk commented on DAEMON-247: Not sure if [error] only would be enough. Think we should exit as well in case explicit JVM path was given and not found. > [debug] ( javajni.c:195 ) Invalid RuntimeLib should be a warning or error? > -- > > Key: DAEMON-247 > URL: https://issues.apache.org/jira/browse/DAEMON-247 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.9 > Environment: Windows Server 2008 Service Pack 2, Java 6 update 31 and > 7 update 3 installed on same machine. > Tomcat 7.0.26 (which uses Daemon 1.0.9). >Reporter: Nick Williams > Original Estimate: 1h > Remaining Estimate: 1h > > When running Tomcat as a service under Windows (thus using Daemon/procrun), > if you mess up the Java Virtual Machine path in the service configurator, it > defaults to the JAVA_HOME JRE, which I suppose is okay (but can wreak havoc > when you have multiple Java versions installed), except that it doesn't warn > you about it. It tells you about it through a DEBUG message, instead, so you > have to actually increase the logging detail and wade through more messages > to even realize it happened: > > [2012-03-20 16:32:41] [debug] ( prunsrv.c:1644) Commons Daemon procrun log > initialized > [2012-03-20 16:32:41] [info] ( prunsrv.c:1648) Commons Daemon procrun > (1.0.9.0 64-bit) started > [2012-03-20 16:32:41] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' > Service... > [2012-03-20 16:32:41] [debug] ( prunsrv.c:1345) Inside ServiceMain... > [2012-03-20 16:32:41] [info] ( prunsrv.c:1089) Starting service... > [2012-03-20 16:32:41] [debug] ( javajni.c:195 ) Invalid RuntimeLib > 'D:\Java\jdk6\jre\bin\server\jvm.dll' > [2012-03-20 16:32:41] [debug] ( javajni.c:197 ) Using Jre JavaHome > 'C:\Program Files\Java\jre7' > [2012-03-20 16:32:41] [debug] ( javajni.c:206 ) loading jvm 'C:\Program > Files\Java\jre7\bin\server\jvm.dll' > > After correcting the JVM path: > > [2012-03-20 16:46:13] [debug] ( prunsrv.c:1644) Commons Daemon procrun log > initialized > [2012-03-20 16:46:13] [info] ( prunsrv.c:1648) Commons Daemon procrun > (1.0.9.0 64-bit) started > [2012-03-20 16:46:13] [info] ( prunsrv.c:1561) Running 'gr01in01tc70' > Service... > [2012-03-20 16:46:13] [debug] ( prunsrv.c:1345) Inside ServiceMain... > [2012-03-20 16:46:13] [info] ( prunsrv.c:1089) Starting service... > [2012-03-20 16:46:13] [debug] ( javajni.c:206 ) loading jvm 'C:\Program > Files\Java\jre6\bin\server\jvm.dll' > IMO, this message should be a warning or even an error (preferable) so that > server admins know right off the bat that they've done something wrong. > Otherwise bad things might happen. > Whether or not it should quit instead of defaulting to the system default JRE > is a different discussion, but I think the message should at least be changed > to a warning or an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-84) Comment handling
Comment handling Key: CSV-84 URL: https://issues.apache.org/jira/browse/CSV-84 Project: Commons CSV Issue Type: New Feature Reporter: Sebb Comment handling is not currently fully documented / tested. There are several possible situations: 1) trailing comment following one or more values 2) comment marker starts in the first column 3) comment marker starts in the first non-whitespace column How should these be handled? 1) The trailing comment should be ignored 2) Entire line should be ignored, i.e. don't treat it as a blank line 3) This is trickier: if whitespace is being trimmed, treat as 2, else treat as 1, i.e. there is a single value containing whitespace It might also be useful to consider returning comments to the application program as part of CSVRecord. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237481#comment-13237481 ] Moandji Ezana edited comment on DBUTILS-88 at 3/24/12 8:53 AM: --- Does anything need to happen for this issue and DBUTILS-87 to be committed? was (Author: mwanji): Does anything need to happen for this issue and DB-UTILS-87 to be committed? > Make AsyncQueryRunner be a decorator around a QueryRunner > - > > Key: DBUTILS-88 > URL: https://issues.apache.org/jira/browse/DBUTILS-88 > Project: Commons DbUtils > Issue Type: Task >Reporter: Moandji Ezana >Priority: Minor > Attachments: AsyncQueryRunner_wraps_QueryRunner.txt, > DBUTILS-88v1.patch, DBUTILS-88v2.patch > > > AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be > possible for AsyncQueryRunner to simply decorate a QueryRunner with async > functionality, in the same way a BufferedInputStream might decorate an > InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237481#comment-13237481 ] Moandji Ezana commented on DBUTILS-88: -- Does anything need to happen for this issue and DB-UTILS-87 to be committed? > Make AsyncQueryRunner be a decorator around a QueryRunner > - > > Key: DBUTILS-88 > URL: https://issues.apache.org/jira/browse/DBUTILS-88 > Project: Commons DbUtils > Issue Type: Task >Reporter: Moandji Ezana >Priority: Minor > Attachments: AsyncQueryRunner_wraps_QueryRunner.txt, > DBUTILS-88v1.patch, DBUTILS-88v2.patch > > > AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be > possible for AsyncQueryRunner to simply decorate a QueryRunner with async > functionality, in the same way a BufferedInputStream might decorate an > InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
