[jira] [Updated] (MATH-449) Storeless covariance
[
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Meyer updated MATH-449:
---
Attachment: MATH-449.patch
This patch includes three new classes, StorelessCovariance.java,
StorelessCovarianceMatrix.java, and StorelessCovarianceTest.java. For the test
cases, I used the same data as in CovarianceTest.java. However, I reduced the
accuracy to 10E-7 because the tests failed the Longley data when using 10E-9.
> Storeless covariance
>
>
> Key: MATH-449
> URL: https://issues.apache.org/jira/browse/MATH-449
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Patrick Meyer
> Fix For: 3.1
>
> Attachments: MATH-449.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Currently there is no storeless version for computing the covariance.
> However, Pebay (2008) describes algorithms for on-line covariance
> computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have
> provided a simple class for implementing this algorithm. It would be nice to
> have this integrated into org.apache.commons.math.stat.correlation.Covariance.
> {code}
> //This code is granted for inclusion in the Apache Commons under the terms of
> the ASL.
> public class StorelessCovariance{
> private double deltaX = 0.0;
> private double deltaY = 0.0;
> private double meanX = 0.0;
> private double meanY = 0.0;
> private double N=0;
> private Double covarianceNumerator=0.0;
> private boolean unbiased=true;
> public Covariance(boolean unbiased){
> this.unbiased = unbiased;
> }
> public void increment(Double x, Double y){
> if(x!=null & y!=null){
> N++;
> deltaX = x - meanX;
> deltaY = y - meanY;
> meanX += deltaX/N;
> meanY += deltaY/N;
> covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
> }
>
> }
> public Double getResult(){
> if(unbiased){
> return covarianceNumerator/(N-1.0);
> }else{
> return covarianceNumerator/N;
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PRIMITIVES-16) Bug in class#ShortList/DoubleList (?) with reproducible JUnit test
[
https://issues.apache.org/jira/browse/PRIMITIVES-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086729#comment-13086729
]
Sai Zhang commented on PRIMITIVES-16:
-
Hi,
Here is the latest output of our documentation inference tool. It renames all
variable names and (hopefully) makes the test easier to read.
The comments generated by our research tool are shown in the form of:
{code}
//Test passes if: (it indicates changes that will make a failed test pass)
{code}
Each piece of comments (not the combination of them) provides a way to correct
the failed test.
We hope such additional information will help developers understand/fix the
test faster/better.
So, it would be great if anyone can take a look at the reported bug to:
(1) confirm is it a real bug?
(2) is such comment information useful? If not, please give us feedback so we
can do our best
to improve our tool!
Thank you!
-Sai
{code}
import org.apache.commons.collections.primitives.AbstractCharCollection;
import org.apache.commons.collections.primitives.CharList;
import org.apache.commons.collections.primitives.adapters.ListDoubleList;
import java.util.List;
import org.apache.commons.collections.primitives.ShortCollections;
import org.apache.commons.collections.primitives.DoubleCollections;
import java.lang.String;
import org.apache.commons.collections.primitives.DoubleList;
import org.apache.commons.collections.primitives.RandomAccessCharList;
import org.apache.commons.collections.primitives.CharCollection;
import org.apache.commons.collections.primitives.ShortList;
import org.apache.commons.collections.primitives.adapters.CharListList;
import org.apache.commons.collections.primitives.adapters.DoubleListList;
import org.apache.commons.collections.primitives.ArrayCharList;
import org.apache.commons.collections.primitives.adapters.ListShortList;
import junit.framework.TestCase;
public class ApachePrimitive_Documented_Test_Pretty extends TestCase {
public void test0() {
Integer i0 = new Integer(10);
ArrayCharList arrayCharList0 = new ArrayCharList(i0);
Integer i1 = new Integer(10);
ArrayCharList arrayCharList1 = new ArrayCharList(i1);
Character char0 = new Character('#');
int i2 = arrayCharList1.indexOf(char0);
Character char1 = new Character('4');
boolean b0 = arrayCharList1.contains(char1);
CharListList charListList0 = new CharListList((CharList)arrayCharList1);
boolean b1 = arrayCharList0.retainAll((CharCollection)arrayCharList1);
String str0 = arrayCharList1.toString();
char[] char_array0 = new char[] { };
char[] char_array1 = arrayCharList1.toArray(char_array0);
ArrayCharList arrayCharList2 = new ArrayCharList();
Integer i3 = new Integer(10);
ArrayCharList arrayCharList3 = new ArrayCharList(i3);
Character char2 = new Character('#');
int i4 = arrayCharList3.indexOf(char2);
int i5 = arrayCharList2.indexOf(char2);
boolean b2 = arrayCharList1.add(char2);
Integer i6 = new Integer(10);
ArrayCharList arrayCharList4 = new ArrayCharList(i6);
Integer i7 = new Integer(10);
ArrayCharList arrayCharList5 = new ArrayCharList(i7);
Character char3 = new Character('#');
int i8 = arrayCharList5.indexOf(char3);
Character char4 = new Character('4');
boolean b3 = arrayCharList5.contains(char4);
CharListList charListList1 = new CharListList((CharList)arrayCharList5);
boolean b4 = arrayCharList4.retainAll((CharCollection)arrayCharList5);
List list0 = CharListList.wrap((CharList)arrayCharList5);
Integer i9 = new Integer(10);
ArrayCharList arrayCharList6 = new ArrayCharList(i9);
Character char5 = new Character('#');
int i10 = arrayCharList6.indexOf(char5);
boolean b5 = arrayCharList5.containsAll((CharCollection)arrayCharList6);
Integer i11 = new Integer(10);
ArrayCharList arrayCharList7 = new ArrayCharList(i11);
Integer i12 = new Integer(10);
ArrayCharList arrayCharList8 = new ArrayCharList(i12);
Character char6 = new Character('#');
int i13 = arrayCharList8.indexOf(char6);
Character char7 = new Character('4');
boolean b6 = arrayCharList8.contains(char7);
CharListList charListList2 = new CharListList((CharList)arrayCharList8);
boolean b7 = arrayCharList7.retainAll((CharCollection)arrayCharList8);
boolean b8 = arrayCharList6.removeAll((CharCollection)arrayCharList8);
int i14 = arrayCharList8.size();
char char8 = arrayCharList1.get(i14);
Integer i15 = new Integer(10);
ArrayCharList arrayCharList9 = new ArrayCharList(i15);
Integer i16 = new Integer(10);
ArrayCharList arrayCharList10 = new ArrayCharList(i16);
Character char9 = new Character('#');
int i17 = arrayCharList10.indexOf(char9);
Character char10 = new Character('4');
boolean b9 = arrayCharList10.contains(char10);
CharListList charListList3 = new CharListList((CharList)arrayCharList10)
[jira] [Commented] (COLLECTIONS-373) Bug in class#ListOrderedSet with reproducible JUnit test
[
https://issues.apache.org/jira/browse/COLLECTIONS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086724#comment-13086724
]
Sai Zhang commented on COLLECTIONS-373:
---
Hi,
Here is the latest output of our documentation inference tool. It renames all
variable names and (hopefully) makes the test easier to read.
The comments generated by our research tool are shown in the form of:
{code}
//Test passes if: (it indicates changes that will make a failed test pass)
{code}
Each piece of comments (not the combination of them) provides a way to correct
the failed test.
We hope such additional information will help developers understand/fix the
test faster/better.
So, it would be great if anyone can take a look at the reported bug to:
(1) confirm is it a real bug?
(2) is such comment information useful? If not, please give us feedback so we
can do our best
to improve our tool!
Thank you!
-Sai
{code}
public void test0() {
ListOrderedSet listOrderedSet0 = new ListOrderedSet();
List list0 = listOrderedSet0.asList();
List list1 = listOrderedSet0.asList();
listOrderedSet0.clear();
Integer i0 = new Integer((-1));
ListOrderedSet listOrderedSet1 = new ListOrderedSet();
Integer i1 = new Integer((-1));
ListOrderedSet listOrderedSet2 = new ListOrderedSet();
List list2 = listOrderedSet2.asList();
ListOrderedSet listOrderedSet3 =
ListOrderedSet.decorate((Set)listOrderedSet2);
boolean b0 = listOrderedSet1.addAll(i1, (Collection)listOrderedSet2);
boolean b1 = listOrderedSet0.addAll(i0, (Collection)listOrderedSet2);
ListOrderedSet listOrderedSet4 = new ListOrderedSet();
List list3 = listOrderedSet4.asList();
List list4 = listOrderedSet4.asList();
ListOrderedSet listOrderedSet5 = new ListOrderedSet();
List list5 = listOrderedSet5.asList();
ListOrderedSet listOrderedSet6 =
ListOrderedSet.decorate((Set)listOrderedSet5);
ListOrderedSet listOrderedSet7 = new ListOrderedSet();
List list6 = listOrderedSet7.asList();
ListOrderedSet listOrderedSet8 =
ListOrderedSet.decorate((Set)listOrderedSet5, list6);
boolean b2 = listOrderedSet4.containsAll((Collection)list6);
ListOrderedSet listOrderedSet9 =
ListOrderedSet.decorate((Set)listOrderedSet0, list6);
ListOrderedSet listOrderedSet10 = new ListOrderedSet();
int i2 = listOrderedSet10.size();
boolean b3 = listOrderedSet0.add((Object)i2);
//Test passes if line is: Integer s0 = new Integer(0)
Short s0 = new Short((short)1);
//Test passes if s0 is not added to listOrderedSet0
boolean b4 = listOrderedSet0.add((Object)s0);
ListOrderedSet listOrderedSet11 = new ListOrderedSet();
List list7 = listOrderedSet11.asList();
List list8 = listOrderedSet11.asList();
listOrderedSet11.clear();
Integer i3 = new Integer((-1));
ListOrderedSet listOrderedSet12 = new ListOrderedSet();
Integer i4 = new Integer((-1));
ListOrderedSet listOrderedSet13 = new ListOrderedSet();
List list9 = listOrderedSet13.asList();
ListOrderedSet listOrderedSet14 =
ListOrderedSet.decorate((Set)listOrderedSet13);
boolean b5 = listOrderedSet12.addAll(i4, (Collection)listOrderedSet13);
boolean b6 = listOrderedSet11.addAll(i3, (Collection)listOrderedSet13);
ListOrderedSet listOrderedSet15 = new ListOrderedSet();
List list10 = listOrderedSet15.asList();
List list11 = listOrderedSet15.asList();
ListOrderedSet listOrderedSet16 = new ListOrderedSet();
List list12 = listOrderedSet16.asList();
ListOrderedSet listOrderedSet17 =
ListOrderedSet.decorate((Set)listOrderedSet16);
ListOrderedSet listOrderedSet18 = new ListOrderedSet();
List list13 = listOrderedSet18.asList();
ListOrderedSet listOrderedSet19 =
ListOrderedSet.decorate((Set)listOrderedSet16, list13);
boolean b7 = listOrderedSet15.containsAll((Collection)list13);
ListOrderedSet listOrderedSet20 =
ListOrderedSet.decorate((Set)listOrderedSet11, list13);
ListOrderedSet listOrderedSet21 = new ListOrderedSet();
int i5 = listOrderedSet21.size();
//Test passes if i5 is not added to listOrderedSet11
boolean b8 = listOrderedSet11.add((Object)i5);
boolean b9 = listOrderedSet0.removeAll((Collection)listOrderedSet11);
// Checks the contract: equals-hashcode on listOrderedSet0 and
listOrderedSet20
assertTrue("Contract failed: equals-hashcode on listOrderedSet0 and
listOrderedSet20", listOrderedSet0.equals(listOrderedSet20) ?
listOrderedSet0.hashCode() == listOrderedSet20.hashCode() : true);
// Checks the contract: equals-hashcode on listOrderedSet9 and
listOrderedSet20
assertTrue("Contract failed: equals-hashcode on listOrderedSet9 and
listOrderedSet20", listOrderedSet9.equals(listOrderedSet20) ?
listOrderedSet9.hashCode() == listOrderedSet20.hashCode() : true);
// Checks the contract: equals-hashcode on listOrder
[jira] [Updated] (MATH-553) Bug in class# org.apache.commons.math.dfp.Dfp / org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
[
https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sai Zhang updated MATH-553:
---
Comment: was deleted
(was: Hi Luc:
(sorry for the late reply. I thought my previous email was sent out, but found
it
still lies in my draft box)
I agree that it does not make sense to compare 2 NaNs. However, I think
two Java objects can still be compared, and the code maybe improved to
avoid violation of the Java specification.
For the problem revealed in the test case, I suggest to fix this bug by adding
a comparison to
*this* object itself. Doing so will avoid "var.equals(var)" returns false.
and prevent Java containers becoming unstable, when they are containing a Dfp
object.
A suggested fix is:
{code}
Class: org.apache.commons.math.dfp.Dfp
@Override
public boolean equals(final Object other) {
if(this == other) {
return true;
}
// all existing code goes here
}
{code}
For the other case, when comparing RealVector { 1, 0, 1 } and {1, -0, 1}, it
seems that
the equals method uses "numeric comparison" to conclude that 0 == -0. However,
when computing their hashcodes, the code implicitly treats "0" as an object,
and use
Arrays.hashcode to get the results (0, -0 are 2 different objects).
Therefore, I suggest to use a *consistent* way for comparison and computing
hashcodes. It is
completely feasible to fix the above problem. Here are 2 possible fixes:
1. change the ArrayRealVector#equals, lines 1207 - 1211
{code}
for (int i = 0; i < data.length; ++i) {
if (data[i] != rhs.getEntry(i)) { //do not use numeric comparison,
convert both sides
return false; //into Double type, and
use Double.equals to compare
}
}
{code}
2. change the ways to compute hashcode in: ArrayRealVector#hashCode
Do not use {code}Arrays.hashCode(value);{code} to get hashcode, since it will
implicitly
boxes each primitive values. Instead, use a method like below to compute
hashcode numerically:
{code}
public static int hash(double[] value) {
int retHashCode = 0;
for(double v : value) {
retHashCode += retHashCode*3 + 17*v;
}
return retHashCode;
}
{code}
I think either way above will fix this problem (though it may be not that
important), and keep
the code behavior consistent!
Thanks
-Sai)
> Bug in class# org.apache.commons.math.dfp.Dfp /
> org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
> -
>
> Key: MATH-553
> URL: https://issues.apache.org/jira/browse/MATH-553
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: jdk 1.6
>Reporter: Sai Zhang
> Attachments: ApacheMath_Documented_Test.java
>
>
> Hi all:
> I am writing an automated bug finding tool, and using
> Apache Commons Math as an experimental subject
> for evaluation.
> The tool creates executable JUnit tests as well as
> explanatory code comments. I attached one bug-revealing
> test as follows. Could you please kindly check it, to
> see if it is a real bug or not?
> Also, it would be tremendous helpful if you could give
> some feedback and suggestion on the quality of generated code comments?
> From the perspective of developers who are familiar with the code,
> is the automatically-inferred comment useful in understanding
> the generated test? is the comment helpful in bug fixing from the
> perspective of developers?
> Particularly when the automatically-generated tests
> are often long.
> Your suggestion will help us improve the tool.
> Please see attachment for the failed test.
> The comment appears in the form of:
> //Tests pass if (it gives some small change to the test which can make
> the failed test pass)
> For example:
> //Test passes if var10 is: (double)<0
> java.lang.Double var10 = new java.lang.Double(0.0d);
> means if you change var10 to a double value which is < 0 (e.g., -1d), the
> failed test will pass
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-553) Bug in class# org.apache.commons.math.dfp.Dfp / org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
[
https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086718#comment-13086718
]
Sai Zhang commented on MATH-553:
Hi Luc:
(sorry for the late reply. I thought my previous email was sent out, but found
it
still lies in my draft box)
I agree that it does not make sense to compare 2 NaNs. However, I think
two Java objects can still be compared, and the code maybe improved to
avoid violation of the Java specification.
For the problem revealed in the test case, I suggest to fix this bug by adding
a comparison to
*this* object itself. Doing so will avoid "var.equals(var)" returns false.
and prevent Java containers becoming unstable, when they are containing a Dfp
object.
A suggested fix is:
{code}
Class: org.apache.commons.math.dfp.Dfp
@Override
public boolean equals(final Object other) {
if(this == other) {
return true;
}
// all existing code goes here
}
{code}
For the other case, when comparing RealVector { 1, 0, 1 } and {1, -0, 1}, it
seems that
the equals method uses "numeric comparison" to conclude that 0 == -0. However,
when computing their hashcodes, the code implicitly treats "0" as an object,
and use
Arrays.hashcode to get the results (0, -0 are 2 different objects).
Therefore, I suggest to use a *consistent* way for comparison and computing
hashcodes. It is
completely feasible to fix the above problem. Here are 2 possible fixes:
1. change the ArrayRealVector#equals, lines 1207 - 1211
{code}
for (int i = 0; i < data.length; ++i) {
if (data[i] != rhs.getEntry(i)) { //do not use numeric comparison,
convert both sides
return false; //into Double type, and
use Double.equals to compare
}
}
{code}
2. change the ways to compute hashcode in: ArrayRealVector#hashCode
Do not use {code}Arrays.hashCode(value);{code} to get hashcode, since it will
implicitly
boxes each primitive values. Instead, use a method like below to compute
hashcode numerically:
{code}
public static int hash(double[] value) {
int retHashCode = 0;
for(double v : value) {
retHashCode += retHashCode*3 + 17*v;
}
return retHashCode;
}
{code}
I think either way above will fix this problem (though it may be not that
important), and keep
the code behavior consistent!
Thanks
-Sai
> Bug in class# org.apache.commons.math.dfp.Dfp /
> org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
> -
>
> Key: MATH-553
> URL: https://issues.apache.org/jira/browse/MATH-553
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: jdk 1.6
>Reporter: Sai Zhang
> Attachments: ApacheMath_Documented_Test.java
>
>
> Hi all:
> I am writing an automated bug finding tool, and using
> Apache Commons Math as an experimental subject
> for evaluation.
> The tool creates executable JUnit tests as well as
> explanatory code comments. I attached one bug-revealing
> test as follows. Could you please kindly check it, to
> see if it is a real bug or not?
> Also, it would be tremendous helpful if you could give
> some feedback and suggestion on the quality of generated code comments?
> From the perspective of developers who are familiar with the code,
> is the automatically-inferred comment useful in understanding
> the generated test? is the comment helpful in bug fixing from the
> perspective of developers?
> Particularly when the automatically-generated tests
> are often long.
> Your suggestion will help us improve the tool.
> Please see attachment for the failed test.
> The comment appears in the form of:
> //Tests pass if (it gives some small change to the test which can make
> the failed test pass)
> For example:
> //Test passes if var10 is: (double)<0
> java.lang.Double var10 = new java.lang.Double(0.0d);
> means if you change var10 to a double value which is < 0 (e.g., -1d), the
> failed test will pass
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-553) Bug in class# org.apache.commons.math.dfp.Dfp / org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
[
https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086717#comment-13086717
]
Sai Zhang commented on MATH-553:
Hi Luc:
(sorry for the late reply. I thought my previous email was sent out, but
found it
still lies in my draft box)
I agree that it does not make sense to compare 2 NaNs. However, I think
two Java objects can still be compared, and the code maybe improved to
avoid violation of the Java specification.
For the problem revealed in the test case, I suggest to fix this bug by
adding a comparison to
*this* object itself. Doing so will avoid "var.equals(var)" returns
false. and prevent Java containers becoming unstable, when they
are containing a Dfp object.
A suggested fix is:
{code}
Class: org.apache.commons.math.dfp.Dfp
@Override
public boolean equals(final Object other) {
if(this == other) {
return true;
}
// all existing code goes here
}
{code}
For the other case, when comparing RealVector { 1, 0, 1 } and {1, -0, 1},
it seems that
the equals method uses "numeric comparison" to conclude that 0 == -0.
However,
when computing their hashcodes, the code implicitly treats "0" as an object,
and use
Arrays.hashcode to get the results (0, -0 are 2 different objects).
Therefore, I suggest to use a *consistent* way for comparison and computing
hashcodes. It is
completely feasible to fix the above problem. Here are 2 possible fixes:
1. change the ArrayRealVector#equals, lines 1207 - 1211
{code}
for (int i = 0; i < data.length; ++i) {
if (data[i] != rhs.getEntry(i)) { //do not use numeric
comparison, convert both sides
return false; //into Double type,
and use Double.equals to compare
}
}
{code}
2. change the ways to compute hashcode in: ArrayRealVector#hashCode
Do not use {code}Arrays.hashCode(value);{code} to get hashcode, since it
will implicitly
boxes each primitive values. Instead, use a method like below to compute
hashcode numerically:
{code}
public static int hash(double[] value) {
int retHashCode = 0;
for(double v : value) {
retHashCode += retHashCode*3 + 17*v;
}
return retHashCode;
}
{code}
I think either way above will fix this problem (though it may be not that
important), and keep
the code behavior consistent!
Thanks
-Sai
--
Sai Zhang
http://www.cs.washington.edu/homes/szhang/
> Bug in class# org.apache.commons.math.dfp.Dfp /
> org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
> -
>
> Key: MATH-553
> URL: https://issues.apache.org/jira/browse/MATH-553
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: jdk 1.6
>Reporter: Sai Zhang
> Attachments: ApacheMath_Documented_Test.java
>
>
> Hi all:
> I am writing an automated bug finding tool, and using
> Apache Commons Math as an experimental subject
> for evaluation.
> The tool creates executable JUnit tests as well as
> explanatory code comments. I attached one bug-revealing
> test as follows. Could you please kindly check it, to
> see if it is a real bug or not?
> Also, it would be tremendous helpful if you could give
> some feedback and suggestion on the quality of generated code comments?
> From the perspective of developers who are familiar with the code,
> is the automatically-inferred comment useful in understanding
> the generated test? is the comment helpful in bug fixing from the
> perspective of developers?
> Particularly when the automatically-generated tests
> are often long.
> Your suggestion will help us improve the tool.
> Please see attachment for the failed test.
> The comment appears in the form of:
> //Tests pass if (it gives some small change to the test which can make
> the failed test pass)
> For example:
> //Test passes if var10 is: (double)<0
> java.lang.Double var10 = new java.lang.Double(0.0d);
> means if you change var10 to a double value which is < 0 (e.g., -1d), the
> failed test will pass
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EMAIL-107) wrong content-type for embedded PNG images
wrong content-type for embedded PNG images -- Key: EMAIL-107 URL: https://issues.apache.org/jira/browse/EMAIL-107 Project: Commons Email Issue Type: Bug Affects Versions: 1.2 Reporter: Jay when embedding a PNG image the content type is: Content-Type: application/octet-stream; which makes some clients not show the image. by contrast, when embedding a GIF image the content type is correctly shown as: Content-Type: image/gif; -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-142) Swallowing exceptions throw by factory destroy() methods can hide genuine issues
[ https://issues.apache.org/jira/browse/POOL-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-142. -- Resolution: Duplicate Agree with the analysis. Logging the exception is probably the best approach. See POOL-131. > Swallowing exceptions throw by factory destroy() methods can hide genuine > issues > > > Key: POOL-142 > URL: https://issues.apache.org/jira/browse/POOL-142 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Mark Thomas > Fix For: 2.0 > > > Swallowing all factory exceptions prevents the factory indicating to the pool > that there is an issue. For example, attempting to destroy an object twice > may indicate a bug in the pool code. The factory exception policy needs to be > reviewed. If changed this will be an API change to needs to wait until 2.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-131) Make org.apache.commons.pool.impl.GenericObjectPool.returnObject(Object) log errors about passivation/destroying
[ https://issues.apache.org/jira/browse/POOL-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086459#comment-13086459 ] Mark Thomas commented on POOL-131: -- Throwing runtime exceptions is likely to cause more problems than it solves in this case. Logging is the better approach. See POOL-142 for a fuller explanation. > Make org.apache.commons.pool.impl.GenericObjectPool.returnObject(Object) log > errors about passivation/destroying > > > Key: POOL-131 > URL: https://issues.apache.org/jira/browse/POOL-131 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 1.4 > Environment: Spring Framework JTA transaction Manager + jBossTS + DBCP >Reporter: Mauro Molinari > Fix For: 2.0 > > > In our environment it happens the following. Suppose our code has a bug and > does not release a connection previously obtained from DBCP. > Suppose a JTA transaction is in progress when this happens. > When trying to commit this transaction, Spring has a guard that realizes that > the owner of that transaction is in some way "dead", so it tries to close the > connection before committing (I think this is a problem, however, let's go > on). Closing the connection makes DBCP/Pool call returnObject on the > GenericObjectPool, then addObjectToPool and, at last, passivateObject. As the > connection is neither in auto-commit mode nor read-only, passivateObject > issues a rollback on the connection but then jBossTS throws a SQLException > saying that it is not allowed to issue a rollback on an underlying connection > while a higher level JTA transaction is in progress. This exception is caught > by returnObject and it is completely lost, because returnObject does not log > it, nor it forwards it upward. > The final result is that: > - the connection is not given back to the Pool, because of the exception > - however, the physical underlying connection to the DBMS remains open > => we have a connection leak, without any proof of it (no exceptions are > logged in any way) > To get to these results I had to carefully debug my code. It would have been > very easier if Pool logged exceptions thrown during passivation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-148) borrowObject should return the exception thrown by validateObject when throwing an Exception to let Exceptions be handled at a higher level
[
https://issues.apache.org/jira/browse/POOL-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved POOL-148.
--
Resolution: Fixed
Assignee: Mark Thomas
This was addressed in the pool2 re-factoring.
> borrowObject should return the exception thrown by validateObject when
> throwing an Exception to let Exceptions be handled at a higher level
> ---
>
> Key: POOL-148
> URL: https://issues.apache.org/jira/browse/POOL-148
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 1.5.2
> Environment: All
>Reporter: Monsieur EDI
>Assignee: Mark Thomas
> Fix For: 2.0
>
>
> public Object borrowObject() throws Exception {
> ...
> try {
> ...
> if(newlyCreated) {
> throw new NoSuchElementException("Could not create a
> validated object, cause: " + e.getMessage());
> }
> SHOULD BE CHANGED TO :
> if(newlyCreated) {
> throw new Exception("Could not create a validated
> object", e);
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-98) Make GenericObjectPool better extensible
[
https://issues.apache.org/jira/browse/POOL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved POOL-98.
-
Resolution: Fixed
Assignee: Mark Thomas
Because pool2 retains references to all the objects, not just the idle objects
all of the stats listed above were relatively simple to expose.
> Make GenericObjectPool better extensible
>
>
> Key: POOL-98
> URL: https://issues.apache.org/jira/browse/POOL-98
> Project: Commons Pool
> Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Henning Schmiedehausen
>Assignee: Mark Thomas
>Priority: Minor
> Fix For: 2.0
>
>
> The current implementation of GenericObjectPool encapsulates the _pool
> object and there is no way to get it directly, which makes some things
> like JMX pool monitoring a bit awkward.
> Would it be possible to either make _pool protected or add a method
> protected Collection getInternalPool() {
> return _pool;
> }
> or something like that to the GenericObjectPool implementation (and
> probably others, but that is the one that bites me most... :-) )
> This would make extending the GenericObjectPool much easier.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-127) Non-ascii characters in source files
[
https://issues.apache.org/jira/browse/CODEC-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CODEC-127.
Resolution: Fixed
Fixes applied to trunk and generics branch
> Non-ascii characters in source files
>
>
> Key: CODEC-127
> URL: https://issues.apache.org/jira/browse/CODEC-127
> Project: Commons Codec
> Issue Type: Bug
>Reporter: Sebb
>
> Some of the test cases include characters in a native encoding (possibly
> UTF-8), rather than using Unicode escapes.
> This can cause a problem for IDEs if they don't know the encoding (e.g. cause
> compilation errors, which is how I found the issue), and possibly some
> transformations may corrupt the contents, e.g. fixing EOL.
> I think we should have a rule of using Unicode escapes for all such non-ascii
> characters.
> It's particularly important for non-ISO-8859-1 characters.
> Some example classes with non-ascii characters:
> {code}
> binary\Base64Test.java:96 byte[] decode =
> b64.decode("SGVsbG{´┐¢´┐¢´┐¢´┐¢´┐¢´┐¢}8gV29ybGQ=");
> language\ColognePhoneticTest.java:110 {"m├Ânchengladbach",
> "664645214"},
> language\ColognePhoneticTest.java:130 String[][] data =
> {{"bergisch-gladbach", "174845214"}, {"M├╝ller-L├╝denscheidt", "65752682"}};
> language\ColognePhoneticTest.java:137 {"Meyer", "M├╝ller"},
> language\ColognePhoneticTest.java:143 {"ganz", "Gänse"},
> language\DoubleMetaphoneTest.java:1222
> this.getDoubleMetaphone().isDoubleMetaphoneEqual("´┐¢", "S");
> language\DoubleMetaphoneTest.java:1227
> this.getDoubleMetaphone().isDoubleMetaphoneEqual("´┐¢", "N");
> language\SoundexTest.java:367 if (Character.isLetter('´┐¢')) {
> language\SoundexTest.java:369 Assert.assertEquals("´┐¢000",
> this.getSoundexEncoder().encode("´┐¢"));
> language\SoundexTest.java:375 Assert.assertEquals("",
> this.getSoundexEncoder().encode("´┐¢"));
> language\SoundexTest.java:387 if (Character.isLetter('´┐¢')) {
> language\SoundexTest.java:389 Assert.assertEquals("´┐¢000",
> this.getSoundexEncoder().encode("´┐¢"));
> language\SoundexTest.java:395 Assert.assertEquals("",
> this.getSoundexEncoder().encode("´┐¢"));
> {code}
> The characters are probably not correct above, because I used a crude perl
> script to find them:
> {code}
> perl -ne "$.=1 if $s ne $ARGV;print qq($ARGV:$. $_) if
> m/\P{ASCII}/;$s=$ARGV;" .java
> {code}
> language\SoundexTest.java:367 in particular is incorrect, because it's
> supposed to be a single character.
> Now one might think that native2ascii -encoding UTF-8 would fix that, but it
> gives:
> if (Character.isLetter('\ufffd'))
> which is an "unknown" character.
> Similarly for binary\Base64Test.java:96.
> It's not all that clear what the Unicode escapes should be in these cases,
> but probably not the unknown character.
> [Possibly the characters got mangled at some point, or maybe they have always
> been wrong]
> The ColognePhoneticTest.java cases are less serious, as the characters are
> valid ISO-8859-1 (accented German), but given that the rest of the file uses
> unicode escaps, I think they should be changed too (but add comments to say
> what they are, e.g. o-umlaut, u-umlaut)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-132) Add support for unix dump files
[ https://issues.apache.org/jira/browse/COMPRESS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086412#comment-13086412 ] Stefan Bodewig commented on COMPRESS-132: - I've added dump support on the base of the current trunk code to the Compress Antlib[1]'s trunk and its different type of test archive works as well. So I see autodetection and docs as the only things missing to close this, yay. The current javadocs say we'd support BZIP2 (in package.html), but this is not true, is it? [1] http://ant.apache.org/antlibs/compress/index.html > Add support for unix dump files > --- > > Key: COMPRESS-132 > URL: https://issues.apache.org/jira/browse/COMPRESS-132 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Reporter: Bear Giles >Priority: Minor > Fix For: 1.3 > > Attachments: dump-20110722.zip, dump.zip, test-z.dump, test.dump > > > I'm submitting a series of patches to the ext2/3/4 dump utility and noticed > that the commons-compress library doesn't have an archiver for it. It's as > old as tar and fills a similar niche but the later has become much more > widely used. Dump includes support for sparse files, extended attributes, mac > os finder, SELinux labels (I think), and more. Incremental dumps can capture > that files have been deleted. > I should have initial support for a decoder this weekend. I can read the > directory entries and inode information (file permissions, etc.) but need a > bit more work on extracting the content as an InputStream. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086368#comment-13086368
]
Gilles commented on MATH-621:
-
{quote}
remove unused variables
{quote}
Would you take that one?
{quote}
reorganize variable use (limit their scope)
{quote}
I've done this for "altmov" and "update".
Let me know which function(s) you'd like to deal with.
{quote}
would be great if we could use/identify some of the ArrayRealVector [...]
{quote}
This can be left for after the other two points I think.
When you make changes, please provide a patch for each step separately: i.e.
one patch for point 1, one patch for each function, for point 2.
> BOBYQA is missing in optimization
> -
>
> Key: MATH-621
> URL: https://issues.apache.org/jira/browse/MATH-621
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dr. Dietmar Wolz
> Fix For: 3.0
>
> Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,
> BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl,
> bobyqaoptimizer0.4.zip, bobyqav0.3.zip
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> During experiments with space flight trajectory optimizations I recently
> observed, that the direct optimization algorithm BOBYQA
> http://plato.asu.edu/ftp/other_software/bobyqa.zip
> from Mike Powell is significantly better than the simple Powell algorithm
> already in commons.math. It uses significantly lower function calls and is
> more reliable for high dimensional problems. You can replace CMA-ES in many
> more application cases by BOBYQA than by the simple Powell optimizer.
> I would like to contribute a Java port of the algorithm.
> I maintained the structure of the original FORTRAN code, so the
> code is fast but not very nice.
> License status: Michael Powell has sent the agreement via snail mail
> - it hasn't arrived yet.
> Progress: The attached patch relative to the trunk contains both the
> optimizer and the related unit tests - which are all green now.
> Performance:
> Performance difference (number of function evaluations)
> PowellOptimizer / BOBYQA for different test functions (taken from
> the unit test of BOBYQA, dimension=13 for most of the
> tests.
> Rosen = 9350 / 1283
> MinusElli = 118 / 59
> Elli = 223 / 58
> ElliRotated = 8626 / 1379
> Cigar = 353 / 60
> TwoAxes = 223 / 66
> CigTab = 362 / 60
> Sphere = 223 / 58
> Tablet = 223 / 58
> DiffPow = 421 / 928
> SsDiffPow = 614 / 219
> Ackley = 757 / 97
> Rastrigin = 340 / 64
> The number for DiffPow should be dicussed with Michael Powell,
> I will send him the details.
> Open Problems:
> Some checkstyle violations because of the original Fortran source:
> - Original method comments were copied - doesn't follow javadoc standard
> - Multiple variable declarations in one line as in the original source
> - Problems related to "goto" conversions:
> "gotos" not convertible in loops were transated into a finite automata
> (switch statement)
> "no default in switch"
> "fall through from previos case in switch"
> which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-647) MATH-449
[ https://issues.apache.org/jira/browse/MATH-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Meyer closed MATH-647. -- Resolution: Not A Problem Error. This issue should not have been created > MATH-449 > > > Key: MATH-647 > URL: https://issues.apache.org/jira/browse/MATH-647 > Project: Commons Math > Issue Type: Bug >Reporter: Patrick Meyer > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-647) MATH-449
MATH-449 Key: MATH-647 URL: https://issues.apache.org/jira/browse/MATH-647 Project: Commons Math Issue Type: Bug Reporter: Patrick Meyer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086341#comment-13086341 ] Dr. Dietmar Wolz commented on MATH-621: --- So finally we use the cm vectors / matrices, fine. Whats next? My feeling is that before we look at the case statements we should do some easy stuff: 1) remove unused variables (eclipse shows some ugly yellow warnings) 2) reorganize variable use (limit their scope). Should be done with the case statement removal in mind. 3) would be great if we could use/identify some of the ArrayRealVector / Array2DRowRealMatrix operations (beside getEntry/setEntry) We should coordinate 1) + 2), 3) may perhaps be done independently - and later merged. > BOBYQA is missing in optimization > - > > Key: MATH-621 > URL: https://issues.apache.org/jira/browse/MATH-621 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Fix For: 3.0 > > Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, > BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, > bobyqaoptimizer0.4.zip, bobyqav0.3.zip > > Original Estimate: 8h > Remaining Estimate: 8h > > During experiments with space flight trajectory optimizations I recently > observed, that the direct optimization algorithm BOBYQA > http://plato.asu.edu/ftp/other_software/bobyqa.zip > from Mike Powell is significantly better than the simple Powell algorithm > already in commons.math. It uses significantly lower function calls and is > more reliable for high dimensional problems. You can replace CMA-ES in many > more application cases by BOBYQA than by the simple Powell optimizer. > I would like to contribute a Java port of the algorithm. > I maintained the structure of the original FORTRAN code, so the > code is fast but not very nice. > License status: Michael Powell has sent the agreement via snail mail > - it hasn't arrived yet. > Progress: The attached patch relative to the trunk contains both the > optimizer and the related unit tests - which are all green now. > Performance: > Performance difference (number of function evaluations) > PowellOptimizer / BOBYQA for different test functions (taken from > the unit test of BOBYQA, dimension=13 for most of the > tests. > Rosen = 9350 / 1283 > MinusElli = 118 / 59 > Elli = 223 / 58 > ElliRotated = 8626 / 1379 > Cigar = 353 / 60 > TwoAxes = 223 / 66 > CigTab = 362 / 60 > Sphere = 223 / 58 > Tablet = 223 / 58 > DiffPow = 421 / 928 > SsDiffPow = 614 / 219 > Ackley = 757 / 97 > Rastrigin = 340 / 64 > The number for DiffPow should be dicussed with Michael Powell, > I will send him the details. > Open Problems: > Some checkstyle violations because of the original Fortran source: > - Original method comments were copied - doesn't follow javadoc standard > - Multiple variable declarations in one line as in the original source > - Problems related to "goto" conversions: > "gotos" not convertible in loops were transated into a finite automata > (switch statement) > "no default in switch" > "fall through from previos case in switch" > which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-172) Add JMX (MBean) management and monitoring
[ https://issues.apache.org/jira/browse/POOL-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-172. -- Resolution: Fixed Assignee: Mark Thomas GOP and GKOP attributes are now exposed via JMX. > Add JMX (MBean) management and monitoring > - > > Key: POOL-172 > URL: https://issues.apache.org/jira/browse/POOL-172 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 1.5.4, 2.0, 3.0 >Reporter: Steve Siebert >Assignee: Mark Thomas > Fix For: 2.0 > > Original Estimate: 6h > Remaining Estimate: 6h > > All JMX MBeans for pool monitoring and runtime management (configuration). > In addition to adding runtime configuration and support for JMX, this feature > could possibly satisfy #POOL-159 and #POOL-98. > Need to look at Tomcat jdbc-pool implementation to see what we can learn, and > if we can contribute back to that project as well. Need to analyze related > tickets, commons mailing list, and develop an API for the MBean(s). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-132) Add support for unix dump files
[ https://issues.apache.org/jira/browse/COMPRESS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086324#comment-13086324 ] Stefan Bodewig commented on COMPRESS-132: - extract test passes with svn revision 1158723 - ArchiveEntry#getSize() is supoosed to return -1 for directories and the test relied on it, DumpArchiveEntry now does. > Add support for unix dump files > --- > > Key: COMPRESS-132 > URL: https://issues.apache.org/jira/browse/COMPRESS-132 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Reporter: Bear Giles >Priority: Minor > Fix For: 1.3 > > Attachments: dump-20110722.zip, dump.zip, test-z.dump, test.dump > > > I'm submitting a series of patches to the ext2/3/4 dump utility and noticed > that the commons-compress library doesn't have an archiver for it. It's as > old as tar and fills a similar niche but the later has become much more > widely used. Dump includes support for sparse files, extended attributes, mac > os finder, SELinux labels (I think), and more. Incremental dumps can capture > that files have been deleted. > I should have initial support for a decoder this weekend. I can read the > directory entries and inode information (file permissions, etc.) but need a > bit more work on extracting the content as an InputStream. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (COMPRESS-132) Add support for unix dump files
[ https://issues.apache.org/jira/browse/COMPRESS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086324#comment-13086324 ] Stefan Bodewig edited comment on COMPRESS-132 at 8/17/11 2:08 PM: -- extract test passes with svn revision 1158723 - ArchiveEntry#getSize() is supposed to return -1 for directories and the test relied on it, DumpArchiveEntry now does. was (Author: bodewig): extract test passes with svn revision 1158723 - ArchiveEntry#getSize() is supoosed to return -1 for directories and the test relied on it, DumpArchiveEntry now does. > Add support for unix dump files > --- > > Key: COMPRESS-132 > URL: https://issues.apache.org/jira/browse/COMPRESS-132 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Reporter: Bear Giles >Priority: Minor > Fix For: 1.3 > > Attachments: dump-20110722.zip, dump.zip, test-z.dump, test.dump > > > I'm submitting a series of patches to the ext2/3/4 dump utility and noticed > that the commons-compress library doesn't have an archiver for it. It's as > old as tar and fills a similar niche but the later has become much more > widely used. Dump includes support for sparse files, extended attributes, mac > os finder, SELinux labels (I think), and more. Incremental dumps can capture > that files have been deleted. > I should have initial support for a decoder this weekend. I can read the > directory entries and inode information (file permissions, etc.) but need a > bit more work on extracting the content as an InputStream. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DAEMON-178) jsvc process does not take the umask of the running user. It is always 077
[ https://issues.apache.org/jira/browse/DAEMON-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086236#comment-13086236 ] Jose D. Benavent edited comment on DAEMON-178 at 8/17/11 10:53 AM: --- Thank you, J Miller(y). I had turned mad wondering why the TOMCAT_USER (off) was not granted read permission to the *catalina.out* log file. It is required, for example, to check error messages when an app is deployed. I downloaded release 6.0.29 which includes *commons-daemon-1.0.2-native-src*, i.e, version 1.0.2 is affected too. was (Author: jdbenavent): Thank you, J Miller(y). I had turned mad wondering why the TOMCAT_USER (off) was not granted read permission to the catalina.out log file. It is required, for example, to check error messages when an app is deployed. I downloaded release 6.0.29 which includes *commons-daemon-1.0.2-native-src*, i.e, version 1.0.2 is affected too. > jsvc process does not take the umask of the running user. It is always 077 > -- > > Key: DAEMON-178 > URL: https://issues.apache.org/jira/browse/DAEMON-178 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.3 > Environment: Ubuntu Hardy 8.0.4, jdk1.6.2 >Reporter: J Miller > Fix For: 1.0.4 > > > 1) create a simple implementation of the Daemon interface that writes "hello > world" log files > 2) compile jsvc as described in the documentation > 3) verify that your linux user has umask != 077, by typing "umask" > 4) start jsvc with all the required CP args as described in the documentation > 5) look the log file permissions > Expected: The permissions are not 700. > Actual: They are 700. > 6) Modify commons-daemon/src/native/unix/native/jsvc-unix.c, replacing 077 > with 022 > 7) recompile jsvc > 8) repeat 4-5 > Expected: The permissions are 755. > Actual: The permissions are 755. > Conclusion: The jsvc process uses a hard-coded value, instead of adopting the > running user's umask, as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-178) jsvc process does not take the umask of the running user. It is always 077
[ https://issues.apache.org/jira/browse/DAEMON-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086236#comment-13086236 ] Jose D. Benavent commented on DAEMON-178: - Thank you, J Miller(y). I had turned mad wondering why the TOMCAT_USER (off) was not granted read permission to the catalina.out log file. It is required, for example, to check error messages when an app is deployed. I downloaded release 6.0.29 which includes *commons-daemon-1.0.2-native-src*, i.e, version 1.0.2 is affected too. > jsvc process does not take the umask of the running user. It is always 077 > -- > > Key: DAEMON-178 > URL: https://issues.apache.org/jira/browse/DAEMON-178 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.3 > Environment: Ubuntu Hardy 8.0.4, jdk1.6.2 >Reporter: J Miller > Fix For: 1.0.4 > > > 1) create a simple implementation of the Daemon interface that writes "hello > world" log files > 2) compile jsvc as described in the documentation > 3) verify that your linux user has umask != 077, by typing "umask" > 4) start jsvc with all the required CP args as described in the documentation > 5) look the log file permissions > Expected: The permissions are not 700. > Actual: They are 700. > 6) Modify commons-daemon/src/native/unix/native/jsvc-unix.c, replacing 077 > with 022 > 7) recompile jsvc > 8) repeat 4-5 > Expected: The permissions are 755. > Actual: The permissions are 755. > Conclusion: The jsvc process uses a hard-coded value, instead of adopting the > running user's umask, as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
