[jira] [Created] (VFS-457) Update test dependencies
Joerg Schaible created VFS-457: -- Summary: Update test dependencies Key: VFS-457 URL: https://issues.apache.org/jira/browse/VFS-457 Project: Commons VFS Issue Type: Task Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Priority: Trivial Fix For: 2.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-457) Update test dependencies
[ https://issues.apache.org/jira/browse/VFS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated VFS-457: --- Description: Update test dependencies. I'd like to keep this issue open until we release vfs 2.1, because I don't see any value in individual entries in the change log for this internal task. Update test dependencies Key: VFS-457 URL: https://issues.apache.org/jira/browse/VFS-457 Project: Commons VFS Issue Type: Task Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Priority: Trivial Fix For: 2.1 Update test dependencies. I'd like to keep this issue open until we release vfs 2.1, because I don't see any value in individual entries in the change log for this internal task. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-457) Update test dependencies
[ https://issues.apache.org/jira/browse/VFS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582032#comment-13582032 ] Joerg Schaible commented on VFS-457: $ svn ci -m Update sshd-core to version 0.8.0 from version 0.7.0. Update mina-core from version 2.0.4 to version 2.0.7. Sendingpom.xml Transmitting file data . Committed revision 1448036. Update test dependencies Key: VFS-457 URL: https://issues.apache.org/jira/browse/VFS-457 Project: Commons VFS Issue Type: Task Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Priority: Trivial Fix For: 2.1 Update test dependencies. I'd like to keep this issue open until we release vfs 2.1, because I don't see any value in individual entries in the change log for this internal task. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOGGING-143) [patch] Update depdency on avalon-framework
[ https://issues.apache.org/jira/browse/LOGGING-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated LOGGING-143: Fix Version/s: 2.0 [patch] Update depdency on avalon-framework --- Key: LOGGING-143 URL: https://issues.apache.org/jira/browse/LOGGING-143 Project: Commons Logging Issue Type: Improvement Affects Versions: 1.1.1 Reporter: Stanislav Ochotnicky Priority: Minor Labels: build, patch Fix For: 2.0 Attachments: commons-logging-avalon-update.patch Commons logging currently uses avalon-framework 4.1.3 while 4.3 exists and provides a nice split between api and implementation. Attached is a patch updating dependency to new version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOGGING-95) [logging] extended API: getChildLogger(String)
[ https://issues.apache.org/jira/browse/LOGGING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated LOGGING-95: --- Fix Version/s: 2.0 [logging] extended API: getChildLogger(String) -- Key: LOGGING-95 URL: https://issues.apache.org/jira/browse/LOGGING-95 Project: Commons Logging Issue Type: Improvement Environment: Operating System: other Platform: Other Reporter: Jörg Hohwiller Priority: Minor Fix For: 2.0 Attachments: ASF.LICENSE.NOT.GRANTED--getChildLogger.diff, ASF.LICENSE.NOT.GRANTED--Logger.java This is a feature request for the commons-logging API already discussed on the mailing list. The idea is to have an extended interface rather than Log that adds additional methods (getChildLogger and getName) that have already been requested for a long while. The suggested approach does not break compatibility of JCL. The existing Log interface is not touched and shall esp. not be deprecated. The new interface may only be used as needed but aims to prevent having even more additional logging APIs in future. The suggestion is to change the implementation in a way that all classes that implement Log shall implement Logger and fullfill the contract of the additional methods. In my request I still leave it open what happens to LogFactory but my suggestion is to leave it untouched (except for javadoc updates). Further I recomment to add an abstract class to the impl package that implements the Logger interface but does not implement any methods. The Logger interface may then recommend in its javadoc to extend the abstract class rather than directly implementing the interface. This would allow to have less trouble if -however- in future an additional feature request for the Logger API arises. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOGGING-133) Allow subclassing of Jdk14Logger
[ https://issues.apache.org/jira/browse/LOGGING-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved LOGGING-133. - Resolution: Fixed Fix Version/s: 1.1.2 Changed in r1448053. Allow subclassing of Jdk14Logger Key: LOGGING-133 URL: https://issues.apache.org/jira/browse/LOGGING-133 Project: Commons Logging Issue Type: Improvement Affects Versions: 1.1.1 Environment: All Reporter: Shevek Priority: Minor Fix For: 1.1.2 Original Estimate: 1h Remaining Estimate: 1h Hi, It would be nice if private void log( Level level, String msg, Throwable ex ) in Jdk14Logger was protected rather than private, allowing one to use that as a base class for other arbitrary loggers based on Jdk14. S. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOGGING-132) Jdk14Logger wrapper does not respect logger name
[
https://issues.apache.org/jira/browse/LOGGING-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved LOGGING-132.
-
Resolution: Fixed
Fix Version/s: 1.1.2
Applied change in r1448063 for the Jdk14Logger.
Jdk14Logger wrapper does not respect logger name
Key: LOGGING-132
URL: https://issues.apache.org/jira/browse/LOGGING-132
Project: Commons Logging
Issue Type: Bug
Affects Versions: Nightly Builds, 1.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.1.0,
1.1.1, 1.1.2
Reporter: Nathan Niesen
Priority: Minor
Fix For: 1.1.2
The JDK14 wrapper implementation logs using the callers class name instead of
the configured logger name. This prevents the ability to use named loggers
for applications and subsystems. Also, the log message name does not match
the JDK logger name so user don't know what name to use to configure the
logger. It is also problematic for obfuscated code and private parts of an
application or library.
Example:
I have a class named com.myco.product.subsysa.ClassX.InnerClassY and I create
logger LogFactory.getLog(SubSystemA).
With the other log wrappers, if I log a message I always get something like:
Oct 21, 2009 5:03:26 PM
[INFO] SubSystemA start - My log message
With the JDK log wrapper, I get something like:
Oct 21, 2009 5:03:26 PM com.myco.product.subsysa.ClassX$InnerClassY start
INFO: My log message
Or worse yet with obfuscated code and the JDK log wrapper, I get something
like:
Oct 21, 2009 5:03:26 PM
com.myco.product.subsysa.ClassX$_oOOO.o0
0
0
INFO: My log message
The fix:
In the calls to logger.logp(...), replace cname with this.name. Loggers
created with the class name will still get the class name.
{code}
private void log( Level level, String msg, Throwable ex ) {
Logger logger = getLogger();
if (logger.isLoggable(level)) {
// Hack (?) to get the stack trace.
Throwable dummyException=new Throwable();
StackTraceElement locations[]=dummyException.getStackTrace();
// Caller will be the third element
String cname=unknown;
String method=unknown;
if( locations!=null locations.length 2 ) {
StackTraceElement caller=locations[2];
cname=caller.getClassName();
method=caller.getMethodName();
}
if( ex==null ) {
logger.logp( level, cname, method, msg );
} else {
logger.logp( level, cname, method, msg, ex );
}
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-503) AuthenticatingSMTPClient does not support non-default encoding
Ofer Regev created NET-503: -- Summary: AuthenticatingSMTPClient does not support non-default encoding Key: NET-503 URL: https://issues.apache.org/jira/browse/NET-503 Project: Commons Net Issue Type: Bug Components: SMTP Affects Versions: 3.2 Reporter: Ofer Regev The AuthenticatingSMTPClient and SMTPSClient do not support any encoding aside from the default encoding of ISO-8859-1 defined in SMTP. This is because the encoding field is final and can only be set in the constructor, but there is not constructor in these classes that allows specifying the encoding. There is one in the base SMTPClient class, but not in the super classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-503) AuthenticatingSMTPClient does not support non-default encoding
[ https://issues.apache.org/jira/browse/NET-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-503. -- Resolution: Fixed Fix Version/s: 3.3 URL: http://svn.apache.org/r1448074 Log: NET-503 AuthenticatingSMTPClient does not support non-default encoding Modified: commons/proper/net/trunk/src/changes/changes.xml commons/proper/net/trunk/src/main/java/org/apache/commons/net/smtp/AuthenticatingSMTPClient.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/smtp/SMTPSClient.java AuthenticatingSMTPClient does not support non-default encoding -- Key: NET-503 URL: https://issues.apache.org/jira/browse/NET-503 Project: Commons Net Issue Type: Bug Components: SMTP Affects Versions: 3.2 Reporter: Ofer Regev Fix For: 3.3 The AuthenticatingSMTPClient and SMTPSClient do not support any encoding aside from the default encoding of ISO-8859-1 defined in SMTP. This is because the encoding field is final and can only be set in the constructor, but there is not constructor in these classes that allows specifying the encoding. There is one in the base SMTPClient class, but not in the super classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOGGING-138) Show stacktrace for flawed discovery in diagnostic messages
[ https://issues.apache.org/jira/browse/LOGGING-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved LOGGING-138. - Resolution: Fixed Fix Version/s: 1.1.2 Added in r1448097. Used a StringWriter instead of your patch, thanks for the report! Show stacktrace for flawed discovery in diagnostic messages --- Key: LOGGING-138 URL: https://issues.apache.org/jira/browse/LOGGING-138 Project: Commons Logging Issue Type: Improvement Affects Versions: 1.1.0, 1.1.1 Reporter: Luke Lu Fix For: 1.1.2 Attachments: logging-138-trunk-v1.patch It looks like since 1.1, if a custom log appender throws an exception the stack trace is not shown in diagnostic messages, making it harder (than 1.0.4) to find out the root cause of the log initialization problem. Here is a simple patch against the trunk to address the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOGGING-136) API Enhancements: 'String.format(String, Object...)' Functionality Delegate Convenience Methods
[
https://issues.apache.org/jira/browse/LOGGING-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated LOGGING-136:
Fix Version/s: 2.0
API Enhancements: 'String.format(String, Object...)' Functionality Delegate
Convenience Methods
-
Key: LOGGING-136
URL: https://issues.apache.org/jira/browse/LOGGING-136
Project: Commons Logging
Issue Type: Improvement
Affects Versions: 1.1.1
Environment: N/A
Reporter: Daniel Siviter
Labels: api, api-addition
Fix For: 2.0
Attachments: commons-logging-1.1.1.jar,
commons-logging-1.1.1-src.rar, site.rar
Original Estimate: 4h
Remaining Estimate: 4h
Improvements to the API to allow convenience methods for performing
{{String.format(String, Object...)}} and allow access to the internal logging
delegate.
Firstly, to add the {{String#format(String, Object...)}} functionality modify
the methods (note: only {{#trace(...)}} shown):
{{void trace(Object message, Object... args);}}
{{void trace(Object message, Throwable t, Object... args);}}
This would allow compatiblity with previous versions of the API (although I
believe they would still require a re-compile) and help tidy up code.
Secondly, to obtain access to the internal instance of a logger the addition
of a {{#getDeletegate()}} method.
I can supply the code if required.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOGGING-135) Thread-safety improvements
[ https://issues.apache.org/jira/browse/LOGGING-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved LOGGING-135. - Resolution: Fixed Fix Version/s: 1.1.2 Applied the double-checked locking idiom from Josh Bloch (Item 71) for Log4JLogger and LogKitLogger (and changing the logger variable to volatile). This is not working reliably for pre-1.5 java but at least better than before. We could also make the getLogger() methods synchronized, but this may have a negative effect on performance in certain environments. Thread-safety improvements -- Key: LOGGING-135 URL: https://issues.apache.org/jira/browse/LOGGING-135 Project: Commons Logging Issue Type: Bug Reporter: Sebb Fix For: 1.1.2 The LogKitLogger.logger field is not final or volatile so changes are not guaranteed to be published. This includes calls to getLogger(), so two different threads using the same instance can theoretically both create the logger. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-278) procrunsrv windows ++Environment doesn't work for java type
Eric Le Lay created DAEMON-278:
--
Summary: procrunsrv windows ++Environment doesn't work for java
type
Key: DAEMON-278
URL: https://issues.apache.org/jira/browse/DAEMON-278
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.0.13
Environment: Windows XP 32bits
Reporter: Eric Le Lay
When starting a service using the 'java' method, the Environment variables are
not applied to the child process.
looking at serviceStart() in prunsrv.c, the Environment variables are applied
(call to setInprocEnvironment) in the JNI case, but there is missing something
similar for the other case ('java' or 'native').
An easy fix would be to set the environment variables in the wrapper so that
they are inherited by the child process. Maybe you want to set them only in the
child process, but I don't know how...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-279) MSVCR should be ditributed with procrun
Ales Dolecek created DAEMON-279: --- Summary: MSVCR should be ditributed with procrun Key: DAEMON-279 URL: https://issues.apache.org/jira/browse/DAEMON-279 Project: Commons Daemon Issue Type: Improvement Components: Procrun Affects Versions: 1.0.13 Reporter: Ales Dolecek Priority: Minor Windows OS does not by default include MSVCR library. And it is not system library and Miscrosoft does not provide it as standalone instalation. According to Microsoft knowledgebas it is responsibility of the application authors to distribute the DLL with their product: http://support.microsoft.com/kb/326922/en The binary distribution of procrun shall therefore include this file. While many systems already include this somewhere on PATH it is not required. And users often download the DLL from various sites in Internet which leads to security risks. If the omission of the DLL is deliberate then you shall document it along with some trusted source where the users might get the library. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[
https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582250#comment-13582250
]
Wurstbrot mit Senf commented on COMPRESS-219:
-
What you did in the test, works: you wrote the stream to a file, i.e. you
actually copied the internal zip to the file. What causes the problem is the
actuall deflating of the zip within the zip.
That is: creating a new ZipArchiveInputStream from the ZipArchiveInputStream
like in the following snippet (I rewrote your code for NIO.2, sorry for that
:-():
@Test
public static void shouldReadNestedZip() throws Exception {
final Path outDir = Files.createDirectories(Paths.get(dir));
try (ZipArchiveInputStream in = new
ZipArchiveInputStream(Files.newInputStream(Paths.get(COMPRESS-219.zip)));) {
extractZipInputStream(outDir, in);
} finally {
FileUtils.deleteDirectory(outDir.toFile());
}
}
private static void extractZipInputStream(final Path outDir, final
ZipArchiveInputStream in) throws IOException {
ZipArchiveEntry zae = in.getNextZipEntry();
while (zae != null) {
if (zae.getName().endsWith(.zip)) {
final Path outFile =
outDir.resolve(Paths.get(zae.getName().replace(^/, )));
Files.createDirectories(outFile);
final ZipArchiveInputStream zipInZip = new ZipArchiveInputStream(in);
extractZipInputStream(outFile, zipInZip);
}
zae = in.getNextZipEntry();
}
}
ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a
STORED zip file entry from within a zip.
Key: COMPRESS-219
URL: https://issues.apache.org/jira/browse/COMPRESS-219
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.4.1
Environment: Windows (Linux as well)
Reporter: Wurstbrot mit Senf
Priority: Minor
Attachments: compress-219-test.patch, test-linux.zip
When trying to read out a ZIP file, that has been stored (Method STORE, not
DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the
ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing
the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line
362) because the toRead is not decreased by the buf.offsetInBuffer.
I will add the zip in question as attachment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[
https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582250#comment-13582250
]
Wurstbrot mit Senf edited comment on COMPRESS-219 at 2/20/13 3:43 PM:
--
What you did in the test, works: you wrote the stream to a file, i.e. you
actually copied the internal zip to the file. What causes the problem is the
actuall deflating of the zip within the zip.
That is: creating a new ZipArchiveInputStream from the ZipArchiveInputStream
like in the following snippet (I rewrote your code for NIO.2, sorry for that
:-() and attached it to the issue.
was (Author: wurstbrot):
What you did in the test, works: you wrote the stream to a file, i.e. you
actually copied the internal zip to the file. What causes the problem is the
actuall deflating of the zip within the zip.
That is: creating a new ZipArchiveInputStream from the ZipArchiveInputStream
like in the following snippet (I rewrote your code for NIO.2, sorry for that
:-():
@Test
public static void shouldReadNestedZip() throws Exception {
final Path outDir = Files.createDirectories(Paths.get(dir));
try (ZipArchiveInputStream in = new
ZipArchiveInputStream(Files.newInputStream(Paths.get(COMPRESS-219.zip)));) {
extractZipInputStream(outDir, in);
} finally {
FileUtils.deleteDirectory(outDir.toFile());
}
}
private static void extractZipInputStream(final Path outDir, final
ZipArchiveInputStream in) throws IOException {
ZipArchiveEntry zae = in.getNextZipEntry();
while (zae != null) {
if (zae.getName().endsWith(.zip)) {
final Path outFile =
outDir.resolve(Paths.get(zae.getName().replace(^/, )));
Files.createDirectories(outFile);
final ZipArchiveInputStream zipInZip = new ZipArchiveInputStream(in);
extractZipInputStream(outFile, zipInZip);
}
zae = in.getNextZipEntry();
}
}
ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a
STORED zip file entry from within a zip.
Key: COMPRESS-219
URL: https://issues.apache.org/jira/browse/COMPRESS-219
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.4.1
Environment: Windows (Linux as well)
Reporter: Wurstbrot mit Senf
Priority: Minor
Attachments: compress-219-test.patch, test-linux.zip
When trying to read out a ZIP file, that has been stored (Method STORE, not
DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the
ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing
the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line
362) because the toRead is not decreased by the buf.offsetInBuffer.
I will add the zip in question as attachment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[ https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wurstbrot mit Senf updated COMPRESS-219: Attachment: ZipArchiveInputStreamTest.java Modified test (NIO.2) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip. Key: COMPRESS-219 URL: https://issues.apache.org/jira/browse/COMPRESS-219 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.4.1 Environment: Windows (Linux as well) Reporter: Wurstbrot mit Senf Priority: Minor Attachments: compress-219-test.patch, test-linux.zip, ZipArchiveInputStreamTest.java When trying to read out a ZIP file, that has been stored (Method STORE, not DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line 362) because the toRead is not decreased by the buf.offsetInBuffer. I will add the zip in question as attachment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[ https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582250#comment-13582250 ] Wurstbrot mit Senf edited comment on COMPRESS-219 at 2/20/13 3:59 PM: -- What you did in the test, works: you wrote the stream to a file, i.e. you actually copied the internal zip to the file. What causes the problem is the actual deflating of the zip within the zip. That is: creating a new ZipArchiveInputStream from the ZipArchiveInputStream like in the following snippet (I rewrote your code a bit for NIO.2, sorry for that :-() so it reproduces the error and attached it to the issue. was (Author: wurstbrot): What you did in the test, works: you wrote the stream to a file, i.e. you actually copied the internal zip to the file. What causes the problem is the actuall deflating of the zip within the zip. That is: creating a new ZipArchiveInputStream from the ZipArchiveInputStream like in the following snippet (I rewrote your code for NIO.2, sorry for that :-() and attached it to the issue. ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip. Key: COMPRESS-219 URL: https://issues.apache.org/jira/browse/COMPRESS-219 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.4.1 Environment: Windows (Linux as well) Reporter: Wurstbrot mit Senf Priority: Minor Attachments: compress-219-test.patch, test-linux.zip, ZipArchiveInputStreamTest.java When trying to read out a ZIP file, that has been stored (Method STORE, not DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line 362) because the toRead is not decreased by the buf.offsetInBuffer. I will add the zip in question as attachment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[ https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582252#comment-13582252 ] Wurstbrot mit Senf edited comment on COMPRESS-219 at 2/20/13 4:01 PM: -- Modified test (NIO.2) Oh, and forget about the static methods. Shouldn't be static :-) was (Author: wurstbrot): Modified test (NIO.2) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip. Key: COMPRESS-219 URL: https://issues.apache.org/jira/browse/COMPRESS-219 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.4.1 Environment: Windows (Linux as well) Reporter: Wurstbrot mit Senf Priority: Minor Attachments: compress-219-test.patch, test-linux.zip, ZipArchiveInputStreamTest.java When trying to read out a ZIP file, that has been stored (Method STORE, not DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line 362) because the toRead is not decreased by the buf.offsetInBuffer. I will add the zip in question as attachment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-458) FTPS implementation incomplete and buggy compared to FTP
Joerg Schaible created VFS-458: -- Summary: FTPS implementation incomplete and buggy compared to FTP Key: VFS-458 URL: https://issues.apache.org/jira/browse/VFS-458 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Fix For: 2.1 The FTPS provider started as copy of the FTP implementation. Part of the code between the two providers were shared, other parts evolved individually. Therefore some options of the FTP provider were not present (although the shared part tried to use them) and some bug fixed were not automatically inherited. The FTPS implementation should inherit as much as possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-458) FTPS implementation incomplete and buggy compared to FTP
[ https://issues.apache.org/jira/browse/VFS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved VFS-458. Resolution: Fixed $ svn ci -m FTPS provider missed functionality and bug fixes already available for the FTP provider. Sending core/src/main/java/org/apache/commons/vfs2/provider/ftp/FTPClientWrapper.java Sending core/src/main/java/org/apache/commons/vfs2/provider/ftp/FtpClientFactory.java Sending core/src/main/java/org/apache/commons/vfs2/provider/ftp/FtpFileSystemConfigBuilder.java Sending core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientFactory.java Sending core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientWrapper.java Sending core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsFileSystemConfigBuilder.java Adding core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/AbstractFtpsProviderTestCase.java Adding core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/FtpsProviderExplicitTestCase.java Adding core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/FtpsProviderImplicitTestCase_Disabled.java Sending core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/FtpsProviderPROTTestCase_Disabled.java Deleting core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/FtpsProviderTestCase_Disabled.java Sending core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/MultipleConnectionTestCase.java Sendingsrc/changes/changes.xml Transmitting file data Committed revision 1448341. FTPS implementation incomplete and buggy compared to FTP Key: VFS-458 URL: https://issues.apache.org/jira/browse/VFS-458 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Fix For: 2.1 The FTPS provider started as copy of the FTP implementation. Part of the code between the two providers were shared, other parts evolved individually. Therefore some options of the FTP provider were not present (although the shared part tried to use them) and some bug fixed were not automatically inherited. The FTPS implementation should inherit as much as possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[ https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582421#comment-13582421 ] Stefan Bodewig commented on COMPRESS-219: - I can't use NIO2 in a Java5 codebase, but I managed to reproduce the bug now :-) Can I include your test zip in compress' source tree or does it contain sensitive information? ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip. Key: COMPRESS-219 URL: https://issues.apache.org/jira/browse/COMPRESS-219 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.4.1 Environment: Windows (Linux as well) Reporter: Wurstbrot mit Senf Priority: Minor Attachments: compress-219-test.patch, test-linux.zip, ZipArchiveInputStreamTest.java When trying to read out a ZIP file, that has been stored (Method STORE, not DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line 362) because the toRead is not decreased by the buf.offsetInBuffer. I will add the zip in question as attachment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-166) Base64 could be faster
[
https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582444#comment-13582444
]
Thomas Neidhart commented on CODEC-166:
---
Hi Julius,
the only change I did was as described on the mailinglist: use (part) of the
result in some kind of calculation to prevent it from being optimized away:
{noformat}
long d = 0;
long start = System.currentTimeMillis();
for (int i = 0; i FACTOR * REPS; i++) {
encoded = Base64.encodeBase64(data);
d += encoded[i % encoded.length];
}
printEncodeStat(start, data, d);
{noformat}
The value d is then passed to the print method to be output. This of course for
all occurrences of this pattern.
Base64 could be faster
--
Key: CODEC-166
URL: https://issues.apache.org/jira/browse/CODEC-166
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.7
Reporter: Julius Davies
Assignee: Julius Davies
Fix For: 1.8
Attachments: base64bench.zip, CODEC-166.patch, CODEC-166_speed.patch
Our Base64 consistently performs 3 times slower compared to MiGBase64 and
iHarder in the byte[] and String encode() methods.
We are pretty good on decode(), though a little slower (approx. 33% slower)
than MiGBase64.
We always win in the Streaming methods (MiGBase64 doesn't do streaming).
Yay! :-) :-) :-)
I put together a benchmark. Here's a typical run:
{noformat}
LARGE DATA new byte[12345]
iHarder...
encode 486.0 MB/sdecode 158.0 MB/s
encode 491.0 MB/sdecode 148.0 MB/s
MiGBase64...
encode 499.0 MB/sdecode 222.0 MB/s
encode 493.0 MB/sdecode 226.0 MB/s
Apache Commons Codec...
encode 142.0 MB/sdecode 146.0 MB/s
encode 138.0 MB/sdecode 150.0 MB/s
{noformat}
I believe the main approach we can consider to improve performance is to
avoid array copies at all costs. MiGBase64 even counts the number of valid
Base64 characters ahead of time on decode() to precalculate the result's size
and avoid any array copying!
I suspect this will mean writing out separate execution paths for the String
and byte[] methods, and keeping them out of the streaming logic, since the
streaming logic is founded on array copy.
Unfortunately this means we will diminish internal reuse of the streaming
implementation, but I think it's the only way to improve performance, if we
want to.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[ https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582447#comment-13582447 ] Stefan Bodewig commented on COMPRESS-219: - fixed with svn revision 1448357 - Thanks! I'll leave this ticket open until I know whether I can enable the test. ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip. Key: COMPRESS-219 URL: https://issues.apache.org/jira/browse/COMPRESS-219 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.4.1 Environment: Windows (Linux as well) Reporter: Wurstbrot mit Senf Priority: Minor Attachments: compress-219-test.patch, test-linux.zip, ZipArchiveInputStreamTest.java When trying to read out a ZIP file, that has been stored (Method STORE, not DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line 362) because the toRead is not decreased by the buf.offsetInBuffer. I will add the zip in question as attachment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[ https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-219: Fix Version/s: 1.5 ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip. Key: COMPRESS-219 URL: https://issues.apache.org/jira/browse/COMPRESS-219 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.4.1 Environment: Windows (Linux as well) Reporter: Wurstbrot mit Senf Priority: Minor Fix For: 1.5 Attachments: compress-219-test.patch, test-linux.zip, ZipArchiveInputStreamTest.java When trying to read out a ZIP file, that has been stored (Method STORE, not DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line 362) because the toRead is not decreased by the buf.offsetInBuffer. I will add the zip in question as attachment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-214) better support for unix symlinks
[
https://issues.apache.org/jira/browse/COMPRESS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-214.
-
Resolution: Fixed
better support for unix symlinks
Key: COMPRESS-214
URL: https://issues.apache.org/jira/browse/COMPRESS-214
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Reporter: Julius Davies
Assignee: Julius Davies
Priority: Minor
Fix For: 1.5
Attachments: COMPRESS-214.patch, COMPRESS-214_unix_symlinks.zip
The current API is a little awkward when dealing with symlinks (e.g., those
created using Info-Zip's zip -y).
I propose the following three methods for ZipArchiveEntry:
{noformat}
public boolean isUnixSymlink()
public String getUnixSymlink(ZipFile zf)
public String getUnixSymlink(ZipFile zf, String pathCharset)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-754) embedded objects are not toString-ed like top-level objects
[
https://issues.apache.org/jira/browse/LANG-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated LANG-754:
-
Attachment: LANG-754.patch
The attached patch fixes ClassUtils.getShortName(String) to only do the
reverseAbbreviation lookup if the supplied className contains an array
definition.
Otherwise the abbreviated class names for primitive types are not used imho.
embedded objects are not toString-ed like top-level objects
---
Key: LANG-754
URL: https://issues.apache.org/jira/browse/LANG-754
Project: Commons Lang
Issue Type: Bug
Components: lang.builder.*
Affects Versions: 2.5, 3.0.1
Environment: Linux Ubuntu
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
Reporter: Dominique De Vito
Priority: Minor
Attachments: LANG-754.patch
Original Estimate: 24h
Remaining Estimate: 24h
I have a simple class 'A' defined as follows:
==
public class A {
int p1;
String p2;
B b;
}
==
While I execute the following instructions:
ToStringBuilder builder = new ReflectionToStringBuilder(a);
System.out.println(builder.toString());
The output is:
A@3ea981ca[p1=0,p2=null,b=B@1ee7b241]
that's normal, without recursion
So, I defined my own style, for recursive toString-ing display:
==
class MyStyle extends ToStringStyle {
private final static ToStringStyle instance = new MyStyle();
public MyStyle() {
setArrayContentDetail(true);
setUseShortClassName(true);
setUseClassName(true);
setUseIdentityHashCode(true);
setFieldSeparator(, );
}
public static ToStringStyle getInstance() {
return instance;
};
@Override
public void appendDetail(final StringBuffer buffer, final String fieldName,
final Object value) {
if (!value.getClass().getName().startsWith(java)) {
buffer.append(ReflectionToStringBuilder.toString(value, instance));
} else {
super.appendDetail(buffer, fieldName, value);
}
}
@Override
public void appendDetail(final StringBuffer buffer, final String fieldName,
final Collection value) {
appendDetail(buffer, fieldName, value.toArray());
}
}
==
When I use my custom MyStyle:
String s = ReflectionToStringBuilder.toString(a, MyStyle.getInstance());
System.out.println(s);
The output is:
A@3ea981ca[p1=0, p2=null, b=byte@1ee7b241[p4=234]]
So, the name of the class 'B' is not displayed.
I expected something like: b=B@1ee7b241[p4=234]
Instead, the name of the class 'B' is replaced with 'byte'.
I don't know why.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-621) ReflectionToStringBuilder.toString does not debug 3rd party object fields within 3rd party object
[
https://issues.apache.org/jira/browse/LANG-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated LANG-621:
-
Attachment: LANG-621.patch
First version of a patch to provide a RecursiveToStringStyle which does
recursively formats an object.
Similar to the ReflectionToStringBuilder, it has an accept(Class) method which
allows for additional filtering for this recursive behavior. By default, only
the primitive wrappers and java.lang.String are formatted in a shallow way. All
the rest is formatted in a deep way.
It is provided as a separate source file (not as inner class of ToStringStyle)
as this class also serves as an howto/example for users as requested by the
original poster.
ReflectionToStringBuilder.toString does not debug 3rd party object fields
within 3rd party object
-
Key: LANG-621
URL: https://issues.apache.org/jira/browse/LANG-621
Project: Commons Lang
Issue Type: Improvement
Components: lang.builder.*
Affects Versions: 2.5
Reporter: Philip Hodges
Priority: Minor
Fix For: 3.x
Attachments: LANG-621.patch
{code:title=Reflect.java|borderStyle=solid}
import org.apache.commons.lang.builder.ReflectionToStringBuilder;
public class Reflect {
public static void main(String[] args) {
// You can also use the builder to debug 3rd party objects:
// System.out.println(An object: +
ReflectionToStringBuilder.toString(anObject));
// expected:
Reflect$Compound@a83b8a[instanceInt=67890,fixture=Reflect$Simple@1d1acd3[instanceInt=12345]]
// actual:
Reflect$Compound@a83b8a[instanceInt=67890,fixture=Reflect$Simple@1d1acd3]
System.out.println(ReflectionToStringBuilder.toString(new
Compound()));
}
static class Compound {
private int instanceInt = 67890;
private Simple fixture = new Simple();
}
static class Simple {
private int instanceInt = 12345;
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-526) Support loading from and saving to DOM nodes
[ https://issues.apache.org/jira/browse/CONFIGURATION-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582501#comment-13582501 ] Oliver Heger commented on CONFIGURATION-526: Thanks for the patch. I will need a couple of days to review it and then come back to you. Support loading from and saving to DOM nodes Key: CONFIGURATION-526 URL: https://issues.apache.org/jira/browse/CONFIGURATION-526 Project: Commons Configuration Issue Type: New Feature Reporter: Oliver Kopp Priority: Minor Labels: patch Attachments: add-DOM-load-and-save-to-XMLPropertiesConfiguration.txt I'm loading a complex XML document, where properties are are nested using the Java 1.5 properties XML format. This is in contrast of the issue CONFIGURATION-209, where an XML-based format has been introduced. I require following signatures: void load(Element element) throws ConfigurationException void save(Document document, Node parent) Please find attached a patch implementing this requirement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-366) Provide feedback about the progress of time consuming tasks
Cornelius Lilge created IO-366:
--
Summary: Provide feedback about the progress of time consuming
tasks
Key: IO-366
URL: https://issues.apache.org/jira/browse/IO-366
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.5
Reporter: Cornelius Lilge
Priority: Minor
While it is easy to copy directory structures with commons-io, it is afaik
impossible to provide user feedback about the copy progress - same applies for
move.
I would suggest providing alternative interfaces of all public {{copy*}} and
{{move*}} methods that include a ProgressListener. The ProgressListener would
be a simple Interface like this:
public interface ProgressListener {
void onProgress(long currentBytes, long totalBytes);
}
So for example:
{{copyToDirectory(final File src, final File destDir)}}
would get its alter ego:
{{copyToDirectory(final File src, final File destDir, final ProgressListener
progressListener)}}
To avoid implementation overhead, I suggest that all currently existing
{{copy}} {{move}} methods would then call the new methods with a {{null}}
parameter for the Progress Listener.
I did a quick dirty proof on concept which you can view here:
bq. https://github.com/sne11ius/commons-io/
Please let me know what you think about it. If you like the idea, I will
provide a cleaner implementation with comments tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-367) Add convenience methods for copyToDirectory and moveToDirectory
Cornelius Lilge created IO-367:
--
Summary: Add convenience methods for copyToDirectory and
moveToDirectory
Key: IO-367
URL: https://issues.apache.org/jira/browse/IO-367
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.5
Reporter: Cornelius Lilge
Priority: Minor
I suggest adding the following convenience methods:
First:
{{void copyToDirectory(final File src, final File destDir)}} which will simply
select either {{copyFileToDirectory}}
or
{{copyDirectoryToDirectory}}.
Second:
{{void copyToDirectory(final CollectionFile src, final File destDir)}} which
will simply use {{copyToDirectory}} for each file object.
Implementation of these methods should be straight foward as they would only
recombine methods that are already existing and tested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-367) Add convenience methods for copyToDirectory
[
https://issues.apache.org/jira/browse/IO-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cornelius Lilge updated IO-367:
---
Summary: Add convenience methods for copyToDirectory (was: Add convenience
methods for copyToDirectory and moveToDirectory)
Add convenience methods for copyToDirectory
---
Key: IO-367
URL: https://issues.apache.org/jira/browse/IO-367
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.5
Reporter: Cornelius Lilge
Priority: Minor
Labels: features
Original Estimate: 4h
Remaining Estimate: 4h
I suggest adding the following convenience methods:
First:
{{void copyToDirectory(final File src, final File destDir)}} which will
simply select either {{copyFileToDirectory}}
or
{{copyDirectoryToDirectory}}.
Second:
{{void copyToDirectory(final CollectionFile src, final File destDir)}}
which will simply use {{copyToDirectory}} for each file object.
Implementation of these methods should be straight foward as they would only
recombine methods that are already existing and tested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-367) Add convenience methods for copyToDirectory
[
https://issues.apache.org/jira/browse/IO-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cornelius Lilge updated IO-367:
---
Description:
I suggest adding the following convenience methods:
First:
{{void copyToDirectory(final File src, final File destDir)}} which will simply
select either
{{copyFileToDirectory}}
or
{{copyDirectoryToDirectory}}.
Second:
{{void copyToDirectory(final CollectionFile src, final File destDir)}} which
will simply use {{copyToDirectory}} for each file object.
Implementation of these methods should be straight foward as they would only
recombine methods that are already existing and tested.
was:
I suggest adding the following convenience methods:
First:
{{void copyToDirectory(final File src, final File destDir)}} which will simply
select either {{copyFileToDirectory}}
or
{{copyDirectoryToDirectory}}.
Second:
{{void copyToDirectory(final CollectionFile src, final File destDir)}} which
will simply use {{copyToDirectory}} for each file object.
Implementation of these methods should be straight foward as they would only
recombine methods that are already existing and tested.
Add convenience methods for copyToDirectory
---
Key: IO-367
URL: https://issues.apache.org/jira/browse/IO-367
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.5
Reporter: Cornelius Lilge
Priority: Minor
Labels: features
Original Estimate: 4h
Remaining Estimate: 4h
I suggest adding the following convenience methods:
First:
{{void copyToDirectory(final File src, final File destDir)}} which will
simply select either
{{copyFileToDirectory}}
or
{{copyDirectoryToDirectory}}.
Second:
{{void copyToDirectory(final CollectionFile src, final File destDir)}}
which will simply use {{copyToDirectory}} for each file object.
Implementation of these methods should be straight foward as they would only
recombine methods that are already existing and tested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-366) Provide feedback about the progress of time consuming tasks
[
https://issues.apache.org/jira/browse/IO-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cornelius Lilge updated IO-366:
---
Remaining Estimate: 48h
Original Estimate: 48h
Provide feedback about the progress of time consuming tasks
---
Key: IO-366
URL: https://issues.apache.org/jira/browse/IO-366
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.5
Reporter: Cornelius Lilge
Priority: Minor
Labels: features
Original Estimate: 48h
Remaining Estimate: 48h
While it is easy to copy directory structures with commons-io, it is afaik
impossible to provide user feedback about the copy progress - same applies
for move.
I would suggest providing alternative interfaces of all public {{copy*}} and
{{move*}} methods that include a ProgressListener. The ProgressListener
would be a simple Interface like this:
public interface ProgressListener {
void onProgress(long currentBytes, long totalBytes);
}
So for example:
{{copyToDirectory(final File src, final File destDir)}}
would get its alter ego:
{{copyToDirectory(final File src, final File destDir, final ProgressListener
progressListener)}}
To avoid implementation overhead, I suggest that all currently existing
{{copy}} {{move}} methods would then call the new methods with a {{null}}
parameter for the Progress Listener.
I did a quick dirty proof on concept which you can view here:
bq. https://github.com/sne11ius/commons-io/
Please let me know what you think about it. If you like the idea, I will
provide a cleaner implementation with comments tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-369) Compilation error with newer versions of Jackrabbit
[
https://issues.apache.org/jira/browse/VFS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582627#comment-13582627
]
Jean-Marc Borer commented on VFS-369:
-
That's normal. The unit tests no longer run properly with version 2.5.3 of
Jackrabbit. See my previous comments higher above. I am still struggling with
the issue. Moreover, on my Mac almost all HDFS unit tests fail, but not on my
PC at work...
Compilation error with newer versions of Jackrabbit
---
Key: VFS-369
URL: https://issues.apache.org/jira/browse/VFS-369
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Cedric Nanni
Attachments: pom.xml.patch, vfs-369-JR-2.5.3.diff, VFS-369.patch
When I try to compile VFS on my computer I've got compilation errors due
maybe because I use a more recent version of jackrabbit. I patched the code
and now it compiles.
{noformat}
diff -rupN
original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
--- original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
2011-08-18 06:57:10.0 +0200
+++ patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
2011-10-24 20:35:41.0 +0200
@@ -50,7 +50,7 @@ public final class ExceptionConverter
{
try
{
-Element error =
davExc.toXml(DomUtil.BUILDER_FACTORY.newDocumentBuilder().newDocument());
+Element error = davExc.toXml(DomUtil.createDocument());
if (DomUtil.matches(error, DavException.XML_ERROR,
DavConstants.NAMESPACE))
{
if (DomUtil.hasChildElement(error, exception, null))
diff -rupN
original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
--- original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
2011-08-18 06:57:10.0 +0200
+++ patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
2011-10-24 20:35:41.0 +0200
@@ -292,19 +292,17 @@ public class WebdavFileObject extends Ht
URLFileName fileName = (URLFileName) getName();
DavPropertySet properties = getProperties(fileName,
PropFindMethod.PROPFIND_ALL_PROP,
new DavPropertyNameSet(), false);
-@SuppressWarnings(unchecked) // iterator() is documented to
return DavProperty instances
-IteratorDavProperty iter = properties.iterator();
+Iterator iter = properties.iterator();
while (iter.hasNext())
{
-DavProperty property = iter.next();
+DavProperty property = (DavProperty)iter.next();
attributes.put(property.getName().toString(),
property.getValue());
}
properties = getPropertyNames(fileName);
-@SuppressWarnings(unchecked) // iterator() is documented to
return DavProperty instances
-IteratorDavProperty iter2 = properties.iterator();
+Iterator iter2 = properties.iterator();
while (iter2.hasNext())
{
-DavProperty property = iter2.next();
+DavProperty property = (DavProperty)iter2.next();
if (!attributes.containsKey(property.getName().getName()))
{
property = getProperty(fileName, property.getName());
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-367) Add convenience methods for copyToDirectory
[
https://issues.apache.org/jira/browse/IO-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cornelius Lilge updated IO-367:
---
Description:
I suggest adding the following convenience methods:
First:
{{void copyToDirectory(final File src, final File destDir)}} which will simply
select either
{{copyFileToDirectory}}
or
{{copyDirectoryToDirectory}}.
Second:
{{void copyToDirectory(final CollectionFile srcs, final File destDir)}} which
will simply use {{copyToDirectory}} for each file object.
Implementation of these methods should be straight foward as they would only
recombine methods that are already existing and tested.
was:
I suggest adding the following convenience methods:
First:
{{void copyToDirectory(final File src, final File destDir)}} which will simply
select either
{{copyFileToDirectory}}
or
{{copyDirectoryToDirectory}}.
Second:
{{void copyToDirectory(final CollectionFile src, final File destDir)}} which
will simply use {{copyToDirectory}} for each file object.
Implementation of these methods should be straight foward as they would only
recombine methods that are already existing and tested.
Add convenience methods for copyToDirectory
---
Key: IO-367
URL: https://issues.apache.org/jira/browse/IO-367
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.5
Reporter: Cornelius Lilge
Priority: Minor
Labels: features
Original Estimate: 4h
Remaining Estimate: 4h
I suggest adding the following convenience methods:
First:
{{void copyToDirectory(final File src, final File destDir)}} which will
simply select either
{{copyFileToDirectory}}
or
{{copyDirectoryToDirectory}}.
Second:
{{void copyToDirectory(final CollectionFile srcs, final File destDir)}}
which will simply use {{copyToDirectory}} for each file object.
Implementation of these methods should be straight foward as they would only
recombine methods that are already existing and tested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-367) Add convenience methods for copyToDirectory
[
https://issues.apache.org/jira/browse/IO-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582808#comment-13582808
]
Gary Gregory commented on IO-367:
-
Patches with unit tests are welcome.
Add convenience methods for copyToDirectory
---
Key: IO-367
URL: https://issues.apache.org/jira/browse/IO-367
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.5
Reporter: Cornelius Lilge
Priority: Minor
Labels: features
Original Estimate: 4h
Remaining Estimate: 4h
I suggest adding the following convenience methods:
First:
{{void copyToDirectory(final File src, final File destDir)}} which will
simply select either
{{copyFileToDirectory}}
or
{{copyDirectoryToDirectory}}.
Second:
{{void copyToDirectory(final CollectionFile srcs, final File destDir)}}
which will simply use {{copyToDirectory}} for each file object.
Implementation of these methods should be straight foward as they would only
recombine methods that are already existing and tested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
