[jira] [Commented] (EXEC-54) Problem with argument containing spaces
[
https://issues.apache.org/jira/browse/EXEC-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245078#comment-13245078
]
Rupert Westenthaler commented on EXEC-54:
-
Came along the same Issue but with a different conclusion. (see
http://markmail.org/message/xbcseasols7ae2mc for details)
In short:
Commons Exec does NOT double quote the parameter. The problem is that the
java executable does not support quoted jar files (see also
http://stackoverflow.com/questions/5569591/unable-to-access-jarfile-in-linux-land).
So I assume this issue can be closed. However I would still be interested in an
utility that can be used to escape (instead of quote) parsed parameters. This
would be very handy when calling executable (like java) that do not interpret
quotation marks.
Problem with argument containing spaces
---
Key: EXEC-54
URL: https://issues.apache.org/jira/browse/EXEC-54
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.1
Environment: Mac OsX 10.6.6, JVM 1.6.0
Reporter: Jeremias Rößler
Assignee: Siegfried Goeschl
Labels: arguments, quotes, spaces
I am new to Commons Exec, so this could also be an error in usage, but...
When I use the {{CommandLine}} class to add a argument that contains spaces,
some quotes are added and are then part of the argument that is given.
For example: When I call {{java what version}} I get
{{java.lang.NoClassDefFoundError: what version}}, and when I call {{java
\what version\}} (which contains escaped quotes, that are part of the
command line argument itself), I get {{java.lang.NoClassDefFoundError: what
version}}.
So the following test fails, because as you can see in the last line, Apache
Exec is producing the latter version where it should have produced the first
version:
{code:java}
@Test
public void testArgumentQuoting() throws Exception {
String argument = what version;
DefaultExecutor executor = new DefaultExecutor();
DefaultExecuteResultHandler resultHandler = new
DefaultExecuteResultHandler();
ByteArrayOutputStream out = new ByteArrayOutputStream();
PumpStreamHandler streamHandler = new PumpStreamHandler(out,
out);
executor.setStreamHandler(streamHandler);
CommandLine cmdLine = new CommandLine(java);
cmdLine.addArgument(argument);
executor.execute(cmdLine, resultHandler);
resultHandler.waitFor();
String resultPattern = Exception in thread \main\
java\\.lang\\.NoClassDefFoundError: ([\\w \]+);
Pattern pattern = Pattern.compile(resultPattern);
Matcher matcher = pattern.matcher(out.toString());
Assert.assertTrue(matcher.find());
// Note: Result should be what version and NOT what
version!
Assert.assertEquals(argument, matcher.group(1));
}
{code}
Note that the same test passes if the space is removed from the argument.
Please also note, that I am not trying to start an external Java process, but
this is merely an example that I assume will work on every developers machine.
--
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] (EXEC-54) Problem with argument containing spaces
[
https://issues.apache.org/jira/browse/EXEC-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245102#comment-13245102
]
Sebb commented on EXEC-54:
--
Note that the quoting / escaping requirements vary by OS.
AFAIK, not all OSes support escapes, and the mechanism may vary depending on
the shell that is used.
Problem with argument containing spaces
---
Key: EXEC-54
URL: https://issues.apache.org/jira/browse/EXEC-54
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.1
Environment: Mac OsX 10.6.6, JVM 1.6.0
Reporter: Jeremias Rößler
Assignee: Siegfried Goeschl
Labels: arguments, quotes, spaces
I am new to Commons Exec, so this could also be an error in usage, but...
When I use the {{CommandLine}} class to add a argument that contains spaces,
some quotes are added and are then part of the argument that is given.
For example: When I call {{java what version}} I get
{{java.lang.NoClassDefFoundError: what version}}, and when I call {{java
\what version\}} (which contains escaped quotes, that are part of the
command line argument itself), I get {{java.lang.NoClassDefFoundError: what
version}}.
So the following test fails, because as you can see in the last line, Apache
Exec is producing the latter version where it should have produced the first
version:
{code:java}
@Test
public void testArgumentQuoting() throws Exception {
String argument = what version;
DefaultExecutor executor = new DefaultExecutor();
DefaultExecuteResultHandler resultHandler = new
DefaultExecuteResultHandler();
ByteArrayOutputStream out = new ByteArrayOutputStream();
PumpStreamHandler streamHandler = new PumpStreamHandler(out,
out);
executor.setStreamHandler(streamHandler);
CommandLine cmdLine = new CommandLine(java);
cmdLine.addArgument(argument);
executor.execute(cmdLine, resultHandler);
resultHandler.waitFor();
String resultPattern = Exception in thread \main\
java\\.lang\\.NoClassDefFoundError: ([\\w \]+);
Pattern pattern = Pattern.compile(resultPattern);
Matcher matcher = pattern.matcher(out.toString());
Assert.assertTrue(matcher.find());
// Note: Result should be what version and NOT what
version!
Assert.assertEquals(argument, matcher.group(1));
}
{code}
Note that the same test passes if the space is removed from the argument.
Please also note, that I am not trying to start an external Java process, but
this is merely an example that I assume will work on every developers machine.
--
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] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245250#comment-13245250
]
Thomas Neidhart commented on LANG-796:
--
I was still musing about this issue, and maybe adding an additional version
with a TimeZone parameter could make sense:
{noformat}
public static Date add(Date date, int calendarField, int amount, TimeZone tz) {
Calendar cal = Calendar.getInstance(tz);
cal.setTime(date);
cal.add(calendarField, amount);
return cal.getTime();
}
{noformat}
But to be consistent, this should be done for all methods (e.g. addDays,
addMonths, ..), and would definitely bloat the API.
DateUtils.addDays does not work properly with daylight saving time (DST)
Key: LANG-796
URL: https://issues.apache.org/jira/browse/LANG-796
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.6
Reporter: Nicola Barbiero
DateUtils.addDays does not work properly with daylight saving time.
The signature of the method is
Date addDays(Date date, int amount)
and the javadocs says Adds a number of days to a date returning a new
object. The original date object is unchanged,
so if X=date.getTime() is the number of milliseconds of the date in input,
the expected behaviour is that the returned Date has a number of milliseconds
equal to X+amount*(8640), where 8640 is the number of milliseconds in
one day.
But when the calculation goes across the DST change date, the number of
milliseconds added does not correspond to whole days.
For example, here in Brussels, this code fragment:
Date input = DateUtils.parseDateStrictly(25-03-2012_00:00, new String[]
{ dd-MM-_HH:mm });
Date output = DateUtils.addDays(input, 1);
will give:
'input' equals to Sun Mar 25 00:00:00 CET 2012== input.getTime()
equals to 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 is equivalent to 23h).
Since addDays is working with objects Date, it should not be influenced by
events like the DST.
Proposed solution: replace the current implementation
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(calendarField, amount);
return c.getTime();
}
based on Calendar with an implementation that works only with Date objects,
for example:
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
return new Date(input.getTime() + amount * 8640l);
}
--
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] (JXPATH-156) iteratePointers on relative context returns incorrect values for multidimensional arrays
iteratePointers on relative context returns incorrect values for
multidimensional arrays
Key: JXPATH-156
URL: https://issues.apache.org/jira/browse/JXPATH-156
Project: Commons JXPath
Issue Type: Bug
Reporter: Lukas Krejci
Let's have multidimensional array/collection as an input.
I would like to iterate through both inner and outer list. iteration through
the inner list is relative to iteration of outer list, so I'm using relative
context for that:
{code}
ListString array1 = Arrays.asList(what, is);
ListString array2 = Arrays.asList(wrong, ?);
ListListString strings = Arrays.asList(array1, array2);
JXPathContext context = JXPathContext.newContext(strings);
Iterator it = context.iteratePointers(.);
while (it.hasNext()) {
Pointer p = (Pointer) it.next();
JXPathContext context2 = context.getRelativeContext(p);
Iterator it2 = context2.iteratePointers(.);
while (it2.hasNext()) {
Pointer p2 = (Pointer) it2.next();
System.out.println(p2.getValue());
}
}
{code}
Unfortunately the inner iteration returns the inner collection instead of it's
items. So the output is following:
{code:xml}
[what, is]
[wrong, ?]
{code}
--
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] [Updated] (JXPATH-156) iteratePointers on relative context returns incorrect values for multidimensional arrays
[
https://issues.apache.org/jira/browse/JXPATH-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Krejci updated JXPATH-156:
Affects Version/s: 1.3
iteratePointers on relative context returns incorrect values for
multidimensional arrays
Key: JXPATH-156
URL: https://issues.apache.org/jira/browse/JXPATH-156
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.3
Reporter: Lukas Krejci
Let's have multidimensional array/collection as an input.
I would like to iterate through both inner and outer list. iteration through
the inner list is relative to iteration of outer list, so I'm using relative
context for that:
{code}
ListString array1 = Arrays.asList(what, is);
ListString array2 = Arrays.asList(wrong, ?);
ListListString strings = Arrays.asList(array1, array2);
JXPathContext context = JXPathContext.newContext(strings);
Iterator it = context.iteratePointers(.);
while (it.hasNext()) {
Pointer p = (Pointer) it.next();
JXPathContext context2 = context.getRelativeContext(p);
Iterator it2 = context2.iteratePointers(.);
while (it2.hasNext()) {
Pointer p2 = (Pointer) it2.next();
System.out.println(p2.getValue());
}
}
{code}
Unfortunately the inner iteration returns the inner collection instead of
it's items. So the output is following:
{code:xml}
[what, is]
[wrong, ?]
{code}
--
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] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245300#comment-13245300
]
Joerg Schaible commented on LANG-796:
-
What about creating UTCDateUtils instead that operates on UTC and is therefore
independent of any TZ? Then we have simply to properly document both types. We
could use a package private base class to share common functionality.
DateUtils.addDays does not work properly with daylight saving time (DST)
Key: LANG-796
URL: https://issues.apache.org/jira/browse/LANG-796
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.6
Reporter: Nicola Barbiero
DateUtils.addDays does not work properly with daylight saving time.
The signature of the method is
Date addDays(Date date, int amount)
and the javadocs says Adds a number of days to a date returning a new
object. The original date object is unchanged,
so if X=date.getTime() is the number of milliseconds of the date in input,
the expected behaviour is that the returned Date has a number of milliseconds
equal to X+amount*(8640), where 8640 is the number of milliseconds in
one day.
But when the calculation goes across the DST change date, the number of
milliseconds added does not correspond to whole days.
For example, here in Brussels, this code fragment:
Date input = DateUtils.parseDateStrictly(25-03-2012_00:00, new String[]
{ dd-MM-_HH:mm });
Date output = DateUtils.addDays(input, 1);
will give:
'input' equals to Sun Mar 25 00:00:00 CET 2012== input.getTime()
equals to 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 is equivalent to 23h).
Since addDays is working with objects Date, it should not be influenced by
events like the DST.
Proposed solution: replace the current implementation
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(calendarField, amount);
return c.getTime();
}
based on Calendar with an implementation that works only with Date objects,
for example:
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
return new Date(input.getTime() + amount * 8640l);
}
--
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] (COLLECTIONS-403) Make AndPredicate, AnyPredicate etc. not final
Make AndPredicate, AnyPredicate etc. not final -- Key: COLLECTIONS-403 URL: https://issues.apache.org/jira/browse/COLLECTIONS-403 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 3.2.1 Reporter: david cogen Priority: Minor If there is no good reason for these (and similar classes) to not be final, they would be much more useful to me if they were not final. I have a class that I wanted to have an is a relation to AnyPredicate, but, AnyPredicate being declared final, I cannot and instead have to design it with a has a relation to AnyPredicate, which for my purpose is much less clear. -- 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] [Resolved] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved CODEC-96.
--
Resolution: Fixed
Assignee: (was: Julius Davies)
In SVN
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Fix For: 1.x
Attachments: CODEC-96.patch, CODEX-96-2.patch,
codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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] (CODEC-138) Complete FilterInputStream interface for BaseNCodecInputStream
[ https://issues.apache.org/jira/browse/CODEC-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245518#comment-13245518 ] Gary D. Gregory commented on CODEC-138: --- Wouldn't UnsupportedOperationException be better? Complete FilterInputStream interface for BaseNCodecInputStream -- Key: CODEC-138 URL: https://issues.apache.org/jira/browse/CODEC-138 Project: Commons Codec Issue Type: Improvement Reporter: Thomas Neidhart Fix For: 1.7 Attachments: CODEC-138.patch Small patch to implement mark and reset in a safe manner. markSupported is already implemented, but the other two methods are inherited from the default FilterInputStream implementation, which calls the corresponding methods of the underlying stream. The patch provides a noop implementation for mark, and throws an IOException when reset is called. -- 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] (CODEC-138) Complete FilterInputStream interface for BaseNCodecInputStream
[ https://issues.apache.org/jira/browse/CODEC-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245527#comment-13245527 ] Thomas Neidhart commented on CODEC-138: --- I think IOException is more consistent with the standard jdk, as it is thrown when reset is not supported or mark has not been called before. Complete FilterInputStream interface for BaseNCodecInputStream -- Key: CODEC-138 URL: https://issues.apache.org/jira/browse/CODEC-138 Project: Commons Codec Issue Type: Improvement Reporter: Thomas Neidhart Fix For: 1.7 Attachments: CODEC-138.patch Small patch to implement mark and reset in a safe manner. markSupported is already implemented, but the other two methods are inherited from the default FilterInputStream implementation, which calls the corresponding methods of the underlying stream. The patch provides a noop implementation for mark, and throws an IOException when reset is called. -- 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] (CODEC-138) Complete FilterInputStream interface for BaseNCodecInputStream
[ https://issues.apache.org/jira/browse/CODEC-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245570#comment-13245570 ] Sebb commented on CODEC-138: Note: InputStream.reset() throws IOE so I think the patch is correct. Complete FilterInputStream interface for BaseNCodecInputStream -- Key: CODEC-138 URL: https://issues.apache.org/jira/browse/CODEC-138 Project: Commons Codec Issue Type: Improvement Reporter: Thomas Neidhart Fix For: 1.7 Attachments: CODEC-138.patch Small patch to implement mark and reset in a safe manner. markSupported is already implemented, but the other two methods are inherited from the default FilterInputStream implementation, which calls the corresponding methods of the underlying stream. The patch provides a noop implementation for mark, and throws an IOException when reset is called. -- 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] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245571#comment-13245571 ] Gary D. Gregory commented on CODEC-133: --- I've applied the patch locally, and I will look through it tonight. Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers Labels: MD5, SHA-512, crypt(3), crypto, hash Attachments: commons-codec-crypt3.diff, crypt3-with-utexas-licence.diff The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- 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] (CODEC-138) Complete FilterInputStream interface for BaseNCodecInputStream
[ https://issues.apache.org/jira/browse/CODEC-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed CODEC-138. - In SVN. Complete FilterInputStream interface for BaseNCodecInputStream -- Key: CODEC-138 URL: https://issues.apache.org/jira/browse/CODEC-138 Project: Commons Codec Issue Type: Improvement Reporter: Thomas Neidhart Fix For: 1.7 Attachments: CODEC-138.patch Small patch to implement mark and reset in a safe manner. markSupported is already implemented, but the other two methods are inherited from the default FilterInputStream implementation, which calls the corresponding methods of the underlying stream. The patch provides a noop implementation for mark, and throws an IOException when reset is called. -- 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] (MATH-777) More CrossoverPolicy's are needed.
More CrossoverPolicy's are needed. -- Key: MATH-777 URL: https://issues.apache.org/jira/browse/MATH-777 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Reid Hochstedler Attachments: Crossover.txt Currently only OnePointCrossover is available. There are no CrossoverPolicy's for Ordered Chromosomes. -- 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] [Updated] (MATH-777) More CrossoverPolicy's are needed.
[ https://issues.apache.org/jira/browse/MATH-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Hochstedler updated MATH-777: -- Attachment: Crossover.txt Implementations of CycleCrossover and OrderedCrossover. More CrossoverPolicy's are needed. -- Key: MATH-777 URL: https://issues.apache.org/jira/browse/MATH-777 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Reid Hochstedler Labels: genetics Attachments: Crossover.txt Currently only OnePointCrossover is available. There are no CrossoverPolicy's for Ordered Chromosomes. -- 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] [Updated] (MATH-777) More CrossoverPolicy's are needed.
[ https://issues.apache.org/jira/browse/MATH-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Hochstedler updated MATH-777: -- Attachment: OrderedCrossover.txt After attaching the first patch I discovered an error in which min and max could be the same. This patch is the corrected version of OrderedCrossover. More CrossoverPolicy's are needed. -- Key: MATH-777 URL: https://issues.apache.org/jira/browse/MATH-777 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Reid Hochstedler Labels: genetics Attachments: Crossover.txt, OrderedCrossover.txt Currently only OnePointCrossover is available. There are no CrossoverPolicy's for Ordered Chromosomes. -- 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] [Updated] (LANG-686) StringUtils.replaceEachRepeatedly(aaa, new String[]{aa}, new String[]{aXa}); throw an exception
[
https://issues.apache.org/jira/browse/LANG-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated LANG-686:
-
Attachment: LANG-686.patch
I have worked on this a bit and provide a patch that does the following:
* refactor the replaceEach method to avoid
code duplication
* change loop detection code
Instead using a timeToLive variable that trys to detect infinite loops, I use a
quite simple but effective method:
Whenever at the end of a replace cycle we end up having a result string that
has already be seen so far, we have possibly detected an infinite loop and thus
abort the execution (with an exception as before).
I have also added two additional unit test cases.
StringUtils.replaceEachRepeatedly(aaa, new String[]{aa}, new
String[]{aXa}); throw an exception
-
Key: LANG-686
URL: https://issues.apache.org/jira/browse/LANG-686
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 2.6
Environment: jdk 1.6.24, windows xp pro sp3, eclipse helios
Reporter: qed
Fix For: 3.x
Attachments: LANG-686.patch
After executing line
StringUtils.replaceEachRepeatedly(aaa, new String[]{aa}, new
String[]{aXa});
exception is thrown:
Exception in thread main java.lang.IllegalStateException: TimeToLive of -1
is less than 0: aXaXa
at
org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:3986)
at
org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
at
org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
at
org.apache.commons.lang.StringUtils.replaceEachRepeatedly(StringUtils.java:3920)
--
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] [Resolved] (COMPRESS-183) Support for de/encoding of tar entry names other than plain 8BIT conversion.
[ https://issues.apache.org/jira/browse/COMPRESS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-183. - Resolution: Fixed Forgot to close this, documentation has been completed about a week ago. Support for de/encoding of tar entry names other than plain 8BIT conversion. Key: COMPRESS-183 URL: https://issues.apache.org/jira/browse/COMPRESS-183 Project: Commons Compress Issue Type: Improvement Components: Archivers Affects Versions: 1.3 Reporter: Joao Schim Labels: patch Fix For: 1.4 Attachments: patch-tar-name-encoding.diff, patch-tar-name-encoding.diff, patch-tar-name-encoding.diff The names of tar entries are currently encoded/decoded by means of plain 8bit conversions of byte to char and vice-versa. This prohibits the use of encodings like UTF8 in the file names. Whether the use of UTF8 (or any other non ASCII) in file names is sensible is a chapter of its own. However tar archives that contain files which names have been encoded with UTF8 do float around. These files currently can not be read correctly by commons-compress due to the encoding being hardcoded to plain 8BIT only. The supplied patch allows to use encodings other than 8BIT using a TarArchiveCodec structure. It does not change the standard functionality, but adds to it the possibility of using a different encoding. A method was added to the TarUtilsTest junit test to test the added functionality. -- 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] (SANSELAN-68) Incorrect reading Physical Width/Height Dpi and Physical Width/Height Inch from TIFF files
[
https://issues.apache.org/jira/browse/SANSELAN-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246015#comment-13246015
]
Damjan Jovanovic commented on SANSELAN-68:
--
Please attach the patch as a separate file, and tick the Grant license to
ASF... checkbox. That's the only way we can accept patches.
Incorrect reading Physical Width/Height Dpi and Physical Width/Height Inch
from TIFF files
--
Key: SANSELAN-68
URL: https://issues.apache.org/jira/browse/SANSELAN-68
Project: Commons Sanselan
Issue Type: Bug
Components: Format: TIFF
Affects Versions: 1.0, 1.1, 1.x
Reporter: VVD
Labels: patch
Width: 3509
Physical Width Dpi: 4650
Physical Width Inch: 1169.667
Height: 2481
Physical Height Dpi: 4650
Physical Height Inch: 827.00024
{code}
TiffImageParser.java (196):
-case 3: // Meter
-unitsPerInch = 0.0254;
+case 3: // Centimeter
+unitsPerInch = 2.54;
(c) http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
TiffImageParser.java (218):
-physicalWidthDpi = (int) (XResolutionPixelsPerUnit /
unitsPerInch);
+physicalWidthDpi = (int) Math.round(XResolutionPixelsPerUnit
* unitsPerInch);
TiffImageParser.java (226):
-physicalHeightDpi = (int) (YResolutionPixelsPerUnit /
unitsPerInch);
+physicalHeightDpi = (int)
Math.round(YResolutionPixelsPerUnit * unitsPerInch);
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
May be need to patch writing of tiff image too - don't know.
P.S. GIMP show values: 300,000, 300,000, 11,697, 8,270.
--
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] (SANSELAN-69) Incorrect reading Physical Width/Height Inch from PNG files
[
https://issues.apache.org/jira/browse/SANSELAN-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246016#comment-13246016
]
Damjan Jovanovic commented on SANSELAN-69:
--
Please attach the patch as a separate file, and tick the Grant license to
ASF... checkbox. That's the only way we can accept patches.
Incorrect reading Physical Width/Height Inch from PNG files
---
Key: SANSELAN-69
URL: https://issues.apache.org/jira/browse/SANSELAN-69
Project: Commons Sanselan
Issue Type: Bug
Components: Format: PNG
Affects Versions: 0.97, 1.0, 1.1, 1.x
Reporter: VVD
Labels: patch
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 1052697.9
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 744298.5
{code}
PngImageParser.java (620):
PhysicalWidthInch = (float) ((double) Width
-* (double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch);
+/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch));
PngImageParser.java (625):
PhysicalHeightInch = (float) ((double) Height
-* (double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch);
+/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch));
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
--
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] [Resolved] (SANSELAN-70) Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots per millimeter
[
https://issues.apache.org/jira/browse/SANSELAN-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-70.
--
Resolution: Fixed
Fix Version/s: 1.0
I've applied the patch to the latest SVN.
Thank you for your contribution!
Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots
per millimeter
--
Key: SANSELAN-70
URL: https://issues.apache.org/jira/browse/SANSELAN-70
Project: Commons Sanselan
Issue Type: Bug
Components: Format: JPEG
Affects Versions: 0.97
Environment: N/A
Reporter: Tars Joris
Labels: patch
Fix For: 1.0
Attachments: Main.java, example_ppi.jpg, example_ppmm.jpg,
jpeg-dpi.patch.txt
The value of physical with DPI is incorrect for JPEG images, which express
their resolution in dots per millimeter.
Two images are attached:
- example_ppi.jpg: Normal image, with resolution specified in dots per inch
(72 pixels/in)
- example_ppmm.jpg: Same image, but with resolution specified in dots per
millimeter (2.8 pixels/mm)
When running the attached code, the output is
{code}
example_ppi.jpg
getPhysicalWidthDpi: 72
getPhysicalHeightDpi: 72
example_ppmm.jpg
getPhysicalWidthDpi: 11
getPhysicalHeightDpi: 71
{code}
While you'd expect the value 71 for getPhysicalWidthDpi for the second image.
--
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
