[jira] [Commented] (COMPRESS-176) ArchiveInputStream#getNextEntry(): Problems with WinZip directories with Umlauts
[
https://issues.apache.org/jira/browse/COMPRESS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217974#comment-13217974
]
Wurstbrot mit Senf commented on COMPRESS-176:
-
Hi all, sounds promising. Thanks a lot, I'm looking forward to the next release.
And by the way, how could you tell that the name's a fake? ;-)
> ArchiveInputStream#getNextEntry(): Problems with WinZip directories with
> Umlauts
>
>
> Key: COMPRESS-176
> URL: https://issues.apache.org/jira/browse/COMPRESS-176
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
> Environment: Windows 7
>Reporter: Wurstbrot mit Senf
>Assignee: Stefan Bodewig
> Fix For: 1.4
>
> Attachments: test-7zip.zip, test-windows.zip, test-winzip.zip,
> testzap-winzip.zip
>
>
> There is a problem when handling a WinZip-created zip with Umlauts in
> directories.
> I'm accessing a zip file created with WinZip containing a directory with an
> umlaut ("ä") with ArchiveInputStream. When creating the zip file the
> unicode-flag of winzip had been active.
> The following problem occurs when accessing the entries of the zip:
> the ArchiveEntry for a directory containing an umlaut is not marked as a
> directory and the file names for the directory and all files contained in
> that directory contain backslashes instead of slashes (i.e. completely
> different to all other files in directories with no umlaut in their path).
> There is no difference when letting the ArchiveStreamFactory decide which
> ArchiveInputStream to create or when using the ZipArchiveInputStream
> constructor with the correct encoding (I've tried different encodings CP437,
> CP850, ISO-8859-15, but still the problem persisted).
> This problem does not occur when using the very same zip file but compressed
> by 7zip or the built-in Windows 7 zip functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-756) double as FieldElement
double as FieldElement
--
Key: MATH-756
URL: https://issues.apache.org/jira/browse/MATH-756
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
As discussed on the mailing-list, it is proposed to develop a wrapper class
around the {{double}} primitive type. This wrapper class should implement
{{FieldElement}}. This would allow generic calculations on exchangeable number
types (big fractions, big decimals, fractions, decimals). This class will be
called {{Decimal64}} (together with the corresponding {{Decimal64Field}}).
Similarly, to the {{BigReal}} class, the newly created {{Decimal64}} class
could go to the {{o.a.c.m3.util}} package.
--
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-176) ArchiveInputStream#getNextEntry(): Problems with WinZip directories with Umlauts
[
https://issues.apache.org/jira/browse/COMPRESS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217899#comment-13217899
]
Stefan Bodewig commented on COMPRESS-176:
-
Workaround and tests are in svn revision 1294460
I'll look into creating a test archive for the opposite direction today.
> ArchiveInputStream#getNextEntry(): Problems with WinZip directories with
> Umlauts
>
>
> Key: COMPRESS-176
> URL: https://issues.apache.org/jira/browse/COMPRESS-176
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
> Environment: Windows 7
>Reporter: Wurstbrot mit Senf
>Assignee: Stefan Bodewig
> Fix For: 1.4
>
> Attachments: test-7zip.zip, test-windows.zip, test-winzip.zip,
> testzap-winzip.zip
>
>
> There is a problem when handling a WinZip-created zip with Umlauts in
> directories.
> I'm accessing a zip file created with WinZip containing a directory with an
> umlaut ("ä") with ArchiveInputStream. When creating the zip file the
> unicode-flag of winzip had been active.
> The following problem occurs when accessing the entries of the zip:
> the ArchiveEntry for a directory containing an umlaut is not marked as a
> directory and the file names for the directory and all files contained in
> that directory contain backslashes instead of slashes (i.e. completely
> different to all other files in directories with no umlaut in their path).
> There is no difference when letting the ArchiveStreamFactory decide which
> ArchiveInputStream to create or when using the ZipArchiveInputStream
> constructor with the correct encoding (I've tried different encodings CP437,
> CP850, ISO-8859-15, but still the problem persisted).
> This problem does not occur when using the very same zip file but compressed
> by 7zip or the built-in Windows 7 zip functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EMAIL-114) Methods to add multiple To, cc, Bcc is desired
Methods to add multiple To, cc, Bcc is desired -- Key: EMAIL-114 URL: https://issues.apache.org/jira/browse/EMAIL-114 Project: Commons Email Issue Type: Improvement Reporter: Gokul Nanthakumar C Currently if we have list of email address as string adding them to mail is possible only by looping or converting them as list of java.mail.internet.InternetAddress. Method like addTo(String[] emails) is desired. -- 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-181) Tar files created by AIX native tar, and which contain symlinks, cannot be read by TarArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217827#comment-13217827
]
Sebb commented on COMPRESS-181:
---
The problem field is the modification time for the symbolic link, which
Compress expects to be either all null or valid octal with trailing null/space.
Note: 7zip reads the file OK but complains that there is data after the end of
the archive.
It treats the link field as having no mtime.
I've yet to find any documentation that says a leading null is allowed.
Perhaps AIX tar is being lazy and failing to null the whole mtime field (which
Compress could handle).
> Tar files created by AIX native tar, and which contain symlinks, cannot be
> read by TarArchiveInputStream
>
>
> Key: COMPRESS-181
> URL: https://issues.apache.org/jira/browse/COMPRESS-181
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: AIX 5.3
>Reporter: Robert Clark
> Attachments: simple-aix-native-tar.tar
>
>
> A simple tar file created on AIX using the native ({{/usr/bin/tar}} tar
> utility) *and* which contains a symbolic link, cannot be loaded by
> TarArchiveInputStream:
> {noformat}
> java.io.IOException: Error detected parsing the header
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:201)
> at Extractor.extract(Extractor.java:13)
> at Extractor.main(Extractor.java:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> at
> org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
> at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
> at org.apache.tools.ant.Main.runBuild(Main.java:809)
> at org.apache.tools.ant.Main.startAnt(Main.java:217)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
> Caused by: java.lang.IllegalArgumentException: Invalid byte 0 at offset 0 in
> '{NUL}1722000726 ' len=12
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:99)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:819)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:314)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:199)
> ... 29 more
> {noformat}
> Tested with 1.2 and the 1.4 nightly build from Feb 23
> ({{Implementation-Build: trunk@r1292625; 2012-02-23 03:20:30+}})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (EXEC-63) Race condition in DefaultExecutor#execute(cmd, handler)
[
https://issues.apache.org/jira/browse/EXEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217797#comment-13217797
]
Martin Sandiford edited comment on EXEC-63 at 2/28/12 1:26 AM:
---
Patch for fix from https://github.com/msandiford/commons-exec commit
0c7e9457f31ea0322d18dcb157d5192a25f0e490
{code:title=fix.diff|borderStyle=solid}
--- a/src/main/java/org/apache/commons/exec/DefaultExecutor.java
+++ b/src/main/java/org/apache/commons/exec/DefaultExecutor.java
@@ -161,7 +161,7 @@ public class DefaultExecutor implements Executor {
throw new IOException(workingDirectory + " doesn't exist.");
}
-return executeInternal(command, environment, workingDirectory,
streamHandler);
+return executeInternal(command, null, environment, workingDirectory,
streamHandler);
}
@@ -189,13 +189,14 @@ public class DefaultExecutor implements Executor {
watchdog.setProcessNotStarted();
}
+final SimpleCondition condition = new SimpleCondition();
Runnable runnable = new Runnable()
{
public void run()
{
int exitValue = Executor.INVALID_EXITVALUE;
try {
-exitValue = executeInternal(command, environment,
workingDirectory, streamHandler);
+exitValue = executeInternal(command, condition,
environment, workingDirectory, streamHandler);
handler.onProcessComplete(exitValue);
} catch (ExecuteException e) {
handler.onProcessFailed(e);
@@ -207,6 +208,9 @@ public class DefaultExecutor implements Executor {
this.executorThread = createThread(runnable, "Exec Default Executor");
getExecutorThread().start();
+
+// Wait until the thread tells us we have actually started
+condition.sleep();
}
/** @see org.apache.commons.exec.Executor#setExitValue(int) */
@@ -316,6 +320,33 @@ public class DefaultExecutor implements Executor {
}
/**
+ * Simple thread notify mechanism.
+ */
+private static final class SimpleCondition {
+private final Object lock = new Object();
+private volatile boolean notified = false;
+
+public void sleep() {
+try {
+synchronized (lock) {
+while (!notified) {
+lock.wait();
+}
+}
+} catch (InterruptedException e) {
+Thread.currentThread().interrupt();
+}
+}
+
+public void wakeup() {
+synchronized (lock) {
+notified = true;
+lock.notifyAll();
+}
+}
+}
+
+/**
* Execute an internal process. If the executing thread is interrupted
while waiting for the
* child process to return the child process will be killed.
*
@@ -326,12 +357,20 @@ public class DefaultExecutor implements Executor {
* @return the exit code of the process
* @throws IOException executing the process failed
*/
-private int executeInternal(final CommandLine command, final Map
environment,
-final File dir, final ExecuteStreamHandler streams) throws
IOException {
+private int executeInternal(final CommandLine command, final
SimpleCondition cond,
+final Map environment, final File dir, final ExecuteStreamHandler
streams)
+throws IOException {
setExceptionCaught(null);
-final Process process = this.launch(command, environment, dir);
+final Process process;
+try {
+process = this.launch(command, environment, dir);
+} finally {
+// If necessary, let our parent know that the process has launched
+if (cond != null)
+cond.wakeup();
+}
try {
streams.setProcessInputStream(process.getOutputStream());
{code}
was (Author: msandiford):
Patch for test case from https://github.com/msandiford/commons-exec commit
0c7e9457f31ea0322d18dcb157d5192a25f0e490
{code:title=fix.diff|borderStyle=solid}
--- a/src/main/java/org/apache/commons/exec/DefaultExecutor.java
+++ b/src/main/java/org/apache/commons/exec/DefaultExecutor.java
@@ -161,7 +161,7 @@ public class DefaultExecutor implements Executor {
throw new IOException(workingDirectory + " doesn't exist.");
}
-return executeInternal(command, environment, workingDirectory,
streamHandler);
+return executeInternal(command, null, environment, workingDirectory,
streamHandler);
}
@@ -189,13 +189,14 @@ public class DefaultExecutor implements Executor {
watchdog.setProcessNotStarted();
}
+final SimpleCondition condition = new SimpleCondition();
[jira] [Commented] (EXEC-63) Race condition in DefaultExecutor#execute(cmd, handler)
[
https://issues.apache.org/jira/browse/EXEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217797#comment-13217797
]
Martin Sandiford commented on EXEC-63:
--
Patch for test case from https://github.com/msandiford/commons-exec commit
0c7e9457f31ea0322d18dcb157d5192a25f0e490
{code:title=fix.diff|borderStyle=solid}
--- a/src/main/java/org/apache/commons/exec/DefaultExecutor.java
+++ b/src/main/java/org/apache/commons/exec/DefaultExecutor.java
@@ -161,7 +161,7 @@ public class DefaultExecutor implements Executor {
throw new IOException(workingDirectory + " doesn't exist.");
}
-return executeInternal(command, environment, workingDirectory,
streamHandler);
+return executeInternal(command, null, environment, workingDirectory,
streamHandler);
}
@@ -189,13 +189,14 @@ public class DefaultExecutor implements Executor {
watchdog.setProcessNotStarted();
}
+final SimpleCondition condition = new SimpleCondition();
Runnable runnable = new Runnable()
{
public void run()
{
int exitValue = Executor.INVALID_EXITVALUE;
try {
-exitValue = executeInternal(command, environment,
workingDirectory, streamHandler);
+exitValue = executeInternal(command, condition,
environment, workingDirectory, streamHandler);
handler.onProcessComplete(exitValue);
} catch (ExecuteException e) {
handler.onProcessFailed(e);
@@ -207,6 +208,9 @@ public class DefaultExecutor implements Executor {
this.executorThread = createThread(runnable, "Exec Default Executor");
getExecutorThread().start();
+
+// Wait until the thread tells us we have actually started
+condition.sleep();
}
/** @see org.apache.commons.exec.Executor#setExitValue(int) */
@@ -316,6 +320,33 @@ public class DefaultExecutor implements Executor {
}
/**
+ * Simple thread notify mechanism.
+ */
+private static final class SimpleCondition {
+private final Object lock = new Object();
+private volatile boolean notified = false;
+
+public void sleep() {
+try {
+synchronized (lock) {
+while (!notified) {
+lock.wait();
+}
+}
+} catch (InterruptedException e) {
+Thread.currentThread().interrupt();
+}
+}
+
+public void wakeup() {
+synchronized (lock) {
+notified = true;
+lock.notifyAll();
+}
+}
+}
+
+/**
* Execute an internal process. If the executing thread is interrupted
while waiting for the
* child process to return the child process will be killed.
*
@@ -326,12 +357,20 @@ public class DefaultExecutor implements Executor {
* @return the exit code of the process
* @throws IOException executing the process failed
*/
-private int executeInternal(final CommandLine command, final Map
environment,
-final File dir, final ExecuteStreamHandler streams) throws
IOException {
+private int executeInternal(final CommandLine command, final
SimpleCondition cond,
+final Map environment, final File dir, final ExecuteStreamHandler
streams)
+throws IOException {
setExceptionCaught(null);
-final Process process = this.launch(command, environment, dir);
+final Process process;
+try {
+process = this.launch(command, environment, dir);
+} finally {
+// If necessary, let our parent know that the process has launched
+if (cond != null)
+cond.wakeup();
+}
try {
streams.setProcessInputStream(process.getOutputStream());
{code}
> 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. 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.e
[jira] [Commented] (EXEC-63) Race condition in DefaultExecutor#execute(cmd, handler)
[
https://issues.apache.org/jira/browse/EXEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217795#comment-13217795
]
Martin Sandiford commented on EXEC-63:
--
Patch for test case from https://github.com/msandiford/commons-exec commit
4c2f449dd5605975d38a2c686dec3c00b7414eee
{code:title=test-case.diff|borderStyle=solid}
--- a/src/test/java/org/apache/commons/exec/DefaultExecutorTest.java
+++ b/src/test/java/org/apache/commons/exec/DefaultExecutorTest.java
@@ -1094,6 +1094,49 @@ public class DefaultExecutorTest extends TestCase {
assertTrue("Not a single process was killed by the watch dog",
watchdogKilledProcessCounter > 0);
}
+
+/**
+ * Test EXEC-63 (https://issues.apache.org/jira/browse/EXEC-63).
+ *
+ * Frequent deadlock when constructing a command pipe chain.
+ * Please note that a successful test is no proof that the issues was
fixed.
+ *
+ * @throws IOException the test failed
+ */
+public void testExec_63() throws IOException {
+CommandLine cmd0;
+CommandLine cmd1;
+if (OS.isFamilyUnix()) {
+cmd0 = new CommandLine("ls").addArgument("-l");
+cmd1 = new CommandLine("sort");
+} else if (OS.isFamilyWindows()) {
+cmd0 = new CommandLine("cmd").addArgument("/c").addArgument("dir");
+cmd1 = new CommandLine("sort");
+} else {
+System.err.println("The test 'testExec_63' does not support the
following OS : " + System.getProperty("os.name"));
+return;
+}
+ByteArrayOutputStream out = new ByteArrayOutputStream();
+ByteArrayOutputStream err = new ByteArrayOutputStream();
+ByteArrayInputStream in = new ByteArrayInputStream(new byte[0]);
+PipedInputStream pipeIn = new PipedInputStream();
+PipedOutputStream pipeOut = new PipedOutputStream(pipeIn);
+DefaultExecutor exec0 = new DefaultExecutor();
+ExecuteWatchdog watchdog0 = new ExecuteWatchdog(5000);
+exec0.setWatchdog(watchdog0);
+exec0.setStreamHandler(new PumpStreamHandler(pipeOut, null, in));
+exec0.execute(cmd0, new DefaultExecuteResultHandler());
+
+DefaultExecutor exec1 = new DefaultExecutor();
+ExecuteWatchdog watchdog1 = new ExecuteWatchdog(5000);
+exec1.setWatchdog(watchdog1);
+exec1.setStreamHandler(new PumpStreamHandler(out, err, pipeIn));
+int result = exec1.execute(cmd1);
+assertTrue("Command exited with status 0", result == 0);
+assertTrue("Output was as expected", out.toString().length() > 500);
+assertEquals("No errors were output", err.toString().trim(), "");
+}
+
// ==
// === Long running tests
// ==
{code}
> 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. 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 ByteArr
[jira] [Resolved] (CHAIN-65) Rename package org.apache.commons.chain to org.apache.commons.chain2 for v2 of chain
[ https://issues.apache.org/jira/browse/CHAIN-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved CHAIN-65. - Resolution: Fixed Assignee: Simone Tripodi Thanks for contributing Elijah, your patch has been successfully applied, see r1294379 > Rename package org.apache.commons.chain to org.apache.commons.chain2 for v2 > of chain > > > Key: CHAIN-65 > URL: https://issues.apache.org/jira/browse/CHAIN-65 > Project: Commons Chain > Issue Type: Task >Affects Versions: 2.0 >Reporter: Elijah Zupancic >Assignee: Simone Tripodi > Fix For: 2.0 > > Attachments: CHAIN-65.patch > > > Since we are breaking binary compatibility in chain 2.0, we will rename the > package so that users of the 1.0 libraries are not adversely affected. -- 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] (CONFIGURATION-480) Reading Manifest files using PropertiesConfiguration
[
https://issues.apache.org/jira/browse/CONFIGURATION-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217549#comment-13217549
]
Oliver Heger commented on CONFIGURATION-480:
If your use case is just splitting key value pairs separated by a colon, then
this should be possible with PropertiesConfiguration out of the box. Our unit
test suite contains tests with files using the colon as alternative separator.
So I have no idea why this does not work in your case. As I pointed out, the
exception you posted indicates that PropertiesConfiguration is not used at all.
However, manifest files can become more complex, e.g. there is a hard limit for
the line length and automatic line wrapping, or a special syntax for directives
or properties with multiple values intoduced by the OSGi specification. Commons
Configuration does not contain a class which supports these features or is
specialized on parsing manifest files.
> Reading Manifest files using PropertiesConfiguration
>
>
> Key: CONFIGURATION-480
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-480
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Chris Molozian
>
> I've searched through the documentation and online with Google. The
> documentation for PropertiesConfiguration explains that it can parse files
> with '=' or ':' or ' ' as delimiters. I have a MANIFEST.MF file with the
> following format:
> {code:title=MANIFEST.MF|borderStyle=solid}
> Manifest-Version: 1.0
> Implementation-Title: webapp
> Implementation-Version: 0.0.1
> Created-By: Gradle 1.0-milestone-6
> Build-Jdk: 1.6.0_26
> {code}
> I've tried to use the PropertiesConfiguration to parse this file, assuming
> that the ' ' delimiter would be used to divide key-value pairs. Instead I get
> the following error:
> {code}
> java.lang.IllegalArgumentException: Key for add operation must be defined!
> at
> org.apache.commons.configuration.tree.DefaultExpressionEngine.prepareAdd(DefaultExpressionEngine.java:420)
> at
> org.apache.commons.configuration.HierarchicalConfiguration.addPropertyDirect(HierarchicalConfiguration.java:383)
> at
> org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.addPropertyDirect(AbstractHierarchicalFileConfiguration.java:147)
> at
> org.apache.commons.configuration.AbstractConfiguration.addPropertyValues(AbstractConfiguration.java:423)
> at
> org.apache.commons.configuration.AbstractConfiguration.append(AbstractConfiguration.java:1271)
> {code}
> At the moment I've created a (very rough) custom PropertiesReader as
> suggested by the User Guide for handling "unconventional formats".
> {code}
> private static class ManifestPropertiesReader
> extends PropertiesConfiguration.PropertiesReader {
> public ManifestPropertiesReader(final Reader in, final char delimiter) {
> super(in, delimiter);
> }
> @Override
> protected void parseProperty(final String line) {
> final int pos = line.indexOf(':');
> final String key = line.substring(0, pos).trim();
> final String value = line.substring(pos + 1).trim();
> initPropertyName(key);
> initPropertyValue(value);
> }
> }
> {code}
> And:
> {code}
> private static class ManifestIOFactory
> extends PropertiesConfiguration.DefaultIOFactory {
> /** Use a custom {@code PropertiesReader} for Manifest files. */
> @Override
> public PropertiesReader createPropertiesReader(final Reader in,
> final char delimiter) {
> return new ManifestPropertiesReader(in, delimiter);
> }
> }
> {code}
> Should all this be necessary to parse MANIFEST.MF files or have I missed
> something?
--
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] (LANG-789) SerializationUtils clone method fails to perform some deep cloning
SerializationUtils clone method fails to perform some deep cloning -- Key: LANG-789 URL: https://issues.apache.org/jira/browse/LANG-789 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Environment: Windows 7, Java 7 (1.7.0_03), Apache Commons Lang 3.1, NetBeans 7.1 Reporter: Harry Levinson SerializationUtils clone method fails to perform some deep cloning of at least some objects containing Externalizable subobjects. Here is the @version text from the SerializationUtils.java source file: SerializationUtils.java 1199718 2011-11-09 12:43:20Z sebb $ To reproduce possible bug: 1. Create two classes (let's call them Parent and Child) and mark both as "implements Externalizable". 2. Write required Externalizable methods readExternal and writeExternal 3. Make Child a private member/field of Parent 4. Write code to override toString if necessary for Parent and Child 5. Create a separate Java class to test creation and cloning of Parent and Child 6. In the test class write to code to do this: a. Create a Parent object b. Create a Child object c. Attach Child to Parent via setter d. Print out Parent object e. Use SerializationUtils.clone() to clone Parent (call it ParentClone) f. Print ParentClone 7. Compare print output of Parent and ParentClone, observe that ParentClone does not contain Child object -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13217354#comment-13217354 ] Elijah Zupancic commented on CHAIN-66: -- My plan is to take this on. I'm just very busy at work right now, so I've been trying to learn docbook format on the bus on my way to and from work. If you want to take on breaking chain into separate modules, that would be much appreciated. > 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] [Updated] (COMPRESS-181) Tar files created by AIX native tar, and which contain symlinks, cannot be read by TarArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Clark updated COMPRESS-181:
--
Description:
A simple tar file created on AIX using the native ({{/usr/bin/tar}} tar
utility) *and* which contains a symbolic link, cannot be loaded by
TarArchiveInputStream:
{noformat}
java.io.IOException: Error detected parsing the header
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:201)
at Extractor.extract(Extractor.java:13)
at Extractor.main(Extractor.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
Caused by: java.lang.IllegalArgumentException: Invalid byte 0 at offset 0 in
'{NUL}1722000726 ' len=12
at
org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:99)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:819)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:314)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:199)
... 29 more
{noformat}
Tested with 1.2 and the 1.4 nightly build from Feb 23 ({{Implementation-Build:
trunk@r1292625; 2012-02-23 03:20:30+}})
was:
A simple tar file created on AIX using the native ({{/usr/bin/tar}} tar
utility) *and* which contains a symbolic link, cannot be loaded by
TarArchiveInputStream:
{noformat}
java.io.IOException: Error detected parsing the header
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:201)
at Extractor.extract(Extractor.java:13)
at Extractor.main(Extractor.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
[jira] [Updated] (COMPRESS-181) Tar files created by AIX native tar, and which contain symlinks, cannot be read by TarArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Clark updated COMPRESS-181:
--
Attachment: simple-aix-native-tar.tar
An example tar file, containing a symbolic link, created by the AIX native tar
utility
> Tar files created by AIX native tar, and which contain symlinks, cannot be
> read by TarArchiveInputStream
>
>
> Key: COMPRESS-181
> URL: https://issues.apache.org/jira/browse/COMPRESS-181
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: AIX 5.3
>Reporter: Robert Clark
> Attachments: simple-aix-native-tar.tar
>
>
> A simple tar file created on AIX using the native ({{/usr/bin/tar}} tar
> utility) *and* which contains a symbolic link, cannot be loaded by
> TarArchiveInputStream:
> {noformat}
> java.io.IOException: Error detected parsing the header
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:201)
> at Extractor.extract(Extractor.java:13)
> at Extractor.main(Extractor.java:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> at
> org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
> at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
> at org.apache.tools.ant.Main.runBuild(Main.java:809)
> at org.apache.tools.ant.Main.startAnt(Main.java:217)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
> Caused by: java.lang.IllegalArgumentException: Invalid byte 0 at offset 0 in
> '{NUL}1722000726 ' len=12
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:99)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:819)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:314)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:199)
> ... 29 more
> {noformat}
> Tested with 1.2 and the 1.4 nightly build from Feb 23
> ({{Implementation-Build: trunk@r1292625; 2012-02-23 03:20:30+}})
> I don't have a place to post the example tar file, but I can send it to
> anyone who wants it (size is 10240 bytes)
--
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] (COMPRESS-181) Tar files created by AIX native tar, and which contain symlinks, cannot be read by TarArchiveInputStream
Tar files created by AIX native tar, and which contain symlinks, cannot be read
by TarArchiveInputStream
Key: COMPRESS-181
URL: https://issues.apache.org/jira/browse/COMPRESS-181
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.3, 1.2, 1.4
Environment: AIX 5.3
Reporter: Robert Clark
A simple tar file created on AIX using the native ({{/usr/bin/tar}} tar
utility) *and* which contains a symbolic link, cannot be loaded by
TarArchiveInputStream:
{noformat}
java.io.IOException: Error detected parsing the header
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:201)
at Extractor.extract(Extractor.java:13)
at Extractor.main(Extractor.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
Caused by: java.lang.IllegalArgumentException: Invalid byte 0 at offset 0 in
'{NUL}1722000726 ' len=12
at
org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:99)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:819)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:314)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:199)
... 29 more
{noformat}
Tested with 1.2 and the 1.4 nightly build from Feb 23 ({{Implementation-Build:
trunk@r1292625; 2012-02-23 03:20:30+}})
I don't have a place to post the example tar file, but I can send it to anyone
who wants it (size is 10240 bytes)
--
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-754) Additional Fraction Constructor
[ https://issues.apache.org/jira/browse/MATH-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217185#comment-13217185 ] Travis Hanna commented on MATH-754: --- That's strange. I don't see the final declaration either when I look in SVN but I swear I got a compile-time error when I tried to extend the class. I'll confirm the version number that we're using and figure out where the discrepancy comes from. Perhaps I made an error (accidentally imported a Fraction class from some other library, misinterpreted the error message, etc.) I can submit a factory class for consideration. It seems like 3.0 development is nearing a close though. Should I attach another patch to this issue or would I be better off creating a new Jira issue and marking it 3.1? > Additional Fraction Constructor > --- > > Key: MATH-754 > URL: https://issues.apache.org/jira/browse/MATH-754 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 > Environment: All >Reporter: Travis Hanna >Priority: Minor > Labels: features, newbie, patch > Fix For: 3.0 > > Attachments: math.patch > > > I'm writing some code which outputs fractional measurements meant for human > consumption. I need a constructor for Fraction which allows you to restrict > the denominators to a finite set. This is necessary due to the fact that > real-world tools are only available with certain fractions. For example, it's > next to impossible to find a ruler with 1/7 inch marked :). > I'm attaching a patch which implements the functionality. I've attempted to > mimic the style of the existing code as much as possible. One caveat: I don't > speak French so the french error message is a computer-generated translation > and probably very poor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-480) Reading Manifest files using PropertiesConfiguration
[
https://issues.apache.org/jira/browse/CONFIGURATION-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217169#comment-13217169
]
Chris Molozian commented on CONFIGURATION-480:
--
Apologies for the late response, I've embedded the code that's attempting to
parse the MANIFEST.MF file:
{code}
PropertiesConfiguration manifestConf = new PropertiesConfiguration();
manifestConf.setIOFactory(new ManifestIOFactory());
manifestConf.setFileName("/META-INF/MANIFEST.MF");
manifestConf.load();
{code}
You didn't really answer my other question, is there anything within Apache
Commons Configuration that supports the parsing of the MANIFEST.MF format?
Thanks.
> Reading Manifest files using PropertiesConfiguration
>
>
> Key: CONFIGURATION-480
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-480
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Chris Molozian
>
> I've searched through the documentation and online with Google. The
> documentation for PropertiesConfiguration explains that it can parse files
> with '=' or ':' or ' ' as delimiters. I have a MANIFEST.MF file with the
> following format:
> {code:title=MANIFEST.MF|borderStyle=solid}
> Manifest-Version: 1.0
> Implementation-Title: webapp
> Implementation-Version: 0.0.1
> Created-By: Gradle 1.0-milestone-6
> Build-Jdk: 1.6.0_26
> {code}
> I've tried to use the PropertiesConfiguration to parse this file, assuming
> that the ' ' delimiter would be used to divide key-value pairs. Instead I get
> the following error:
> {code}
> java.lang.IllegalArgumentException: Key for add operation must be defined!
> at
> org.apache.commons.configuration.tree.DefaultExpressionEngine.prepareAdd(DefaultExpressionEngine.java:420)
> at
> org.apache.commons.configuration.HierarchicalConfiguration.addPropertyDirect(HierarchicalConfiguration.java:383)
> at
> org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.addPropertyDirect(AbstractHierarchicalFileConfiguration.java:147)
> at
> org.apache.commons.configuration.AbstractConfiguration.addPropertyValues(AbstractConfiguration.java:423)
> at
> org.apache.commons.configuration.AbstractConfiguration.append(AbstractConfiguration.java:1271)
> {code}
> At the moment I've created a (very rough) custom PropertiesReader as
> suggested by the User Guide for handling "unconventional formats".
> {code}
> private static class ManifestPropertiesReader
> extends PropertiesConfiguration.PropertiesReader {
> public ManifestPropertiesReader(final Reader in, final char delimiter) {
> super(in, delimiter);
> }
> @Override
> protected void parseProperty(final String line) {
> final int pos = line.indexOf(':');
> final String key = line.substring(0, pos).trim();
> final String value = line.substring(pos + 1).trim();
> initPropertyName(key);
> initPropertyValue(value);
> }
> }
> {code}
> And:
> {code}
> private static class ManifestIOFactory
> extends PropertiesConfiguration.DefaultIOFactory {
> /** Use a custom {@code PropertiesReader} for Manifest files. */
> @Override
> public PropertiesReader createPropertiesReader(final Reader in,
> final char delimiter) {
> return new ManifestPropertiesReader(in, delimiter);
> }
> }
> {code}
> Should all this be necessary to parse MANIFEST.MF files or have I missed
> something?
--
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-754) Additional Fraction Constructor
[ https://issues.apache.org/jira/browse/MATH-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217136#comment-13217136 ] Gilles commented on MATH-754: - bq. [...] in commons-math 2.2, Fraction is declared final. [...] I don't see this in the code! bq. [...] I do have one counter argument. [...] I'm not sure that it's really the same kind of limitation, but I agree that where to draw the line is also a matter of taste... You should then start a discussion on the "dev" ML. bq. Maybe there should be a separate class that is responsible for converting doubles to Fractions to keep the Fraction class clean? That would be nice. I'm pretty sure that other people will also be interested in this approach. I think that the "factory" pattern will be quite appropriate for implementing this functionality. > Additional Fraction Constructor > --- > > Key: MATH-754 > URL: https://issues.apache.org/jira/browse/MATH-754 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 > Environment: All >Reporter: Travis Hanna >Priority: Minor > Labels: features, newbie, patch > Fix For: 3.0 > > Attachments: math.patch > > > I'm writing some code which outputs fractional measurements meant for human > consumption. I need a constructor for Fraction which allows you to restrict > the denominators to a finite set. This is necessary due to the fact that > real-world tools are only available with certain fractions. For example, it's > next to impossible to find a ruler with 1/7 inch marked :). > I'm attaching a patch which implements the functionality. I've attempted to > mimic the style of the existing code as much as possible. One caveat: I don't > speak French so the french error message is a computer-generated translation > and probably very poor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217123#comment-13217123 ] Stefan Bodewig commented on COMPRESS-16: I plan to look up what the GNU tar implementation does, may take a few days, though. I agree with Gili this issue has by now outgrown COMPRESS-16 as it specifically only dealt with lengths. OTOH it is not restricted to star either, if we start supporting "bigger numbers" for group or date, we should support star as well as PAX. > unable to extract a TAR file that contains an entry which is 10 GB in size > -- > > Key: COMPRESS-16 > URL: https://issues.apache.org/jira/browse/COMPRESS-16 > Project: Commons Compress > Issue Type: Bug > Components: Archivers > Environment: I am using win xp sp3, but this should be platform > independent. >Reporter: Sam Smith > Fix For: 1.4 > > Attachments: > 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, > 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, > 0004-Prefer-octal-over-binary-size-representation.patch, ant-8GB-tar.patch, > patch-for-compress.txt > > > I made a TAR file which contains a file entry where the file is 10 GB in size. > When I attempt to extract the file using TarInputStream, it fails with the > following stack trace: > java.io.IOException: unexpected EOF with 24064 bytes unread > at > org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) > at > org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) > So, TarInputStream does not seem to support large (> 8 GB?) files. > Here is something else to note: I created that TAR file using TarOutputStream > , which did not complain when asked to write a 10 GB file into the TAR file, > so I assume that TarOutputStream has no file size limits? That, or does it > silently create corrupted TAR files (which would be the worst situation of > all...)? -- 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-176) ArchiveInputStream#getNextEntry(): Problems with WinZip directories with Umlauts
[
https://issues.apache.org/jira/browse/COMPRESS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-176:
Fix Version/s: 1.4
> ArchiveInputStream#getNextEntry(): Problems with WinZip directories with
> Umlauts
>
>
> Key: COMPRESS-176
> URL: https://issues.apache.org/jira/browse/COMPRESS-176
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
> Environment: Windows 7
>Reporter: Wurstbrot mit Senf
>Assignee: Stefan Bodewig
> Fix For: 1.4
>
> Attachments: test-7zip.zip, test-windows.zip, test-winzip.zip,
> testzap-winzip.zip
>
>
> There is a problem when handling a WinZip-created zip with Umlauts in
> directories.
> I'm accessing a zip file created with WinZip containing a directory with an
> umlaut ("ä") with ArchiveInputStream. When creating the zip file the
> unicode-flag of winzip had been active.
> The following problem occurs when accessing the entries of the zip:
> the ArchiveEntry for a directory containing an umlaut is not marked as a
> directory and the file names for the directory and all files contained in
> that directory contain backslashes instead of slashes (i.e. completely
> different to all other files in directories with no umlaut in their path).
> There is no difference when letting the ArchiveStreamFactory decide which
> ArchiveInputStream to create or when using the ZipArchiveInputStream
> constructor with the correct encoding (I've tried different encodings CP437,
> CP850, ISO-8859-15, but still the problem persisted).
> This problem does not occur when using the very same zip file but compressed
> by 7zip or the built-in Windows 7 zip functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-176) ArchiveInputStream#getNextEntry(): Problems with WinZip directories with Umlauts
[
https://issues.apache.org/jira/browse/COMPRESS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217122#comment-13217122
]
Stefan Bodewig commented on COMPRESS-176:
-
Whether we need forward slashes in Unicode extra fields can only be answered by
somebody using WinZIP. The best would be creating a test archive with a
directory that contains a character in its name that is not part of CP437 - and
to be safe not part of the platform's default encoding either.
> ArchiveInputStream#getNextEntry(): Problems with WinZip directories with
> Umlauts
>
>
> Key: COMPRESS-176
> URL: https://issues.apache.org/jira/browse/COMPRESS-176
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
> Environment: Windows 7
>Reporter: Wurstbrot mit Senf
>Assignee: Stefan Bodewig
> Fix For: 1.4
>
> Attachments: test-7zip.zip, test-windows.zip, test-winzip.zip,
> testzap-winzip.zip
>
>
> There is a problem when handling a WinZip-created zip with Umlauts in
> directories.
> I'm accessing a zip file created with WinZip containing a directory with an
> umlaut ("ä") with ArchiveInputStream. When creating the zip file the
> unicode-flag of winzip had been active.
> The following problem occurs when accessing the entries of the zip:
> the ArchiveEntry for a directory containing an umlaut is not marked as a
> directory and the file names for the directory and all files contained in
> that directory contain backslashes instead of slashes (i.e. completely
> different to all other files in directories with no umlaut in their path).
> There is no difference when letting the ArchiveStreamFactory decide which
> ArchiveInputStream to create or when using the ZipArchiveInputStream
> constructor with the correct encoding (I've tried different encodings CP437,
> CP850, ISO-8859-15, but still the problem persisted).
> This problem does not occur when using the very same zip file but compressed
> by 7zip or the built-in Windows 7 zip functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
