[jira] [Commented] (DAEMON-242) jsvc cannot find libcap.so on debian-based distributions
[ https://issues.apache.org/jira/browse/DAEMON-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214407#comment-13214407 ] Mladen Turk commented on DAEMON-242: Right, I was afraid that this feature would be actually useless in many cases. The amount of possibilities is endless so it seems that a loop will be needed. > jsvc cannot find libcap.so on debian-based distributions > > > Key: DAEMON-242 > URL: https://issues.apache.org/jira/browse/DAEMON-242 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.9 > Environment: Debian 6.0.2 > Ubuntu 11.04 >Reporter: Phil Clay > > Debian-based distributions do not symlink the "main" shared object to the > major version. > For example: > On RHEL4u4: > $ ls -l /lib/libcap.so* > lrwxrwxrwx 1 root root11 Jun 13 2007 /lib/libcap.so -> libcap.so.1 > lrwxrwxrwx 1 root root14 Jun 12 2007 /lib/libcap.so.1 -> libcap.so.1.10 > -rwxr-xr-x 1 root root 11784 Oct 7 2006 /lib/libcap.so.1.10 > Notice libcap.so -> libcap.so.1 > On Debian 6.02: > $ ls -l /lib/libcap.so* > lrwxrwxrwx 1 root root14 Jan 25 10:19 /lib/libcap.so.2 -> libcap.so.2.19 > -rw-r--r-- 1 root root 16640 Aug 16 2010 /lib/libcap.so.2.19 > On Ubuntu 11.04: > $ ls -l /lib/libcap.so* > lrwxrwxrwx 1 root root14 2011-07-16 09:52 /lib/libcap.so.2 -> > libcap.so.2.20 > -rw-r--r-- 1 root root 13816 2011-02-15 14:35 /lib/libcap.so.2.20 > Notice there is no libcap.so -> libcap.so.2 > Therefore, when jsvc attempts to load libcap.so, it fails... > I see this when running jsvc -debug ... > Attemtping to load library /lib/libcap.so > Attemtping to load library /usr/lib/libcap.so > failed loading capabilities library -- /usr/lib/libcap.so: cannot open shared > object file: No such file or directory. > set_caps(CAPS) failed for user 'oncommand' > Service exit with a return value of 4 > If I create the libcap.so -> libcap.so.2 symlink, it works. > I'm guessing the fix for this would be to load libcap.so, libcap.so.2, > libcap.so.1 in progression to see if any work. > (Note that I have performed the workaround I mentioned in > https://issues.apache.org/jira/browse/DAEMON-241 to get this far.) -- 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] (SANSELAN-17) integer overflow unhandled
[
https://issues.apache.org/jira/browse/SANSELAN-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic updated SANSELAN-17:
-
Attachment: concat-app13.patch
Concatenating the APP13 segments, as this patch does, gets the metadata to
parse without an exception.
However this alone is not the correct solution, as some images contain
independent APP13 blocks which should not be concatenated. Detecting which
blocks belong together is a difficult problem, and
http://dev.exiv2.org/issues/533 describes how exiv2 does it (by parsing the
internal block structures).
> integer overflow unhandled
> --
>
> Key: SANSELAN-17
> URL: https://issues.apache.org/jira/browse/SANSELAN-17
> Project: Commons Sanselan
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 0.94-incubator
> Environment: win32, 32 bit operating systems
>Reporter: Greg Squires
> Attachments: concat-app13.patch, crash.jpeg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> This function can throw an Exception in ByteSourceArray.java due to a
> negative byte[] allocation size. The length argument has been found to wrap
> when called from IccProfileParser.java.
> In 64bit machines, issues related to incorrect metadata, or ICC data can lead
> to incorrect and excess memory allocations. These large numbers however cause
> 32bit negative signed values.
> public byte[] getBlock(int start, int length) throws IOException
> {
> if (start + length > bytes.length)
> throw new IOException("Could not read block (block
> start: " + start
> + ", block length: " + length + ", data
> length: "
> + bytes.length + ").");
> byte result[] = new byte[length];
> System.arraycopy(bytes, start, result, 0, length);
> return result;
> }
--
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] (COMPRESS-174) BZip2CompressorInputStream doesn't handle being given a wrong-format compressed file
[ https://issues.apache.org/jira/browse/COMPRESS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214199#comment-13214199 ] Sebb commented on COMPRESS-174: --- The method CompressorStreamFactory.createCompressorInputStream(InputStream) can be used to autodetect the compression type. > BZip2CompressorInputStream doesn't handle being given a wrong-format > compressed file > > > Key: COMPRESS-174 > URL: https://issues.apache.org/jira/browse/COMPRESS-174 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: Linux and Windows >Reporter: Andrew Pavlin >Priority: Minor > > When reading a file through BZip2CompressorInputStream, and the user selects > a file of the wrong type (such as ZIP or GZIP), the read blows up with a > strange ArrayIndexOutOfBoundException, instead of reporting immediately that > the input data is of the wrong format. > The Bzip2Compressor should be able to identify whether a stream is of BZip2 > format or not, and immediately reject it with a meaningful exception > (example: "ProtocolException: not a BZip2 compressed file"). > Alternatively, are there functions in commons-compress that can identify the > compression type of an InputStream by inspection? > Example stack trace when using a ZIP input file: > Exception in thread "OSM Decompressor" > java.lang.ArrayIndexOutOfBoundsException: 90 > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:688) > > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:322) > > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.setupNoRandPartA(BZip2CompressorInputStream.java:880) > > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.setupNoRandPartB(BZip2CompressorInputStream.java:936) > > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.read0(BZip2CompressorInputStream.java:228) > > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.read(BZip2CompressorInputStream.java:180) > > at java.io.InputStream.read(InputStream.java:82) > at > org.ka2ddo.yaac.osm.OsmXmlSegmenter$1.run(OsmXmlSegmenter.java:129) > at java.lang.Thread.run(Thread.java:680) > -- 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] (COMPRESS-168) getName of ZipArchiveEntry
[ https://issues.apache.org/jira/browse/COMPRESS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated COMPRESS-168: -- Issue Type: Bug (was: Test) > getName of ZipArchiveEntry > -- > > Key: COMPRESS-168 > URL: https://issues.apache.org/jira/browse/COMPRESS-168 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.2 > Environment: J2EE Environment with jdk 1.4 >Reporter: Pavithra Kumar > Attachments: TestZip.zip > > > getName method of ZipArchiveEntry is not giving arabic file names. Instead of > that it gives some chunked characters. -- 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-158) Empty directories missing in zip archive
[ https://issues.apache.org/jira/browse/COMPRESS-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMPRESS-158. --- Resolution: Cannot Reproduce No further input, so assume problem has been resolved > Empty directories missing in zip archive > > > Key: COMPRESS-158 > URL: https://issues.apache.org/jira/browse/COMPRESS-158 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.2 > Environment: Java 1.6, Ubuntu Linux (ext4 fs) >Reporter: Daniel Spicar >Priority: Minor > Attachments: CompressionUtil.java, output.zip, test.zip > > > When zipping a directory that contains several files and subdirectories of > which some can be empty, I am missing empty directories. When using a tar > archive format empty directories are present. > I have found https://issues.apache.org/jira/browse/COMPRESS-105 which > describes a similar issue, however I am unable to reproduce the solution > suggested there. -- 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-155) CompressorStreamFactory hangs when creating BZip2CompressorInputStream from ReaderInputStream
[ https://issues.apache.org/jira/browse/COMPRESS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMPRESS-155. --- Resolution: Invalid Compressed files are a stream of bytes. It does not make sense to try and decompress a stream of characters. If there are problems using ReaderInputStream as far as I can tell that is not a bug in Compress. > CompressorStreamFactory hangs when creating BZip2CompressorInputStream from > ReaderInputStream > - > > Key: COMPRESS-155 > URL: https://issues.apache.org/jira/browse/COMPRESS-155 > Project: Commons Compress > Issue Type: Bug >Reporter: PNS >Priority: Blocker > > Assume that one wants to read a BZIP2 file but only has a reference to a > BufferedReader object and not to the File object itself. > An approach would be creating an InputStream from the BufferedReader > reference, using the org.apache.commons.io.input.ReaderInputStream class, as > follows: > BufferedReader reader = ; > InputStream is = new ReaderInputStream(reader); > CompressorInputStream cis = new > CompressorStreamFactory().createCompressorInputStream(is); > However, the call to the createCompressorInputStream() method hangs on the > statement > int signatureLength = in.read(signature); // CompressorStreamFactory line 93 > in commons-compress v1.2 > The problem seems to be in the read(byte[] b, int off, int len) method of > ReaderInputStream, which is called by the method fill(), in turn called by > read1(byte[] b, int off, int len) in BufferedInputStream. -- 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-131) ArrayOutOfBounds while decompressing bz2
[ https://issues.apache.org/jira/browse/COMPRESS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMPRESS-131. --- Resolution: Fixed Fix Version/s: 1.4 Did not actually fail, so presumably was fixed in an earlier version of Compress. Added test case. > ArrayOutOfBounds while decompressing bz2 > > > Key: COMPRESS-131 > URL: https://issues.apache.org/jira/browse/COMPRESS-131 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.1 > Environment: Ubuntu linux >Reporter: Gustavo Orair >Priority: Minor > Fix For: 1.4 > > Attachments: BDIN.Teste.xml.bz2 > > Original Estimate: 168h > Remaining Estimate: 168h > > Decompressing a bz2 file generated by bzip2 utility throws an > ArrayIndexOutOfBounds at method recvDecodingTables() line 469. > I believe it is related to encodings used to generate the original text file > (the compressed file). -- 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-178) TarArchiveInputStream throws IllegalArgumentException instead of IOException
[
https://issues.apache.org/jira/browse/COMPRESS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved COMPRESS-178.
---
Resolution: Fixed
Fix Version/s: 1.4
> TarArchiveInputStream throws IllegalArgumentException instead of IOException
>
>
> Key: COMPRESS-178
> URL: https://issues.apache.org/jira/browse/COMPRESS-178
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
> Fix For: 1.4
>
>
> TarArchiveInputStream is throwing IllegalArgumentException instead of
> IOException on corrupt files, in direct contradiction to the Javadoc. Here is
> a stack-trace:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Expected behavior: TarArchiveInputStream should wrap the
> IllegalArgumentException in an IOException.
--
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-179) TarUtils.formatLongOctalOrBinaryBytes() assumes the field will be 12 bytes long
[ https://issues.apache.org/jira/browse/COMPRESS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMPRESS-179. --- Resolution: Fixed Fix Version/s: 1.4 > TarUtils.formatLongOctalOrBinaryBytes() assumes the field will be 12 bytes > long > --- > > Key: COMPRESS-179 > URL: https://issues.apache.org/jira/browse/COMPRESS-179 > Project: Commons Compress > Issue Type: Bug >Reporter: Sebb > Fix For: 1.4 > > > The TarUtils.formatLongOctalOrBinaryBytes method currently assumes that the > field can hold 11 octal bytes. > This is not necessarily the case; the uid and gid fields (8 bytes) can > potentially be encoded as binary. -- 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] (EXEC-63) Race condition in DefaultExecutor#execute(cmd, handler)
[
https://issues.apache.org/jira/browse/EXEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sandiford updated EXEC-63:
-
Description:
{{DefaultExecutor#execute(CommandLine, ExecuteResultHandler)}} can, and usually
does, return before the target process has actually started. This can result
in a race condition where several asynchronous processes are coupled by
{{PipedInputStream}}/{{PipedOutputStream}} objects.
The following example shows the issue:
{code:title=Borken.java|borderStyle=solid}
import java.io.*;
import org.apache.commons.exec.*;
public class Borken {
public static int pipe(OutputStream out, OutputStream err, InputStream in,
CommandLine cmd0, CommandLine cmd1)
throws IOException {
PipedInputStream pipeIn = new PipedInputStream();
PipedOutputStream pipeOut = new PipedOutputStream(pipeIn);
DefaultExecutor exec0 = new DefaultExecutor();
exec0.setStreamHandler(new PumpStreamHandler(pipeOut, null, in));
exec0.execute(cmd0, new DefaultExecuteResultHandler());
// If the following line is commented, deadlock occurs
//try { Thread.sleep(100); } catch (InterruptedException e) { }
DefaultExecutor exec1 = new DefaultExecutor();
exec1.setStreamHandler(new PumpStreamHandler(out, err, pipeIn));
return exec1.execute(cmd1);
}
public static void main(String... args) {
CommandLine cmd0 = new
CommandLine("cmd").addArgument("/c").addArgument("dir");
//CommandLine cmd0 = new CommandLine("ls").addArgument("-l");
CommandLine cmd1 = new CommandLine("sort");
ByteArrayOutputStream out = new ByteArrayOutputStream();
ByteArrayOutputStream err = new ByteArrayOutputStream();
ByteArrayInputStream in = new ByteArrayInputStream(new byte[0]);
try {
int result = pipe(out, err, in, cmd0, cmd1);
System.out.format("Result code: %d%n", result);
System.out.format("Out: %s%n", out.toString());
} catch (Exception e) {
e.printStackTrace();
}
}
}
{code}
One possible solution is to pass in a semaphore object into
{{DefaultExecutor#executeInternal}} which is notified once the process is
started. The {{execute(CommandLine, Map, ExecuteResultHandler)}} method can
then wait on this before returning.
was:
DefaultExecutor#execute(CommandLine, ExecuteResultHandler) can, and usually
does, return before the target process has actually started. This can result
in a race condition where several asynchronous processes are coupled by
PipedInputStream/PipedOutputStream objects.
The following example shows the issue:
import java.io.*;
import org.apache.commons.exec.*;
public class Borken {
public static int pipe(OutputStream out, OutputStream err, InputStream in,
CommandLine cmd0, CommandLine cmd1)
throws IOException {
PipedInputStream pipeIn = new PipedInputStream();
PipedOutputStream pipeOut = new PipedOutputStream(pipeIn);
DefaultExecutor exec0 = new DefaultExecutor();
exec0.setStreamHandler(new PumpStreamHandler(pipeOut, null, in));
exec0.execute(cmd0, new DefaultExecuteResultHandler());
// If the following line is commented, deadlock occurs
//try { Thread.sleep(100); } catch (InterruptedException e) { }
DefaultExecutor exec1 = new DefaultExecutor();
exec1.setStreamHandler(new PumpStreamHandler(out, err, pipeIn));
return exec1.execute(cmd1);
}
public static void main(String... args) {
CommandLine cmd0 = new
CommandLine("cmd").addArgument("/c").addArgument("dir");
//CommandLine cmd0 = new CommandLine("ls").addArgument("-l");
CommandLine cmd1 = new CommandLine("sort");
ByteArrayOutputStream out = new ByteArrayOutputStream();
ByteArrayOutputStream err = new ByteArrayOutputStream();
ByteArrayInputStream in = new ByteArrayInputStream(new byte[0]);
try {
int result = pipe(out, err, in, cmd0, cmd1);
System.out.format("Result code: %d%n", result);
System.out.format("Out: %s%n", out.toString());
} catch (Exception e) {
e.printStackTrace();
}
}
}
One possible solution is to pass in a semaphore object into
DefaultExecutor#executeInternal which is notified once the process is started.
The execute(CommandLine, Map, ExecuteResultHandler) method can then wait on
this before returning.
> Race condition in DefaultExecutor#execute(cmd, handler)
> ---
>
> Key: EXEC-63
> URL: https://issues.apache.org/jira/browse/EXEC-63
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Windows 7/64 bit, JDK 1.6.0_27
>Reporter: Martin Sandiford
> Labels: deadlock
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> {{DefaultExecutor#execute(CommandLine, ExecuteResultHandler)}} can, and
> usually does, return before the target process has actually started.
[jira] [Created] (EXEC-63) Race condition in DefaultExecutor#execute(cmd, handler)
Race condition in DefaultExecutor#execute(cmd, handler)
---
Key: EXEC-63
URL: https://issues.apache.org/jira/browse/EXEC-63
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.1
Environment: Windows 7/64 bit, JDK 1.6.0_27
Reporter: Martin Sandiford
DefaultExecutor#execute(CommandLine, ExecuteResultHandler) can, and usually
does, return before the target process has actually started. This can result
in a race condition where several asynchronous processes are coupled by
PipedInputStream/PipedOutputStream objects.
The following example shows the issue:
import java.io.*;
import org.apache.commons.exec.*;
public class Borken {
public static int pipe(OutputStream out, OutputStream err, InputStream in,
CommandLine cmd0, CommandLine cmd1)
throws IOException {
PipedInputStream pipeIn = new PipedInputStream();
PipedOutputStream pipeOut = new PipedOutputStream(pipeIn);
DefaultExecutor exec0 = new DefaultExecutor();
exec0.setStreamHandler(new PumpStreamHandler(pipeOut, null, in));
exec0.execute(cmd0, new DefaultExecuteResultHandler());
// If the following line is commented, deadlock occurs
//try { Thread.sleep(100); } catch (InterruptedException e) { }
DefaultExecutor exec1 = new DefaultExecutor();
exec1.setStreamHandler(new PumpStreamHandler(out, err, pipeIn));
return exec1.execute(cmd1);
}
public static void main(String... args) {
CommandLine cmd0 = new
CommandLine("cmd").addArgument("/c").addArgument("dir");
//CommandLine cmd0 = new CommandLine("ls").addArgument("-l");
CommandLine cmd1 = new CommandLine("sort");
ByteArrayOutputStream out = new ByteArrayOutputStream();
ByteArrayOutputStream err = new ByteArrayOutputStream();
ByteArrayInputStream in = new ByteArrayInputStream(new byte[0]);
try {
int result = pipe(out, err, in, cmd0, cmd1);
System.out.format("Result code: %d%n", result);
System.out.format("Out: %s%n", out.toString());
} catch (Exception e) {
e.printStackTrace();
}
}
}
One possible solution is to pass in a semaphore object into
DefaultExecutor#executeInternal which is notified once the process is started.
The execute(CommandLine, Map, ExecuteResultHandler) method can then wait on
this before returning.
--
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] (COMPRESS-177) TarArchiveInputStream rejects valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated COMPRESS-177:
--
Comment: was deleted
(was: Hmm, is this actually fixed? I didn't see a commit in SVN...)
> TarArchiveInputStream rejects valid TAR file
>
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
> Fix For: 1.4
>
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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] (COMPRESS-177) TarArchiveInputStream rejects valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214108#comment-13214108
]
Gili commented on COMPRESS-177:
---
Hmm, is this actually fixed? I didn't see a commit in SVN...
> TarArchiveInputStream rejects valid TAR file
>
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
> Fix For: 1.4
>
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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-177) TarArchiveInputStream rejects valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved COMPRESS-177.
---
Resolution: Fixed
Fix Version/s: 1.4
> TarArchiveInputStream rejects valid TAR file
>
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
> Fix For: 1.4
>
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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-175) GNU Tar sometimes uses binary encoding for UID and GID
[ https://issues.apache.org/jira/browse/COMPRESS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMPRESS-175. --- Resolution: Fixed Fix Version/s: 1.4 > GNU Tar sometimes uses binary encoding for UID and GID > -- > > Key: COMPRESS-175 > URL: https://issues.apache.org/jira/browse/COMPRESS-175 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.3 >Reporter: Thomas Hallgren > Fix For: 1.4 > > Attachments: TarArchiveEntry.patch > > > Some tar files have UID and GID fields that start with the binary marker > 0x80. The TarArchiveEntry is unable to cope with that since it assumes that > UID and GID are always ASCII. -- 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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-746:
Description:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features (/) (r1292318)
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251 and
r1292270)
* Check the user guide
was:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features (/) (r1292318)
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251 and
r1292270)
* Check the user guide
Concerning the "FindBugs" warnings: Only those for "BOBYQAOptimizer" remain.
But I think that it is fine to leave them since it is advertised as "alpha
code".
Concerning the "CheckStyle" warnings: Only those for "PivotingQRDecomposition"
remain. But it will be removed from the release branch.
Is there something more to be done on the "trunk" before creating a release
branch?
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features (/) (r1292318)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution (/) (r1292572)
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214089#comment-13214089
]
Gilles commented on MATH-746:
-
bq. Merging with the other cases seems a better alternative, [...]
Done in revision 1292572.
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features (/) (r1292318)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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] (NET-423) FTPClient.storeFile might fail when ControlKeepAliveTimeout is set
[
https://issues.apache.org/jira/browse/NET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated NET-423:
Summary: FTPClient.storeFile might fail when ControlKeepAliveTimeout is set
(was: FTPClient.storeFIle might fail when ControlKeepAliveTimeout is set)
Fix typo in ticket tile.
> FTPClient.storeFile might fail when ControlKeepAliveTimeout is set
> --
>
> Key: NET-423
> URL: https://issues.apache.org/jira/browse/NET-423
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1
>Reporter: Jens Koch
>Priority: Minor
> Fix For: 3.1
>
>
> When setting ControlKeepAliveTimeout. FTPClient.__storeFile might fail when
> waiting for ack on ControlConnection.
> Current code:
> {noformat}
> // Get the transfer response
> boolean ok = completePendingCommand();
> if (csl != null) {
> csl.cleanUp(); // fetch any outstanding keepalive replies
> }
> {noformat}
> While CSL is active, the ControlConnection timeout is set to 1 sec., if using
> default. This timeout value doesn't leave much room in terms of network/end
> point latency.
> Replacing the code fragment above with the following fragment probably solves
> the problem (If proper ControlConnection timeout value is set):
> {noformat}
> if (csl != null) {
> csl.cleanUp(); // fetch any outstanding keepalive replies
> }
> // Get the transfer response
> boolean ok = completePendingCommand();
> {noformat}
> One workaround is to set ControlKeepAliveReplyTimeout to a higher value.
--
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] (COMPRESS-177) TarArchiveInputStream rejects valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213961#comment-13213961
]
Gili commented on COMPRESS-177:
---
Sebb,
Can you schedule this bug for version 1.4?
> TarArchiveInputStream rejects valid TAR file
>
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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] (IO-302) ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without BOM multiple times
[ https://issues.apache.org/jira/browse/IO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-302. Resolution: Fixed Fix Version/s: 2.2 Assignee: Gary D. Gregory In SVN. > ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without > BOM multiple times > --- > > Key: IO-302 > URL: https://issues.apache.org/jira/browse/IO-302 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.1 > Environment: Win7 64bit, Java 6 32bit >Reporter: Jan Steuerwald >Assignee: Gary D. Gregory > Fix For: 2.2 > > Attachments: IO-302.patch, Test.java, testfileBOM.xml, > testfileNoBOM.xml > > > Resetting the BOMInputStream doesn't reset the _fbLength_ member variable. > This causes _fbLength_ to grow bigger than the _firstBytes_ array (when the > file doesn't contain a BOM), which leads to an ArrayIndexOutOfBoundsException > in the _readFirstBytes_ method. > The attached test case reveals the problem. -- 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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213784#comment-13213784
]
Gilles commented on MATH-746:
-
bq. Why not just check p == pc within a certain tolerance, e.g. machine
precision? It'll provide a performance benefit at least.
The performance benefit would only occur in the single case where {{p == pc}}
(within the tolerance), which is to be balanced with the cost of evaluating one
more {{if}} every time. I'd guess that the merged code will be faster, on
average...
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features (/) (r1292318)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213774#comment-13213774
]
Dennis Hendriks commented on MATH-746:
--
bq. The issue is indeed whether this check is indispensable, or whether the
computation in the following block is always "good enough" even in the case
where p = (c - a) / (b - a)
I think it is "good enough".
bq. Why not just check p == pc within a certain tolerance, e.g. machine
precision? It'll provide a performance benefit at least.
I wouldn't do that. Merging with the other cases seems a better alternative,
especially since that is mathematically allowed.
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features (/) (r1292318)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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] (POOL-212) GenericObjectPool allows maxIdle < minIdle
GenericObjectPool allows maxIdle < minIdle -- Key: POOL-212 URL: https://issues.apache.org/jira/browse/POOL-212 Project: Commons Pool Issue Type: Bug Affects Versions: 1.4 Reporter: Sergejs Melderis Priority: Minor GenericObjectPool allows any values for minIdle and maxIdle, and performs no validation on those values. It allows maxIdle to be less than minIdle, and that creates weird behavior during eviction. After each eviction the Evictor thread calls ensureMinIdle() method which adds objects the pool using addObjectToPool() to make sure there at least minIdle objects in the pool.addObjectToPool() on another hand makes sure that there no more then maxIdle objects in the pool, and immediately destroys the newly created object. In my application we had minIdle configured to 100, but maxIdle wasn't configured and used the default value which is 8, and each eviction would create and destroy a bunch of objects. This issue can be fixed by adding checks in setMinIdle and setMaxIdle, or by adding maxIdle variable to the formula used in calculateDevicit() method. We use version 1.4, but I also tested it on latest 1.6 and observed the same behavior. -- 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] (CHAIN-66) Updated Chain documentation to include new changes to the API
[ https://issues.apache.org/jira/browse/CHAIN-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elijah Zupancic updated CHAIN-66: - Affects Version/s: 2.0 > Updated Chain documentation to include new changes to the API > - > > Key: CHAIN-66 > URL: https://issues.apache.org/jira/browse/CHAIN-66 > Project: Commons Chain > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Elijah Zupancic > Labels: documentaion > > Since the chain API is getting generics in the 2.0 release, we need to update > the documentation so that it reflects the API update. -- 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] (CHAIN-66) Updated Chain documentation to include new changes to the API
Updated Chain documentation to include new changes to the API - Key: CHAIN-66 URL: https://issues.apache.org/jira/browse/CHAIN-66 Project: Commons Chain Issue Type: Improvement Reporter: Elijah Zupancic Since the chain API is getting generics in the 2.0 release, we need to update the documentation so that it reflects the API update. -- 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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213731#comment-13213731
]
Ross Collins commented on MATH-746:
---
Why not just check p == pc within a certain tolerance, e.g. machine precision?
It'll provide a performance benefit at least.
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features (/) (r1292318)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213727#comment-13213727
]
Gilles commented on MATH-746:
-
bq. What is the complaint that "FindBugs" complains about at that line?
Strict comparison between floating point numbers, of course ;)
The issue is indeed whether this check is indispensable, or whether the
computation in the following block is always "good enough" even in the case
where {{p = (c - a) / (b - a)}}
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features (/) (r1292318)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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] (JCS-92) On shutdown .key (empty during runtime) not written and .data (not empty during runtime) deleted
On shutdown .key (empty during runtime) not written and .data (not empty during
runtime) deleted
Key: JCS-92
URL: https://issues.apache.org/jira/browse/JCS-92
Project: Commons JCS
Issue Type: Bug
Components: Composite Cache
Affects Versions: jcs-1.3
Environment: win 7x64; jvm 1.6
Reporter: Karl Klinge
On shutdown .key (which is empty during runtime) is not written from memory and
.data (not empty during runtime) is deleted.
cache ccf:
#
## Default Region Configuration
jcs.default=DC2
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=50
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
#
## CACHE REGIONS
jcs.region.sac=DC2
jcs.region.sac.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.region.sac.cacheattributes.MaxObjects=10
jcs.region.sac.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
jcs.region.sac.elementattributes.IsEternal=true
##jcs.region.sac.elementattributes.MaxLifeSeconds=172800 ## 2 Tage
jcs.region.sac.cacheattributes.DiskUsagePatternName=UPDATE
### AUXILIARY CACHES
# Indexed Disk Cache
jcs.auxiliary.DC2=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
jcs.auxiliary.DC2.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
jcs.auxiliary.DC2.attributes.DiskPath=c:/cache/status
jcs.auxiliary.DC2.attributes.MaxPurgatorySize=1000
jcs.auxiliary.DC2.attributes.MaxKeySize=10
jcs.auxiliary.DC2.attributes.OptimizeAtRemoveCount=3
jcs.auxiliary.DC2.attributes.OptimizeOnShutdown=true
jcs.auxiliary.DC2.attributes.MaxRecycleBinSize=1000
Object to write to cache:
key: string
value (all used classes in import implement Serializable):
>>
package de.spektra.rtd.sdb.condition;
import de.spektra.rtd.model.event.Event;
import de.spektra.rtd.model.event.StatusAlarmCondition;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.Map;
/**
*
* @author Klinge
*/
public class DistrictConditions implements Serializable{
//private static final java.util.logging.Logger logger =
Logger.getLogger("DistrictCondition");
private Map objectTypesConditions;
public DistrictConditions() {
this.objectTypesConditions = new HashMap();
}
public ObjectCondition setEvent(Event event) {
String objectType = event.getIdentification().getObjectType();
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
if (objectTypeConditions == null) {
objectTypeConditions = new DistrictObjectTypeConditions();
this.objectTypesConditions.put(objectType, objectTypeConditions);
}
return objectTypeConditions.setEvent(event);
}
public ObjectCondition getObjectCondtion(String objectType, String
identification) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
//logger.log(Level.INFO, "objectTypeConditions: {0}",
objectTypeConditions);
return objectTypeConditions.getObjectCondition(identification);
}
public Collection getObjectConditions(Collection
objectTypes) {
ArrayList objectConditions = new
ArrayList();
for (String objectType: objectTypes) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
if (objectTypeConditions!=null) {
objectConditions.addAll(objectTypeConditions.getObjectConditions());
}
}
return objectConditions;
}
public StatusAlarmCondition getCurrentStatusAlarmCondtition(String
objectType, String identification) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
return
objectTypeConditions.getCurrentStatusAlarmCondition(identification);
}
public Collection
getCurrentStatusAlarmCondtitions(Collection objectTypes) {
ArrayList statusAlarmConditions = new
ArrayList();
for (String objectType: objectTypes) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
if (objectTypeConditions!=null) {
statusAlarmConditions.addAll(objectTypeConditions.getCurrentStatusAlarmConditions());
}
}
return statusAlarmConditions;
}
}
--
This message is automatically genera
[jira] [Commented] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213677#comment-13213677
]
Dennis Hendriks commented on MATH-746:
--
bq. "FindBugs" complains about TriangularDistribution containing the line
marked "HERE".
What is the complaint that "FindBugs" complains about at that line?
bq. I think that this if-block should be removed and the test that follows it
should read [...]
Indeed, "c" is mathematically equal to "a + FastMath.sqrt(p * (b - a) * (c -
a))" when "p == pc". So, in theory, they could be merged. However, due to
numeric computations, they may not always be equal in practice. Whether that is
a problem, I don't know... (but I doubt it is...)
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features (/) (r1292318)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-746:
Description:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features (/) (r1292318)
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251 and
r1292270)
* Check the user guide
was:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251 and
r1292270)
* Check the user guide
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features (/) (r1292318)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213636#comment-13213636
]
Gilles commented on MATH-746:
-
"FindBugs" complains about {{TriangularDistribution}} containing the line
marked "HERE".
{code}
public double inverseCumulativeProbability(double p)
throws OutOfRangeException {
if (p < 0.0 || p > 1.0) {
throw new OutOfRangeException(p, 0, 1);
}
if (p == 0.0) {
return a;
}
if (p == 1.0) {
return b;
}
final double pc = (c - a) / (b - a);
if (p == pc) { // <-- HERE
return c;
}
if (p < pc) {
return a + FastMath.sqrt(p * (b - a) * (c - a));
}
return b - FastMath.sqrt((1 - p) * (b - a) * (b - c));
}
{code}
I think that this {{if}}-block should be removed and the test that follows it
should read:
{code}
if (p <= pc) {
// etc.
}
{code}
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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] (SANDBOX-395) Correct names for classes and variables related to operations on weights
[
https://issues.apache.org/jira/browse/SANDBOX-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claudio Squarcella resolved SANDBOX-395.
Resolution: Fixed
fixed, see [revision
1292272|http://svn.apache.org/viewvc?view=revision&revision=1292272].
> Correct names for classes and variables related to operations on weights
>
>
> Key: SANDBOX-395
> URL: https://issues.apache.org/jira/browse/SANDBOX-395
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Claudio Squarcella
>Priority: Minor
> Labels: graph, operations, weight
> Attachments:
> SANDBOX-395_CorrectClassAndVariableNamesForWeightOperations.patch
>
>
> Hi all,
> as discussed in ML already the current classes/variables that refer to
> operations on weights can be renamed for better expressiveness:
> * all the classes under {{weight.primitive}} should be renamed from {{XXX}}
> to {{XXXOperations}} because they actually contain operations on weights
> (they do not represent weights themselves);
> * in the actual algorithms, all variable names for weight operations should
> actually be something like {{weightOperations}} instead of the name of the
> interface (e.g. {{orderedMonoid}}).
--
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] (SANDBOX-395) Correct names for classes and variables related to operations on weights
[
https://issues.apache.org/jira/browse/SANDBOX-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213603#comment-13213603
]
Claudio Squarcella commented on SANDBOX-395:
Cool, I just committed!
> Correct names for classes and variables related to operations on weights
>
>
> Key: SANDBOX-395
> URL: https://issues.apache.org/jira/browse/SANDBOX-395
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Claudio Squarcella
>Priority: Minor
> Labels: graph, operations, weight
> Attachments:
> SANDBOX-395_CorrectClassAndVariableNamesForWeightOperations.patch
>
>
> Hi all,
> as discussed in ML already the current classes/variables that refer to
> operations on weights can be renamed for better expressiveness:
> * all the classes under {{weight.primitive}} should be renamed from {{XXX}}
> to {{XXXOperations}} because they actually contain operations on weights
> (they do not represent weights themselves);
> * in the actual algorithms, all variable names for weight operations should
> actually be something like {{weightOperations}} instead of the name of the
> interface (e.g. {{orderedMonoid}}).
--
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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-746:
Description:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251 and
r1292270)
* Check the user guide
was:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
* Check the user guide
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults (/) (r1292251
> and r1292270)
> * Check the user guide
--
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] (SANDBOX-396) [BeanUtils2] Implement clone() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213562#comment-13213562
]
Benedikt Ritter commented on SANDBOX-396:
-
Hey Simo,
thanks for your feedback! I'll have a look at it next weekend. Because I'm
currently working on setIndexed(), it requires me to finish that first, create
a patch and then revert the project. If I don't, you would have to deal with
several patches mixed up together in one file.
Have a nice day!
Benedikt
> [BeanUtils2] Implement clone() on DefaultBeanAccessor
> -
>
> Key: SANDBOX-396
> URL: https://issues.apache.org/jira/browse/SANDBOX-396
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
> Attachments: SANDBOX-396.txt
>
>
> Implement {{clone()}} on DefaultBeanAccessor:
> * create a new instance of the same type as the bean encapsulated by the
> Accessor
> * create a {{DefaultBeanAccessor}} for the new instance
> * call populate on the new {{DefaultBeanAccessor}} with {{this.describe()}}
> as argument
> * return the clone
--
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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-746:
Description:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
* Check the user guide
was:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
* Check the user guide
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver (/) (r1292245)
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults
> * Check the user guide
--
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-752) Triangulation algorithm
Triangulation algorithm --- Key: MATH-752 URL: https://issues.apache.org/jira/browse/MATH-752 Project: Commons Math Issue Type: Sub-task Reporter: Thomas Neidhart Priority: Minor Fix For: 3.1 The geometric package is currently lacking an algorithm for [Delaunay Triangulation|http://en.wikipedia.org/wiki/Delaunay_triangulation]. -- 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-750) Voronoi diagram algorithm
[ https://issues.apache.org/jira/browse/MATH-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-750: - Issue Type: Sub-task (was: New Feature) Parent: MATH-751 > Voronoi diagram algorithm > - > > Key: MATH-750 > URL: https://issues.apache.org/jira/browse/MATH-750 > Project: Commons Math > Issue Type: Sub-task >Reporter: Thomas Neidhart >Priority: Minor > Labels: 2d, geometric > Fix For: 3.1 > > > It would be nice to have an implementation of Voronoi diagrams in CM see > [http://en.wikipedia.org/wiki/Voronoi_diagram]. -- 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-749) Convex Hull algorithm
[ https://issues.apache.org/jira/browse/MATH-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-749: - Issue Type: Sub-task (was: New Feature) Parent: MATH-751 > Convex Hull algorithm > - > > Key: MATH-749 > URL: https://issues.apache.org/jira/browse/MATH-749 > Project: Commons Math > Issue Type: Sub-task >Reporter: Thomas Neidhart >Priority: Minor > Labels: 2d, geometric > Fix For: 3.1 > > > It would be nice to have convex hull implementations for 2D/3D space. There > are several known algorithms > [http://en.wikipedia.org/wiki/Convex_hull_algorithms]: > * Graham scan: O(n log n) > * Incremental: O(n log n) > * Divide and Conquer: O(n log n) > * Kirkpatrick-Seidel: O(n log h) > * Chan: O(n log h) > The preference would be on an algorithm that is easily extensible for higher > dimensions, so *Incremental* and *Divide and Conquer* would be prefered. -- 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-751) Standard algorithms in computational geometry
Standard algorithms in computational geometry - Key: MATH-751 URL: https://issues.apache.org/jira/browse/MATH-751 Project: Commons Math Issue Type: New Feature Reporter: Thomas Neidhart Priority: Minor Fix For: 3.1 CM is currently lacking support for several standard algorithms in computational geometry like triangulation, voronoi diagrams,... -- 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
