[jira] [Updated] (CODEC-104) Add a function for the classical Unix crypt(3) hash
[ https://issues.apache.org/jira/browse/CODEC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-104: -- Summary: Add a function for the classical Unix crypt(3) hash (was: Please add a function for the classical Unix crypt(3) hash) > Add a function for the classical Unix crypt(3) hash > --- > > Key: CODEC-104 > URL: https://issues.apache.org/jira/browse/CODEC-104 > Project: Commons Codec > Issue Type: New Feature >Reporter: Christian Hammers > Fix For: 1.x > > > The Sun Java APIs lack a function for the classical Unix crypt(3) hash that > was used in e.g. /etc/passwd or Apache htpasswd and is still widely used > dispite the availablitity of better algorithms like MD5 or SHA. > Apart from me cursing Sun for producing monster crypto APIs but missing the > little things that one really needs, there are already several Apache projects > that implemented UnixCrypt for their own: > org.apache.directory.studio.ldapbrowser.core.utils.UnixCrypt > org.apache.fulcrum.crypto.impl.UnixCrypt > and maybe others > bye, > -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-133) Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants.
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-133: -- Summary: Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. (was: Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants) > Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. > --- > > Key: CODEC-133 > URL: https://issues.apache.org/jira/browse/CODEC-133 > Project: Commons Codec > Issue Type: New Feature >Affects Versions: 1.6 >Reporter: Christian Hammers > Labels: MD5, SHA-512, crypt(3), crypto, hash > Attachments: commons-codec-crypt3.diff, > crypt3-with-utexas-licence.diff > > > The Linux libc6 crypt(3) function, which is used to generate e.g. the > password hashes in /etc/shadow, is available in nearly all other programming > languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and > offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt > and several iterations to make rainbow table attacks harder. Thus they are > widely used to store user passwords. > Java, though, has due it's platform independence, no direct access to the > libc functions and still lacks an proper port of the crypt(3) function. > I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES > based crypt(3) method but would also like to see the much stronger algorithms. > There are other bug reports like DIRSTUDIO-738 that demand those crypt > variants for some specific applications so there it would benefit other > Apache projects as well. > Java ports of most of the specific crypt variants are already existing, but > they would have to be cleaned up, properly tested and license checked: > ftp://ftp.arlut.utexas.edu/pub/java_hashes/ > I would be willing to help here by cleaning the source code and writing unit > tests etc. but I'd like to generally know if you are interested and if > there's someone who can do a code review (it's security relevant after all > and I'm no crypto guy) > bye, > -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-210) Wrapper-Mode VFS
[ https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-210: Fix Version/s: (was: 2.0) 2.1 > Wrapper-Mode VFS > > > Key: VFS-210 > URL: https://issues.apache.org/jira/browse/VFS-210 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: Mario Ivankovits >Assignee: Mario Ivankovits > Fix For: 2.1 > > > VFS should behave more like a wrapper to the underlaying library than a full > blown filesystem. > This should solve the following problems: > * access of hidden files/directories > * access to special folders > * speed up FTP access -- 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] (VFS-228) Ant regression with ClassNotFoundException for DefaultLocalFileProvider
[ https://issues.apache.org/jira/browse/VFS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-228: Fix Version/s: (was: 2.0) 2.1 > Ant regression with ClassNotFoundException for DefaultLocalFileProvider > --- > > Key: VFS-228 > URL: https://issues.apache.org/jira/browse/VFS-228 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: java version "1.6.0_0" > IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) > OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) > Apache Ant version 1.7.1 compiled on October 3 2008 >Reporter: Per Hermansson >Priority: Critical > Fix For: 2.1 > > Attachments: patch, test.xml, vfs-task.diff > > > The latest version from trunk fails to work with Apache Ant resulting in this > error: > Could not load VFS configuration from > "jar:file:/media/Fort/per/program/backup/lib/commons-vfs-2.0-SNAPSHOT.jar!/org/apache/commons/vfs/impl/providers.xml". > which was caused by > java.lang.ClassNotFoundException: > org.apache.commons.vfs.provider.local.DefaultLocalFileProvider > The cause seems to be a class loader issued introduced in rev 537717. > Reverting that change: > cd core > svn diff -c r537717 > src/main/java/org/apache/commons/vfs/impl/StandardFileSystemManager.java | > patch -R > mvn clean install > [copy commons-vfs-2.0-SNAPSHOT to my test's lib dir] > ant -f test.xml test > Makes my example ant file work again (worked with the 1.0 release). > The 537717 revision was intended to fix > VFS-136: Don't force-set the classloader - Thanks to Adam Heath for the patch > So it might be a bit controversial to reverse that change. > Attaching patch fixing the issue and my example ant file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-236) SmbFileObject throws NPE when used without authentication
[
https://issues.apache.org/jira/browse/VFS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-236:
Fix Version/s: (was: 2.0)
2.1
> SmbFileObject throws NPE when used without authentication
> -
>
> Key: VFS-236
> URL: https://issues.apache.org/jira/browse/VFS-236
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds
>Reporter: Matt Casters
> Fix For: 2.1
>
>
> If you have a shared folder without authentication, SmbFileObject throws an
> NPE in method createSmbFile().
> Here is what I changed to get it to run:
> private SmbFile createSmbFile(FileName fileName) throws
> MalformedURLException, SmbException, FileSystemException
> {
> SmbFileName smbFileName = (SmbFileName) fileName;
> String path = smbFileName.getUriWithoutAuth();
> UserAuthenticationData authData = null;
> SmbFile file;
> NtlmPasswordAuthentication auth;
> try
> {
> authData =
> UserAuthenticatorUtils.authenticate(getFileSystem().getFileSystemOptions(),
> SmbFileProvider.AUTHENTICATOR_TYPES);
> if (authData!=null) {
> auth = new NtlmPasswordAuthentication(
> UserAuthenticatorUtils.toString(
> UserAuthenticatorUtils.getData(
> authData,
>
> UserAuthenticationData.DOMAIN,
>
> UserAuthenticatorUtils.toChar(smbFileName.getDomain(,
> UserAuthenticatorUtils.toString(
> UserAuthenticatorUtils.getData(
> authData,
>
> UserAuthenticationData.USERNAME,
>
> UserAuthenticatorUtils.toChar(smbFileName.getUserName(,
> UserAuthenticatorUtils.toString(
> UserAuthenticatorUtils.getData(
> authData,
>
> UserAuthenticationData.PASSWORD,
>
> UserAuthenticatorUtils.toChar(smbFileName.getPassword();
> file = new SmbFile(path, auth);
> } else {
> auth=null;
> file = new SmbFile(path);
> }
> }
> finally
> {
> UserAuthenticatorUtils.cleanup(authData);
> }
> if (file.isDirectory() && !file.toString().endsWith("/"))
> {
> if (auth!=null) {
> file = new SmbFile(path + "/", auth);
> } else {
> file = new SmbFile(path + "/");
> }
> }
> return file;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-250) URLFileName should always honor trailing slash for collections
[ https://issues.apache.org/jira/browse/VFS-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-250: Fix Version/s: (was: 2.0) 2.1 > URLFileName should always honor trailing slash for collections > -- > > Key: VFS-250 > URL: https://issues.apache.org/jira/browse/VFS-250 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: James William Dumay > Fix For: 2.1 > > Attachments: VFS-urlfilename-should-be-always-uri-style.patch > > > URLFileName should always honor trailing slash for collections. > When using webdav VFS.getUriStyle() should always equal to true as operations > on a collection resource without a trailing slash will result in a 301. This > should be default for the URLFileName. -- 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] (VFS-275) add RandomAccessContent.setLength() method
[ https://issues.apache.org/jira/browse/VFS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-275: Fix Version/s: (was: 2.0) 2.1 > add RandomAccessContent.setLength() method > -- > > Key: VFS-275 > URL: https://issues.apache.org/jira/browse/VFS-275 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Google App Engine >Reporter: Vince Bonfanti > Fix For: 2.1 > > Attachments: VFS-randomaccesscontent-setlength.patch > > > I'm developing a Commons VFS plug-in for Google App Engine > (http://code.google.com/p/gaevfs/), and also using this as a basis for a > pluggable file system for the H2 relational database > (http://www.h2database.com/html/main.html) that will allow H2 to run on > Google App Engine. In order to support H2, I need to support a setLength() > method for my RandomAccessContent implementation. Note that setLength() is > supported by java.io.RandomAccessFile > (http://java.sun.com/javase/6/docs/api/index.html), so adding this method > will bring RandomAccessContent a little closer to RandomAccessFile. -- 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] (VFS-254) Let FileObject and FileContent extend Closeable
[ https://issues.apache.org/jira/browse/VFS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-254: Fix Version/s: (was: 2.0) 2.1 > Let FileObject and FileContent extend Closeable > --- > > Key: VFS-254 > URL: https://issues.apache.org/jira/browse/VFS-254 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.0, 1.1, later, Nightly Builds, 2.0 >Reporter: Marek Zawirski >Priority: Trivial > Fix For: 2.1 > > Attachments: extend_cloneable.patch > > > What about letting FileObject and FileContent extend java.io.Closeable > interface? > Some applications have a generic code for closing such resources (and for > example ignoring and logging exceptions during close), so it may be useful at > application-level. -- 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] (VFS-255) Allow file operations to return a result
[
https://issues.apache.org/jira/browse/VFS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-255:
Fix Version/s: (was: 2.0)
2.1
> Allow file operations to return a result
>
>
> Key: VFS-255
> URL: https://issues.apache.org/jira/browse/VFS-255
> Project: Commons VFS
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Frank van der Kleij
> Fix For: 2.1
>
>
> Currently the file operations can not return any result after being executed.
> A simple interface should allow marking the operations that return something
> without being too strict about what they return.
> I'm working on a command line shell based on VFS that also allows executing
> operations (http://vfs-utils.sourceforge.net/shell). For the moment I found
> nothing better than to check for a method getResult() but it I would prefer
> to just check for the interface.
> The interface could be something like this:
> package org.apache.commons.vfs.operations;
> public interface FileOperationResult {
> public abstract Object getResult();
> }
> For me returning a String would be good enough, but I think returning an
> Object the most appropriate. In the vfs shell I just do a toString() on it.
--
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] (VFS-265) Set user dir as root dir by default for FTP provider
[ https://issues.apache.org/jira/browse/VFS-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-265: Fix Version/s: (was: 2.0) 2.1 > Set user dir as root dir by default for FTP provider > > > Key: VFS-265 > URL: https://issues.apache.org/jira/browse/VFS-265 > Project: Commons VFS > Issue Type: Wish >Affects Versions: 2.0 >Reporter: Scott Bjerstedt >Priority: Minor > Fix For: 2.1 > > Attachments: FTP-userrootdefault.patch > > > Currently the FTP provider try to set "/" as the default directory on login, > and many servers don't support this on login. Would like to have the code in > FtpFileSystemConfigBuilder set the user dir as root by default. -- 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] (VFS-258) Unsafe casting to AbstractFileObject subclasses in doRename()
[ https://issues.apache.org/jira/browse/VFS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-258: Fix Version/s: (was: 2.0) 2.1 > Unsafe casting to AbstractFileObject subclasses in doRename() > - > > Key: VFS-258 > URL: https://issues.apache.org/jira/browse/VFS-258 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Marek Zawirski > Fix For: 2.1 > > Attachments: doRename_use_AbstractFileObject.patch > > > AbstractFileObject#doRename() method is called from > AbstractFileObject#moveTo() when file can be moved within the same file > system. As it concerns file that is subclass AbstractFileObject, target file > is also assumed to be AbstractFileObject type. However, this target file can > be decorated. Undressing with FileObjectUtils.getAbstractFileObject() was not > performed in every places that it should be. Some subclasses do correct > stripping of decorator in doRename() implementations (e.g. FtpFileObject), > some of them not (e.g. RamFileObject) - which may cause ClassCastExceptions. > Patch proposal: pass undressed AbstractFileObject to doRename() instead of > possibly decorated FileObject. -- 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] (VFS-252) SmbFileObject does not support setLastModifiedTime while jcifs supports it, it is critical for a backup application that checks the last modified time stamp to check which f
[
https://issues.apache.org/jira/browse/VFS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-252:
Fix Version/s: (was: 2.0)
2.1
> SmbFileObject does not support setLastModifiedTime while jcifs supports it,
> it is critical for a backup application that checks the last modified time
> stamp to check which files needs to be updated
> -
>
> Key: VFS-252
> URL: https://issues.apache.org/jira/browse/VFS-252
> Project: Commons VFS
> Issue Type: Improvement
>Affects Versions: later
>Reporter: Gerrit Cap
>Priority: Critical
> Fix For: 2.1
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> /**
>* @throws Exception
> * @see
> org.apache.commons.vfs.provider.AbstractFileObject#doSetLastModifiedTime(long)
>*/
> protected boolean doSetLastModTime(long modtime) throws Exception {
> file.setLastModified(modtime);
> return true;
> }
--
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] (VFS-279) ClassCastException in LocalFileSystem when using OnCall caching
[ https://issues.apache.org/jira/browse/VFS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-279: Fix Version/s: (was: 2.0) 2.1 > ClassCastException in LocalFileSystem when using OnCall caching > --- > > Key: VFS-279 > URL: https://issues.apache.org/jira/browse/VFS-279 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.0, 1.1, 2.0 >Reporter: Didier Earith > Fix For: 1.0, 1.1, 2.1 > > Attachments: LocalFileSystem.java > > > When using OnCall caching in the file system, there is a ClassCastException > in the LocalFileSystem#doReplicateFile function. > To fix the issue, I replaced : > final LocalFile localFile = (LocalFile) fileObject; > by > final LocalFile localFile = (LocalFile) > FileObjectUtils.getAbstractFileObject(fileObject); -- 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] (VFS-266) AbstractFileName and AbstractFileObject serialization
[ https://issues.apache.org/jira/browse/VFS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-266: Fix Version/s: (was: 2.0) 2.1 > AbstractFileName and AbstractFileObject serialization > - > > Key: VFS-266 > URL: https://issues.apache.org/jira/browse/VFS-266 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Google App Engine Java >Reporter: Vince Bonfanti > Fix For: 2.1 > > Attachments: > VFS-abstractfilename-abstractfileobject-serialization.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > I'm implementing a VFS plug-in that implements a distributed, writeable file > system for Google App Engine (GAE) Java (see gaevfs.appspot.com for more > info). In order for this to work properly, I need to create a distributed > FilesCache implementation using the memcache API provided by GAE. However, > memcache requires that both keys and values must be serializable. Therefore, > to complete my implementation, I need to make AbstractFileName and > AbstractFileObject serializable (because my implementation classes inherit > from these). -- 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] (VFS-393) The ls command allways returns the cached data
[ https://issues.apache.org/jira/browse/VFS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-393: Fix Version/s: (was: 2.0) 2.1 > The ls command allways returns the cached data > -- > > Key: VFS-393 > URL: https://issues.apache.org/jira/browse/VFS-393 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: Red hat Linux >Reporter: Prasad Kulkarni >Priority: Blocker > Labels: patch > Fix For: 2.1 > > > We have follwed the below steps to reproduce the issue > 1. Created a folder under /home/xyz with name abc > 2. Tried to get the Childrens of /home/xyz > 3. I have got the folder listed as 'abc' although there are few other > childrens which are not considered and listed > 4. Deleted the folder 'abc' > 5. Tried to get the Childrens of /home/xyz > 6. It is still listing the folder 'abc' > We have also tried all three possible cache strategy but no luck. -- 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] (VFS-348) Upgrade to commons-net 2.2
[ https://issues.apache.org/jira/browse/VFS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-348: Fix Version/s: (was: 2.0) 2.1 > Upgrade to commons-net 2.2 > -- > > Key: VFS-348 > URL: https://issues.apache.org/jira/browse/VFS-348 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: Nightly Builds, 2.0 >Reporter: Stefan Bodewig >Priority: Minor > Fix For: 2.1 > > Attachments: vfs-net22.patch > > > commons-net says they recommend all users of 2.0 should upgrade to 2.2 > because of the number of fixed issues. Who knows, maybe some of the FTP > issues of VFS are addressed as well. > It would also make the commons-vfs2 build in Gump work again. > The patch is trivial and the one I'll append also fixes the usage of a > deprecated method - inside a log statement inside the example code, yay - > which is required to make Gump happy. -- 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] (VFS-313) CLONE -FTP configuration does not include option for setting socket timeout
[ https://issues.apache.org/jira/browse/VFS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-313: Fix Version/s: (was: 2.0) 2.1 > CLONE -FTP configuration does not include option for setting socket timeout > --- > > Key: VFS-313 > URL: https://issues.apache.org/jira/browse/VFS-313 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Brad Davis > Fix For: 2.1 > > Attachments: patch.txt > > > The FTP Configuration includes an option to set a timeout for the data > connection, but not for the socket timeout. This is a problem, as idle > sockets can cause your download to hang forever and never timeout. -- 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] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-398:
Fix Version/s: (was: 2.0)
2.1
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Priority: Blocker
> Fix For: 2.1
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision&revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file";);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
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] (VFS-395) [POM] Declare maven-scm-* dependencies as optional.
[ https://issues.apache.org/jira/browse/VFS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-395: Fix Version/s: 2.1 Summary: [POM] Declare maven-scm-* dependencies as optional. (was: VFS2 should declare maven-scm-* dependencies as optional in pom) > [POM] Declare maven-scm-* dependencies as optional. > --- > > Key: VFS-395 > URL: https://issues.apache.org/jira/browse/VFS-395 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Xavier Dury > Fix For: 2.1 > > > VFS2 includes weird dependencies: maven-scm-api, maven-scm-provider-svnexe. > See http://commons.apache.org/vfs/commons-vfs2/dependencies.html -- 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] (VFS-410) [SFTP] SftpFileObject getInputStream(long) reads the whole file into memory
[
https://issues.apache.org/jira/browse/VFS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-410:
Summary: [SFTP] SftpFileObject getInputStream(long) reads the whole file
into memory (was: If using getInputStream(long position) on SftpFileObject the
file is read into memory)
> [SFTP] SftpFileObject getInputStream(long) reads the whole file into memory
> ---
>
> Key: VFS-410
> URL: https://issues.apache.org/jira/browse/VFS-410
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Martin Stockhammer
> Fix For: 2.1
>
> Attachments: SftpFileObject.java.patch
>
>
> The method {{getInputStream(long filePointer)}} in {{SftpFileObject.java}}
> reads the complete file into memory to create the input stream.
> Newer versions of JSch provide a method
> {{channel.get(file, monitor, filePointer);}}
> that is much faster.
--
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] (VFS-411) [SFTP] Update Jsch to version 0.1.47 from 0.1.46.
[ https://issues.apache.org/jira/browse/VFS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-411: Summary: [SFTP] Update Jsch to version 0.1.47 from 0.1.46. (was: [SFTP] Update Jsch to version 0.1.47) > [SFTP] Update Jsch to version 0.1.47 from 0.1.46. > - > > Key: VFS-411 > URL: https://issues.apache.org/jira/browse/VFS-411 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_31, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_31\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.1 > > > [SFTP] Update Jsch to version 0.1.47 from 0.1.46. -- 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] (IO-326) Add new FileUtils.sizeOf[Directory] APIs to return BigInteger
[ https://issues.apache.org/jira/browse/IO-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-326: --- Fix Version/s: 2.4 Committed first cut as sizeOf[Directory]AsBigInteger > Add new FileUtils.sizeOf[Directory] APIs to return BigInteger > - > > Key: IO-326 > URL: https://issues.apache.org/jira/browse/IO-326 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.3 >Reporter: Gary D. Gregory > Fix For: 2.4 > > > FileUtils.sizeOfDirectory will return a negative number when the size count > goes past Long.MAX_VALUE. > Counting with a BigInteger will solve this issue. Options: > - Change the signature of FileUtils.sizeOfDirectory() to return a BigInteger. > This will obviously break BC. > - Create a new API to return a BigInteger. What would this new API be called? > -- sizeOfDirectoryAsBigInteger > -- bigIntegerSizeOfDirectory > -- largeSizeOfDirectory > -- ...? -- 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] (IO-326) Add new FileUtils.sizeOf[Directory] APIs to return BigInteger
[ https://issues.apache.org/jira/browse/IO-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-326: --- Summary: Add new FileUtils.sizeOf[Directory] APIs to return BigInteger (was: Add or change FileUtils.sizeOfDirectory API such that it does not overflow) > Add new FileUtils.sizeOf[Directory] APIs to return BigInteger > - > > Key: IO-326 > URL: https://issues.apache.org/jira/browse/IO-326 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.3 >Reporter: Gary D. Gregory > > FileUtils.sizeOfDirectory will return a negative number when the size count > goes past Long.MAX_VALUE. > Counting with a BigInteger will solve this issue. Options: > - Change the signature of FileUtils.sizeOfDirectory() to return a BigInteger. > This will obviously break BC. > - Create a new API to return a BigInteger. What would this new API be called? > -- sizeOfDirectoryAsBigInteger > -- bigIntegerSizeOfDirectory > -- largeSizeOfDirectory > -- ...? -- 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] (IO-326) Add or change FileUtils.sizeOfDirectory API such that it does not overflow
[ https://issues.apache.org/jira/browse/IO-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-326: --- Summary: Add or change FileUtils.sizeOfDirectory API such that it does not overflow (was: Add or change FileUtils.sizeOfDirectory API that does not overflow) > Add or change FileUtils.sizeOfDirectory API such that it does not overflow > -- > > Key: IO-326 > URL: https://issues.apache.org/jira/browse/IO-326 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.3 >Reporter: Gary D. Gregory > > FileUtils.sizeOfDirectory will return a negative number when the size count > goes past Long.MAX_VALUE. > Counting with a BigInteger will solve this issue. Options: > - Change the signature of FileUtils.sizeOfDirectory() to return a BigInteger. > This will obviously break BC. > - Create a new API to return a BigInteger. What would this new API be called? > -- sizeOfDirectoryAsBigInteger > -- bigIntegerSizeOfDirectory > -- largeSizeOfDirectory > -- ...? -- 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] (IO-318) Add Charset sister APIs to method that take a String charset name.
[ https://issues.apache.org/jira/browse/IO-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-318: --- Description: Add Charset sister APIs to method that take a String charset name (aka encoding). For example: foo(..., String charsetName) -> foo(..., Charset charset). Refactor such that we do not have code duplication of the algorithms. Known issue: Source compatibility. Now there are APIs that change only with the last type, String vs. Charset, you will get a compile error if you pass null to the old String API because the target method will be ambiguous: do you want to call the String or Charset version? You must type-cast to one type or the other. Known issue: checked java.io.UnsupportedEncodingException vs. unchecked java.nio.charset.UnsupportedCharsetException The JRE API Charset.forName throws the unchecked UnsupportedCharsetException. The Commons IO 2.2 String APIs throw the checked UnsupportedEncodingException, a subclass of IOException, when a charset is not available. The refactored String APIs throw UnsupportedCharsetException from Charset.forName, an unchecked IllegalArgumentException. The String APIs throw IOException, so there is no source compatibility issue. If you somehow relied on catching the checked UnsupportedEncodingException instead of IOException, its superclass, you should catch the unchecked java.nio.charset.UnsupportedCharsetException to act on the fact that the charset is not available. was: Add Charset sister APIs to method that take a String charset name (aka encoding). For example: foo(..., String charsetName) -> foo(..., Charset charset). Refactor such that we do not have code duplication of the algorithms. Known issue: Source compatibility. Now there are APIs that change only with the last type, String vs. Charset, you will get a compile error if you pass null to the old String API because the target method will be ambiguous: do you want to call the String or Charset version? You must type-cast to one type or the other. Known issue: checked java.io.UnsupportedEncodingException vs. unchecked java.nio.charset.UnsupportedCharsetException The JRE API Charset.forName throws the unchecked UnsupportedCharsetException. The Commons IO 2.2 String APIs throw the checked UnsupportedEncodingException, a subclass of IOException, when an charset is not available. The refactored String APIs throw UnsupportedCharsetException from Charset.forName, an unchecked IllegalArgumentException. The String APIs throw IOException, so there is no source compatibility issue. If you somehow relied on catching the checked UnsupportedEncodingException instead of IOException, its superclass, you should catch the unchecked java.nio.charset.UnsupportedCharsetException to act on the fact that the charset is not available. Fix typo in description. > Add Charset sister APIs to method that take a String charset name. > -- > > Key: IO-318 > URL: https://issues.apache.org/jira/browse/IO-318 > Project: Commons IO > Issue Type: New Feature > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.7.0_03, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_03\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.3 > > > Add Charset sister APIs to method that take a String charset name (aka > encoding). > For example: foo(..., String charsetName) -> foo(..., Charset charset). > Refactor such that we do not have code duplication of the algorithms. > Known issue: Source compatibility. > Now there are APIs that change only with the last type, String vs. Charset, > you will get a compile error if you pass null to the old String API because > the target method will be ambiguous: do you want to call the String or > Charset version? You must type-cast to one type or the other. > Known issue: checked java.io.UnsupportedEncodingException vs. unchecked > java.nio.charset.UnsupportedCharsetException > The JRE API Charset.forName throws the unchecked UnsupportedCharsetException. > The Commons IO 2.2 String APIs throw the checked > UnsupportedEncodingException, a subclass of IOException, when a charset is > not available. > The refactored String APIs throw UnsupportedCharsetException from > Charset.forName, an unchecked IllegalArgumentException. The String APIs throw > IOException, so there is no source compatibility issue. > If you somehow relied on catching the checked UnsupportedEncodingException > instead of IOException, its superclass, you should catch the unchecked > java.nio.charset.UnsupportedCharsetException
[jira] [Updated] (IO-318) Add Charset sister APIs to method that take a String charset name.
[ https://issues.apache.org/jira/browse/IO-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-318: --- Description: Add Charset sister APIs to method that take a String charset name (aka encoding). For example: foo(..., String charsetName) -> foo(..., Charset charset). Refactor such that we do not have code duplication of the algorithms. Known issue: Source compatibility. Now there are APIs that change only with the last type, String vs. Charset, you will get a compile error if you pass null to the old String API because the target method will be ambiguous: do you want to call the String or Charset version? You must type-cast to one type or the other. Known issue: checked java.io.UnsupportedEncodingException vs. unchecked java.nio.charset.UnsupportedCharsetException The JRE API Charset.forName throws the unchecked UnsupportedCharsetException. The Commons IO 2.2 String APIs throw the checked UnsupportedEncodingException, a subclass of IOException, when an charset is not available. The refactored String APIs throw UnsupportedCharsetException from Charset.forName, an unchecked IllegalArgumentException. The String APIs throw IOException, so there is no source compatibility issue. If you somehow relied on catching the checked UnsupportedEncodingException instead of IOException, its superclass, you should catch the unchecked java.nio.charset.UnsupportedCharsetException to act on the fact that the charset is not available. was: Add Charset sister APIs to method that take a String charset name (aka encoding). For example: foo(..., String charsetName) -> foo(..., Charset charset). Refactor such that we do not have code duplication of the algorithms. Known issue: Source compatibility. Now there are APIs that change only by the last type, String vs. Charset, you will get a compile error if you pass null to the API because the target method will be ambiguous, so you have to type cast to one type or the other. > Add Charset sister APIs to method that take a String charset name. > -- > > Key: IO-318 > URL: https://issues.apache.org/jira/browse/IO-318 > Project: Commons IO > Issue Type: New Feature > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.7.0_03, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_03\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.3 > > > Add Charset sister APIs to method that take a String charset name (aka > encoding). > For example: foo(..., String charsetName) -> foo(..., Charset charset). > Refactor such that we do not have code duplication of the algorithms. > Known issue: Source compatibility. > Now there are APIs that change only with the last type, String vs. Charset, > you will get a compile error if you pass null to the old String API because > the target method will be ambiguous: do you want to call the String or > Charset version? You must type-cast to one type or the other. > Known issue: checked java.io.UnsupportedEncodingException vs. unchecked > java.nio.charset.UnsupportedCharsetException > The JRE API Charset.forName throws the unchecked UnsupportedCharsetException. > The Commons IO 2.2 String APIs throw the checked > UnsupportedEncodingException, a subclass of IOException, when an charset is > not available. > The refactored String APIs throw UnsupportedCharsetException from > Charset.forName, an unchecked IllegalArgumentException. The String APIs throw > IOException, so there is no source compatibility issue. > If you somehow relied on catching the checked UnsupportedEncodingException > instead of IOException, its superclass, you should catch the unchecked > java.nio.charset.UnsupportedCharsetException to act on the fact that the > charset is not available. -- 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] (CODEC-136) Use Charset objects when possible, create Charsets class for required character encodings
[ https://issues.apache.org/jira/browse/CODEC-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-136: -- Summary: Use Charset objects when possible, create Charsets class for required character encodings (was: Use Charset objects when possible, create Charsets for required character encodings) > Use Charset objects when possible, create Charsets class for required > character encodings > - > > Key: CODEC-136 > URL: https://issues.apache.org/jira/browse/CODEC-136 > Project: Commons Codec > Issue Type: New Feature > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_31, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_31\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 1.7 > > > Use Charset objects when possible, create Charsets for required character > encodings. -- 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] (CODEC-136) Use Charset objects when possible, create Charsets for required character encodings
[ https://issues.apache.org/jira/browse/CODEC-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-136: -- Fix Version/s: 1.7 > Use Charset objects when possible, create Charsets for required character > encodings > --- > > Key: CODEC-136 > URL: https://issues.apache.org/jira/browse/CODEC-136 > Project: Commons Codec > Issue Type: New Feature > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_31, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_31\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 1.7 > > > Use Charset objects when possible, create Charsets for required character > encodings. -- 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] (IO-287) Use terabyte (TB), petabyte (PB) and exabyte (EB) in FileUtils.byteCountToDisplaySize(long size)
[ https://issues.apache.org/jira/browse/IO-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-287: --- Summary: Use terabyte (TB), petabyte (PB) and exabyte (EB) in FileUtils.byteCountToDisplaySize(long size) (was: Use terabyte (TB) , petabyte (PB) and exabyte (EB) in FileUtils.byteCountToDisplaySize(long size)) Fix typo in issue title. > Use terabyte (TB), petabyte (PB) and exabyte (EB) in > FileUtils.byteCountToDisplaySize(long size) > > > Key: IO-287 > URL: https://issues.apache.org/jira/browse/IO-287 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.2 > > Attachments: IO-287-r1200701.patch.txt > > > Use terabyte (TB) , petabyte (PB) and exabyte (EB) in > FileUtils.byteCountToDisplaySize(long size). > Currently, the code is commented out. -- 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] (VFS-407) [RAM] Reading a RAM FileSystem file fails because it never returns EOF -1.
[
https://issues.apache.org/jira/browse/VFS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-407:
Fix Version/s: 2.1
Summary: [RAM] Reading a RAM FileSystem file fails because it never
returns EOF -1. (was: Reading a RAM FileSystem file fails because it never
returns EOF -1.)
> [RAM] Reading a RAM FileSystem file fails because it never returns EOF -1.
> --
>
> Key: VFS-407
> URL: https://issues.apache.org/jira/browse/VFS-407
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Miroslav Pokorny
> Fix For: 2.1
>
> Attachments: CustomRamProviderTest.java,
> EmptyRamProviderFileBugTests-from-miroslav.pokorny-20120322.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> RamFileRandomAccessContent
> ORIGINAL
> @Override
> public int read(byte[] b, int off, int len) throws IOException
> {
> int retLen = Math.min(len, getLeftBytes());
> RamFileRandomAccessContent.this.readFully(b, off, retLen);
> return retLen;
> }
> // getLeftBytes() returns 0 when empty. retLen is 0 when empty and never -1.
> FIXED
> // HACK Patched to return -1 when empty previously it returned 0
> @Override
> public int read(final byte[] b, final int off, final int len)
> throws IOException {
> int retLen = InputStreams.END;
> final int left =
> RamFileRandomAccessContent.this.getLeftBytes();
> if (left > 0) {
> retLen = Math.min(len, left);
> RamFileRandomAccessContent.this.readFully(b, off, retLen);
> }
> return retLen;
> }
--
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] (VFS-407) Reading a RAM FileSystem file fails because it never returns EOF -1.
[
https://issues.apache.org/jira/browse/VFS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-407:
Summary: Reading a RAM FileSystem file fails because it never returns EOF
-1. (was: reading a RAM FileSystem file fails because it never returns EOF -1.)
> Reading a RAM FileSystem file fails because it never returns EOF -1.
>
>
> Key: VFS-407
> URL: https://issues.apache.org/jira/browse/VFS-407
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Miroslav Pokorny
> Attachments: CustomRamProviderTest.java,
> EmptyRamProviderFileBugTests-from-miroslav.pokorny-20120322.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> RamFileRandomAccessContent
> ORIGINAL
> @Override
> public int read(byte[] b, int off, int len) throws IOException
> {
> int retLen = Math.min(len, getLeftBytes());
> RamFileRandomAccessContent.this.readFully(b, off, retLen);
> return retLen;
> }
> // getLeftBytes() returns 0 when empty. retLen is 0 when empty and never -1.
> FIXED
> // HACK Patched to return -1 when empty previously it returned 0
> @Override
> public int read(final byte[] b, final int off, final int len)
> throws IOException {
> int retLen = InputStreams.END;
> final int left =
> RamFileRandomAccessContent.this.getLeftBytes();
> if (left > 0) {
> retLen = Math.min(len, left);
> RamFileRandomAccessContent.this.readFully(b, off, retLen);
> }
> return retLen;
> }
--
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] (IO-310) Add ByteOrderMark constants for UTF-32
[ https://issues.apache.org/jira/browse/IO-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-310: --- Summary: Add ByteOrderMark constants for UTF-32 (was: Add ByteOrderMark constants for UTF-32 little and big endian.) > Add ByteOrderMark constants for UTF-32 > -- > > Key: IO-310 > URL: https://issues.apache.org/jira/browse/IO-310 > Project: Commons IO > Issue Type: New Feature > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_31, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_31\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > > Add ByteOrderMark constants for UTF-32. > This is useful for XML processing. See > http://www.w3.org/TR/2006/REC-xml-20060816/#sec-guessing -- 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] (CODEC-130) Base64InputStream.skip skips underlying stream, not output
[
https://issues.apache.org/jira/browse/CODEC-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CODEC-130:
--
Fix Version/s: 1.7
> Base64InputStream.skip skips underlying stream, not output
> --
>
> Key: CODEC-130
> URL: https://issues.apache.org/jira/browse/CODEC-130
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: James Pickering
>Priority: Minor
> Fix For: 1.7
>
> Attachments: base64snippet.java
>
>
> Base64InputStream.skip() skips within underlying stream, leading to
> unexpected behaviour.
> The following code will reproduce the issue:
> @Test
> public void testSkip() throws Throwable {
> InputStream ins =
> new
> ByteArrayInputStream("".getBytes("ISO-8859-1"));//should decode to
> {0, 0, 0, 255, 255, 255}
> Base64InputStream instance = new Base64InputStream(ins);
> assertEquals(3L, instance.skip(3L)); //should skip 3 decoded characters,
> or 4 encoded characters
> assertEquals(255, instance.read()); //Currently returns 3, as it is
> decoding "A/", not "//"
> }
> The following code, if added to Base64InputStream, or (BaseNCodecInputStream
> in the dev build) would resolve the issue:
> @Override
> public long skip(long n) throws IOException {
> //delegate to read()
> long bytesRead = 0;
> while ((bytesRead < n) && (read() != -1)) {
> bytesRead++;
> }
> return bytesRead;
> }
> More efficient code may be possible.
--
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] (CODEC-130) Base64InputStream.skip skips underlying stream, not output
[
https://issues.apache.org/jira/browse/CODEC-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CODEC-130:
--
Comment: was deleted
(was: Hi TN,
Feel free to patch and unit test with sufficient code coverage.
Gary)
> Base64InputStream.skip skips underlying stream, not output
> --
>
> Key: CODEC-130
> URL: https://issues.apache.org/jira/browse/CODEC-130
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: James Pickering
>Priority: Minor
> Attachments: base64snippet.java
>
>
> Base64InputStream.skip() skips within underlying stream, leading to
> unexpected behaviour.
> The following code will reproduce the issue:
> @Test
> public void testSkip() throws Throwable {
> InputStream ins =
> new
> ByteArrayInputStream("".getBytes("ISO-8859-1"));//should decode to
> {0, 0, 0, 255, 255, 255}
> Base64InputStream instance = new Base64InputStream(ins);
> assertEquals(3L, instance.skip(3L)); //should skip 3 decoded characters,
> or 4 encoded characters
> assertEquals(255, instance.read()); //Currently returns 3, as it is
> decoding "A/", not "//"
> }
> The following code, if added to Base64InputStream, or (BaseNCodecInputStream
> in the dev build) would resolve the issue:
> @Override
> public long skip(long n) throws IOException {
> //delegate to read()
> long bytesRead = 0;
> while ((bytesRead < n) && (read() != -1)) {
> bytesRead++;
> }
> return bytesRead;
> }
> More efficient code may be possible.
--
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] (CODEC-121) QuotedPrintableCodec does not support soft line break per the 'quoted-printable' example on Wikipedia
[ https://issues.apache.org/jira/browse/CODEC-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-121: -- Fix Version/s: (was: 1.6.1) 1.7 > QuotedPrintableCodec does not support soft line break per the > 'quoted-printable' example on Wikipedia > - > > Key: CODEC-121 > URL: https://issues.apache.org/jira/browse/CODEC-121 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.5, 1.6 > Environment: I tested on Windows 7. >Reporter: Java John > Labels: codec, decode, quoted-printable > Fix For: 1.7 > > Attachments: CODEC-121.patch, CODEC-121_v2.patch > > > Writing a unit test I discovered that the example Wikipedia uses for > quoted-printable data does not decode but instead throws an exception. > Their example is here: http://en.wikipedia.org/wiki/Quoted-printable#Example > test: > String qpdata = "If you believe that truth=3Dbeauty, then surely=20=\r\n" > + > "mathematics is the most beautiful branch of philosophy."; > String expected = "If you believe that truth=beauty, then surely " + > "mathematics is the most beautiful branch of philosophy."; > assertEquals( expected, new QuotedPrintableCodec().decode(qpdata) ); > I suppose I could fix if you like but currently I'm not a registered > developer. -- 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] (CODEC-132) BeiderMorseEncoder OOM issues
[ https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-132: -- Fix Version/s: (was: 1.6.1) 1.7 > BeiderMorseEncoder OOM issues > - > > Key: CODEC-132 > URL: https://issues.apache.org/jira/browse/CODEC-132 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Robert Muir > Fix For: 1.7 > > Attachments: CODEC-132.patch, CODEC-132_test.patch > > > In Lucene/Solr, we integrated this encoder into the latest release. > Our tests use a variety of random strings, and we have recent jenkins failures > from some input streams (of length <= 10), using huge amounts of memory (e.g. > > 64MB), > resulting in OOM. > I've created a test case (length is 30 here) that will OOM with -Xmx256M. > I haven't dug into this much as to what's causing it, but I suspect there > might be a bug > revolving around certain punctuation characters: we didn't see this happening > until > we beefed up our random string generation to start producing "html-like" > strings. -- 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] (CODEC-131) DoubleMetaphone javadoc contains dead links
[ https://issues.apache.org/jira/browse/CODEC-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-131: -- Fix Version/s: (was: 1.6.1) 1.7 > DoubleMetaphone javadoc contains dead links > --- > > Key: CODEC-131 > URL: https://issues.apache.org/jira/browse/CODEC-131 > Project: Commons Codec > Issue Type: Bug >Reporter: Santiago M. Mola >Priority: Trivial > Labels: documentation > Fix For: 1.7 > > > DoubleMetaphone documentation points to dead links in the domain cuj.com: >Original Article: http://www.cuj.com/documents/s=8038/cuj0006philips/ >Original Source Code: ftp://ftp.cuj.com/pub/2000/1806/philips.zip -- 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] (CODEC-63) Implement NYSIIS
[ https://issues.apache.org/jira/browse/CODEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-63: - Fix Version/s: (was: 1.x) 1.7 > Implement NYSIIS > > > Key: CODEC-63 > URL: https://issues.apache.org/jira/browse/CODEC-63 > Project: Commons Codec > Issue Type: New Feature >Affects Versions: 1.x >Reporter: Henri Yandell > Fix For: 1.7 > > Attachments: CODEC-63-reworked.tar, Nysiis.patch, > codec-63-nysiis-ggregory.diff > > > http://en.wikipedia.org/wiki/NYSIIS -- 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] (CODEC-63) Implement NYSIIS
[ https://issues.apache.org/jira/browse/CODEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-63: - Attachment: codec-63-nysiis-ggregory.diff Takes the previous patches, adds tests to improve code coverage and show issues (bugs or not). Also adds trueLength (6) boolean. > Implement NYSIIS > > > Key: CODEC-63 > URL: https://issues.apache.org/jira/browse/CODEC-63 > Project: Commons Codec > Issue Type: New Feature >Affects Versions: 1.x >Reporter: Henri Yandell > Fix For: 1.x > > Attachments: CODEC-63-reworked.tar, Nysiis.patch, > codec-63-nysiis-ggregory.diff > > > http://en.wikipedia.org/wiki/NYSIIS -- 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] (CODEC-63) Implement NYSIIS
[ https://issues.apache.org/jira/browse/CODEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-63: - Summary: Implement NYSIIS (was: Implement Nysiis) > Implement NYSIIS > > > Key: CODEC-63 > URL: https://issues.apache.org/jira/browse/CODEC-63 > Project: Commons Codec > Issue Type: New Feature >Affects Versions: 1.x >Reporter: Henri Yandell > Fix For: 1.x > > Attachments: CODEC-63-reworked.tar, Nysiis.patch > > > http://en.wikipedia.org/wiki/NYSIIS -- 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] (CODEC-121) QuotedPrintableCodec does not support soft line break per the 'quoted-printable' example on Wikipedia
[ https://issues.apache.org/jira/browse/CODEC-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-121: -- Affects Version/s: 1.6 Fix Version/s: (was: 1.x) 1.6.1 > QuotedPrintableCodec does not support soft line break per the > 'quoted-printable' example on Wikipedia > - > > Key: CODEC-121 > URL: https://issues.apache.org/jira/browse/CODEC-121 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.5, 1.6 > Environment: I tested on Windows 7. >Reporter: Java John > Labels: codec, decode, quoted-printable > Fix For: 1.6.1 > > Attachments: CODEC-121.patch, CODEC-121_v2.patch > > > Writing a unit test I discovered that the example Wikipedia uses for > quoted-printable data does not decode but instead throws an exception. > Their example is here: http://en.wikipedia.org/wiki/Quoted-printable#Example > test: > String qpdata = "If you believe that truth=3Dbeauty, then surely=20=\r\n" > + > "mathematics is the most beautiful branch of philosophy."; > String expected = "If you believe that truth=beauty, then surely " + > "mathematics is the most beautiful branch of philosophy."; > assertEquals( expected, new QuotedPrintableCodec().decode(qpdata) ); > I suppose I could fix if you like but currently I'm not a registered > developer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-423) FTPClient.storeFile might fail when ControlKeepAliveTimeout is set
[
https://issues.apache.org/jira/browse/NET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated NET-423:
Summary: FTPClient.storeFile might fail when ControlKeepAliveTimeout is set
(was: FTPClient.storeFIle might fail when ControlKeepAliveTimeout is set)
Fix typo in ticket tile.
> FTPClient.storeFile might fail when ControlKeepAliveTimeout is set
> --
>
> Key: NET-423
> URL: https://issues.apache.org/jira/browse/NET-423
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1
>Reporter: Jens Koch
>Priority: Minor
> Fix For: 3.1
>
>
> When setting ControlKeepAliveTimeout. FTPClient.__storeFile might fail when
> waiting for ack on ControlConnection.
> Current code:
> {noformat}
> // Get the transfer response
> boolean ok = completePendingCommand();
> if (csl != null) {
> csl.cleanUp(); // fetch any outstanding keepalive replies
> }
> {noformat}
> While CSL is active, the ControlConnection timeout is set to 1 sec., if using
> default. This timeout value doesn't leave much room in terms of network/end
> point latency.
> Replacing the code fragment above with the following fragment probably solves
> the problem (If proper ControlConnection timeout value is set):
> {noformat}
> if (csl != null) {
> csl.cleanUp(); // fetch any outstanding keepalive replies
> }
> // Get the transfer response
> boolean ok = completePendingCommand();
> {noformat}
> One workaround is to set ControlKeepAliveReplyTimeout to a higher value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-404) [FTP][FTPS] Update Apache Commons Net to 3.1 from 3.0.1
[ https://issues.apache.org/jira/browse/VFS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-404: Summary: [FTP][FTPS] Update Apache Commons Net to 3.1 from 3.0.1 (was: Update Apache Commons Net to 3.1 from 3.0.1) > [FTP][FTPS] Update Apache Commons Net to 3.1 from 3.0.1 > --- > > Key: VFS-404 > URL: https://issues.apache.org/jira/browse/VFS-404 > Project: Commons VFS > Issue Type: Task >Affects Versions: 2.0 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 2.1 > > > Update Apache Commons Net to 3.1 from 3.0.1. -- 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] (IO-303) TeeOutputStream does not call branch.close() when main.close() throws an exception
[
https://issues.apache.org/jira/browse/IO-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-303:
---
Fix Version/s: 2.2
Assignee: Gary D. Gregory
Summary: TeeOutputStream does not call branch.close() when
main.close() throws an exception (was: TeeOutputStream fails executing
branch.close() when main.close() raised an exception)
> TeeOutputStream does not call branch.close() when main.close() throws an
> exception
> --
>
> Key: IO-303
> URL: https://issues.apache.org/jira/browse/IO-303
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.1
>Reporter: Fabian Barney
>Assignee: Gary D. Gregory
> Labels: close, stream
> Fix For: 2.2
>
>
> TeeOutputStream.close() looks like this:
> {code:title=TeeOutputStream.java|borderStyle=solid}
> /**
> * Closes both streams.
> * @throws IOException if an I/O error occurs
> */
> @Override
> public void close() throws IOException {
> super.close();
> this.branch.close();
> }
> {code}
> It is obvious that {{this.branch.close()}} is not executed when
> {{super.close()}} raises an exception. {{super.close()}} may in fact raise an
> IOException since {{ProxyOutputStream.handleIOException(IOException)}} is not
> overridden.
--
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] (POOL-161) ContextClassLoader problems for the Evictor thread
[ https://issues.apache.org/jira/browse/POOL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated POOL-161: - Fix Version/s: 1.6.1 > ContextClassLoader problems for the Evictor thread > -- > > Key: POOL-161 > URL: https://issues.apache.org/jira/browse/POOL-161 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.4 >Reporter: Sylvain Laurent > Fix For: 1.6.1, 2.0 > > Attachments: TestGenericObjectPoolClassLoader.patch.txt, > patch_Evictor_CCL.txt > > > Since a single Timer is used for several GenericObjectPool instances, this > may create classloader issues and a memory leak of one classloader : > Let's imagine the following scenario : > - commons-pool.jar is in the classpath of a webapp container (e.g. tomcat). > - 2 webapps A and B are deployed, each creating an instance of > GenericObjectPool for its own usage. > - each webapp makes use of the idle object evictor and sets a positive number > for minIdle > - first, webapp A instantiates its GenericObjectPool. Since this is the first > TimerTask to be created, the Timer instance is created, thus creating a > Thread whose ContextClassLoader is the current one, that is webapp A's > ContextClassLoader. > The TimerTask properly creates instances of idle objects in the pool, making > use of the ObjectFactory provided by A. > - then B instantiates its GenericObjectPool. A new TimerTask is created, and > it tries to invoke the ObjectFactory provided by B. But when it needs a class > that only exists in B webapp, it cannot find it because the > ContextClassLoader of the Timer Thread is A's classloader. > Other side effect : if webapp A is undeployed, but B is still running, then > A's webappClassLoader cannot be GCed because the Timer Thread keeps a strong > reference to A's classloader (as its context classloader). -- 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] (VFS-392) Build tests WebDAV file system with an embedded WebDAV server (Apache Jackrabbit).
[ https://issues.apache.org/jira/browse/VFS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-392: Summary: Build tests WebDAV file system with an embedded WebDAV server (Apache Jackrabbit). (was: Build tests WebDAV file system with an embedded WebDAV server (Apache Jackrabbit?).) > Build tests WebDAV file system with an embedded WebDAV server (Apache > Jackrabbit). > -- > > Key: VFS-392 > URL: https://issues.apache.org/jira/browse/VFS-392 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.1 > > > The build should test the WebDAV file system with an embedded HTTP server > like Apache Jackrabbit. -- 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] (VFS-400) Add a FileSelector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-400:
Summary: Add a FileSelector based on regular expressions (was: Selector
based on regular expressions)
> Add a FileSelector based on regular expressions
> ---
>
> Key: VFS-400
> URL: https://issues.apache.org/jira/browse/VFS-400
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Rikard Oxenstrand
>Priority: Minor
> Attachments: FileRegexSelector.java.patch
>
>
> In the long todo list there was a post about adding a file selector based on
> regular expressions. I had need for that for a specific project so I built a
> simple class that seems to work. I'm kind of new to open source contribution
> though so I'm not sure if i should just commit it to trunk. Here is the code:
> {code:title=FileRegexSelector.java|borderStyle=solid}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.commons.vfs2;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> /**
> * A {@link FileSelector} that selects based on regular expressions matched
> against base filename.
> *
> * @since 2.1
> */
> public class FileRegexSelector implements FileSelector
> {
> /**
> * The extensions to select.
> */
> private Pattern pattern = null;
> /**
> * Creates a new selector for the given extensions.
> *
> * @param extensions
> *The extensions to be included by this selector.
> */
> public FileRegexSelector(String regex)
> {
> this.pattern = Pattern.compile(regex);
> }
> /**
> * Determines if a file or folder should be selected.
> * @param fileInfo
> *The file selection information.
> * @return true if the file should be selected, false otherwise.
> */
> public boolean includeFile(final FileSelectInfo fileInfo)
> {
> if (this.pattern == null)
> {
> return false;
> }
> Matcher matcher =
> this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
> return matcher.matches();
> }
> /**
> * Determines whether a folder should be traversed.
> *
> * @param fileInfo
> *The file selection information.
> * @return true if descendents should be traversed, fase otherwise.
> */
> public boolean traverseDescendents(final FileSelectInfo fileInfo)
> {
> return true;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-392) Build tests WebDAV file system with an embedded WebDAV server (Apache Jackrabbit?).
[ https://issues.apache.org/jira/browse/VFS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-392: Fix Version/s: 2.1 > Build tests WebDAV file system with an embedded WebDAV server (Apache > Jackrabbit?). > --- > > Key: VFS-392 > URL: https://issues.apache.org/jira/browse/VFS-392 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.1 > > > The build should test the WebDAV file system with an embedded HTTP server > like Apache Jackrabbit. -- 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] (IO-301) Add IOUtils.closeQuietly(Selector)
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-301: --- Summary: Add IOUtils.closeQuietly(Selector) (was: commons-io: IOUtils.closeQuietly(Selector) necessary ) > Add IOUtils.closeQuietly(Selector) > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > Attachments: IO-301.patch > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- 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] (POOL-210) Jar manifest.mf does not contain SVN information for Implementation-Build
[
https://issues.apache.org/jira/browse/POOL-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated POOL-210:
-
Description:
The value found in the manfest is:
{quote}
Implementation-Build: UNKNOWN_BRANCH@r??; 2012-01-04 10:31:47-0500
{quote}
This is fixed by upgrading to commons-parent 23 from 22.
The value should look like this:
{quote}
Implementation-Build: branches/POOL_1_X@r1229459; 2012-01-11 16:38:38-
0500
{quote}
was:
The value found in the manfest is:
Implementation-Build: UNKNOWN_BRANCH@r??; 2012-01-04 10:31:47-0500
This is fixed by upgrading to commons-parent 23 from 22.
> Jar manifest.mf does not contain SVN information for Implementation-Build
> -
>
> Key: POOL-210
> URL: https://issues.apache.org/jira/browse/POOL-210
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 1.6
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> svn, version 1.7.2-SlikSvn-1.7.2-X64 (SlikSvn/1.7.2) X64
>compiled Dec 6 2011, 13:13:15
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
> Fix For: 1.6.1
>
>
> The value found in the manfest is:
> {quote}
> Implementation-Build: UNKNOWN_BRANCH@r??; 2012-01-04 10:31:47-0500
> {quote}
> This is fixed by upgrading to commons-parent 23 from 22.
> The value should look like this:
> {quote}
> Implementation-Build: branches/POOL_1_X@r1229459; 2012-01-11 16:38:38-
> 0500
> {quote}
--
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] (POOL-210) Jar manifest.mf does not contain SVN information for Implementation-Build
[ https://issues.apache.org/jira/browse/POOL-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated POOL-210: - Fix Version/s: 1.6.1 > Jar manifest.mf does not contain SVN information for Implementation-Build > - > > Key: POOL-210 > URL: https://issues.apache.org/jira/browse/POOL-210 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.6 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > svn, version 1.7.2-SlikSvn-1.7.2-X64 (SlikSvn/1.7.2) X64 >compiled Dec 6 2011, 13:13:15 >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 1.6.1 > > > The value found in the manfest is: > Implementation-Build: UNKNOWN_BRANCH@r??; 2012-01-04 10:31:47-0500 > This is fixed by upgrading to commons-parent 23 from 22. -- 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] (POOL-208) Support Java 1.5 Generics in version 1.x.
[ https://issues.apache.org/jira/browse/POOL-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated POOL-208: - Fix Version/s: 1.6 > Support Java 1.5 Generics in version 1.x. > - > > Key: POOL-208 > URL: https://issues.apache.org/jira/browse/POOL-208 > Project: Commons Pool > Issue Type: Improvement > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 1.6 > > > Support Java 1.5 Generics in version 1.x. > Create a 1.x release with generics. Right now, that would be 1.6. -- 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] (CODEC-121) QuotedPrintableCodec does not support soft line break per the 'quoted-printable' example on Wikipedia
[ https://issues.apache.org/jira/browse/CODEC-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-121: -- Fix Version/s: (was: 1.6) 1.x > QuotedPrintableCodec does not support soft line break per the > 'quoted-printable' example on Wikipedia > - > > Key: CODEC-121 > URL: https://issues.apache.org/jira/browse/CODEC-121 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.5 > Environment: I tested on Windows 7. >Reporter: Java John > Labels: codec, decode, quoted-printable > Fix For: 1.x > > > Writing a unit test I discovered that the example Wikipedia uses for > quoted-printable data does not decode but instead throws an exception. > Their example is here: http://en.wikipedia.org/wiki/Quoted-printable#Example > test: > String qpdata = "If you believe that truth=3Dbeauty, then surely=20=\r\n" > + > "mathematics is the most beautiful branch of philosophy."; > String expected = "If you believe that truth=beauty, then surely " + > "mathematics is the most beautiful branch of philosophy."; > assertEquals( expected, new QuotedPrintableCodec().decode(qpdata) ); > I suppose I could fix if you like but currently I'm not a registered > developer. -- 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] (CODEC-95) Base64: optionally allow strict parsing of base64 strings
[
https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CODEC-95:
-
Fix Version/s: (was: 1.6)
1.x
> Base64: optionally allow strict parsing of base64 strings
> -
>
> Key: CODEC-95
> URL: https://issues.apache.org/jira/browse/CODEC-95
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Adam Rabung
>Priority: Minor
> Fix For: 1.x
>
> Attachments: strictMode.zip
>
>
> Currently, Codec skips base64 characters that are outside of the encode
> table. I realize this is perfectly to spec, but I wonder if other users
> might appreciate a "strict" mode that throws an exception when one of these
> illegal characters are encountered. For example, I would love an exception
> to be thrown here:
> new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));
--
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] (CODEC-104) Please add a function for the classical Unix crypt(3) hash
[ https://issues.apache.org/jira/browse/CODEC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-104: -- Fix Version/s: (was: 1.6) 1.x > Please add a function for the classical Unix crypt(3) hash > -- > > Key: CODEC-104 > URL: https://issues.apache.org/jira/browse/CODEC-104 > Project: Commons Codec > Issue Type: New Feature >Reporter: Christian Hammers > Fix For: 1.x > > > The Sun Java APIs lack a function for the classical Unix crypt(3) hash that > was used in e.g. /etc/passwd or Apache htpasswd and is still widely used > dispite the availablitity of better algorithms like MD5 or SHA. > Apart from me cursing Sun for producing monster crypto APIs but missing the > little things that one really needs, there are already several Apache projects > that implemented UnixCrypt for their own: > org.apache.directory.studio.ldapbrowser.core.utils.UnixCrypt > org.apache.fulcrum.crypto.impl.UnixCrypt > and maybe others > bye, > -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-91) Handling of embedded padding in base64 encoded data changed in 1.4
[
https://issues.apache.org/jira/browse/CODEC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CODEC-91:
-
Fix Version/s: (was: 1.6)
1.x
> Handling of embedded padding in base64 encoded data changed in 1.4
> --
>
> Key: CODEC-91
> URL: https://issues.apache.org/jira/browse/CODEC-91
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Chris Pimlott
>Assignee: Julius Davies
> Fix For: 1.x
>
> Attachments: codec-91-actually-works-and-tests-yay.patch
>
>
> 1.4 changed the way that embedded padding characters (i.e. "=") were handled
> when decoding base64 data. Previously, the decoder ignored them and decoded
> all the data. Now it stops upon encountering the first padding byte. This
> breaks compatibility with previous versions.
> For example, in 1.4,
> b64.decode("Y29tbW9ucwo=".getBytes());
> gives the same result as
> b64.decode("Y29tbW9ucwo=Y29tbW9ucwo=".getBytes());
--
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] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CODEC-96:
-
Fix Version/s: (was: 1.6)
1.x
> Base64 encode() method is no longer thread-safe, breaking clients using it as
> a shared BinaryEncoder
>
>
> Key: CODEC-96
> URL: https://issues.apache.org/jira/browse/CODEC-96
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Matt Ryall
>Assignee: Julius Davies
> Fix For: 1.x
>
> Attachments: codec-96-3rd-attempt.patch
>
>
> Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
> This introduced instance variables to Base64 which means the class can no
> longer be used as a shared BinaryEncoder instance.
> For example, BinaryEncoder has an interface which could be (and was) used
> like this with Base64:
> {code:java}
> class Example {
> private BinaryEncoder encoder = new Base64();
> byte[] someMethod(byte[] data) {
> try {
> return encoder.encode(data);
> }
> catch (EncoderException e) {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
> which is accessed by multiple threads can throw NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
> at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
> at ... (application code)
> {noformat}
> Looking at the implementation of Base64, I think making it thread-safe for
> this kind of usage would be quite tricky. I haven't attempted to prepare a
> patch.
> I would be happy if it was indicated in the Javadoc that Base64 is not
> thread-safe and should not be shared. However, some other users of
> commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-389) Use variable argument lists in FileSystemException instead of Object[]s
[
https://issues.apache.org/jira/browse/VFS-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-389:
Summary: Use variable argument lists in FileSystemException instead of
Object[]s (was: Use variable argument list in FileSystemException instead of
Object[])
> Use variable argument lists in FileSystemException instead of Object[]s
> ---
>
> Key: VFS-389
> URL: https://issues.apache.org/jira/browse/VFS-389
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Fix For: Nightly Builds
>
>
> h3. Replace
> {code:java}
> org.apache.commons.vfs2.FileSystemException.FileSystemException(String,
> Object[])
> {code}
> with:
> {code:java}
> org.apache.commons.vfs2.FileSystemException.FileSystemException(String,
> Object...)
> {code}
> This is a binary compatible change.
> h3. Add
> {code:java}
> org.apache.commons.vfs2.FileSystemException.FileSystemException(String,
> Throwable, Object...)
> {code}
> and deprecate:
> {code:java}
> org.apache.commons.vfs2.FileSystemException.FileSystemException(String,
> Object[], Throwable)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-385) Add HTTP status code to HTTP file provider exception messages when available.
[
https://issues.apache.org/jira/browse/VFS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-385:
Summary: Add HTTP status code to HTTP file provider exception messages when
available. (was: Add HTTP status code to exception messages when available.)
> Add HTTP status code to HTTP file provider exception messages when available.
> -
>
> Key: VFS-385
> URL: https://issues.apache.org/jira/browse/VFS-385
> Project: Commons VFS
> Issue Type: Improvement
>Affects Versions: 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
> Fix For: Nightly Builds
>
>
> Enhance the following message patterns with the HTTP status code:
> {noformat}
> vfs.provider.http/get.error=GET method failed for "{0}" with HTTP status {1}.
> vfs.provider.http/head.error=HEAD method failed for "{0}" with HTTP status
> {1}.
> vfs.provider.http/get-range.error=GET method failed for "{0}" range "{1}"
> with HTTP status {2}.
> {noformat}
--
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] (VFS-383) Update JSch to 0.1.45 from 0.1.42 for the SFTP provider.
[ https://issues.apache.org/jira/browse/VFS-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-383: Summary: Update JSch to 0.1.45 from 0.1.42 for the SFTP provider. (was: Update jsch to 0.1.45 from 0.1.42 for the SFTP provider.) > Update JSch to 0.1.45 from 0.1.42 for the SFTP provider. > > > Key: VFS-383 > URL: https://issues.apache.org/jira/browse/VFS-383 > Project: Commons VFS > Issue Type: Task >Affects Versions: 2.0 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: Nightly Builds > > > Update jsch to 0.1.45 from 0.1.42. -- 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] (VFS-383) Update jsch to 0.1.45 from 0.1.42 for the SFTP provider.
[ https://issues.apache.org/jira/browse/VFS-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-383: Summary: Update jsch to 0.1.45 from 0.1.42 for the SFTP provider. (was: Update jsch to 0.1.45 from 0.1.42.) > Update jsch to 0.1.45 from 0.1.42 for the SFTP provider. > > > Key: VFS-383 > URL: https://issues.apache.org/jira/browse/VFS-383 > Project: Commons VFS > Issue Type: Task >Affects Versions: 2.0 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: Nightly Builds > > > Update jsch to 0.1.45 from 0.1.42. -- 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] (VFS-382) SFTP getChildren() does not fail when called on a file
[
https://issues.apache.org/jira/browse/VFS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-382:
Description:
SFTP test testChildren(org.apache.commons.vfs2.test.ContentTests) fails
I've tried this with *Apache SSHd* and *Bitvise WinSSHD* and I get the same
failure.
The test {{org.apache.commons.vfs2.test.ContentTests}} asks for the children
({{getChildren()}}) of a {{file1.txt}} file (not a folder) and does not fail.
The test expects the {{getChildren()}} method to throw an exception.
Instead, it returns one file, file1.txt itself.
Under the covers, we do a "ls file1.txt", which returns "file1.txt".
It looks like [VFS-210] was an effort to optimize and reduce roundtrips but it
may have broken this code.
Thoughts on fixing this?
In
{{org.apache.commons.vfs2.provider.sftp.SftpFileObject.doListChildrenResolved()}}?
was:
I've tried this with *Apache SSHd* and *Bitvise WinSSHD* and I get the same
failure.
The test {{org.apache.commons.vfs2.test.ContentTests}} asks for the children
({{getChildren()}}) of a {{file1.txt}} file (not a folder) and does not fail.
The test expects the {{getChildren()}} method to throw an exception.
Instead, it returns one file, file1.txt itself.
Under the covers, we do a "ls file1.txt", which returns "file1.txt".
It looks like [VFS-210] was an effort to optimize and reduce roundtrips but it
may have broken this code.
Thoughts on fixing this?
In
{{org.apache.commons.vfs2.provider.sftp.SftpFileObject.doListChildrenResolved()}}?
Summary: SFTP getChildren() does not fail when called on a file (was:
SFTP test testChildren(org.apache.commons.vfs2.test.ContentTests) fails)
> SFTP getChildren() does not fail when called on a file
> --
>
> Key: VFS-382
> URL: https://issues.apache.org/jira/browse/VFS-382
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Attachments: vfs-382.diff
>
>
> SFTP test testChildren(org.apache.commons.vfs2.test.ContentTests) fails
> I've tried this with *Apache SSHd* and *Bitvise WinSSHD* and I get the same
> failure.
> The test {{org.apache.commons.vfs2.test.ContentTests}} asks for the children
> ({{getChildren()}}) of a {{file1.txt}} file (not a folder) and does not fail.
> The test expects the {{getChildren()}} method to throw an exception.
> Instead, it returns one file, file1.txt itself.
> Under the covers, we do a "ls file1.txt", which returns "file1.txt".
> It looks like [VFS-210] was an effort to optimize and reduce roundtrips but
> it may have broken this code.
> Thoughts on fixing this?
> In
> {{org.apache.commons.vfs2.provider.sftp.SftpFileObject.doListChildrenResolved()}}?
--
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] (IO-291) Add new function FileUtils.directoryContains
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Summary: Add new function FileUtils.directoryContains (was: Add new function FileUtils.isContained) > Add new function FileUtils.directoryContains > > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Attachments: io-291-simple.diff, io-291-v5.patch > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (VFS-382) SFTP test testChildren(org.apache.commons.vfs2.test.ContentTests) fails
[
https://issues.apache.org/jira/browse/VFS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-382:
Attachment: vfs-382.diff
Patch that shows the problem using Apache SSHd, which removes the need for a
manually configured SSH server.
> SFTP test testChildren(org.apache.commons.vfs2.test.ContentTests) fails
> ---
>
> Key: VFS-382
> URL: https://issues.apache.org/jira/browse/VFS-382
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Attachments: vfs-382.diff
>
>
> I've tried this with *Apache SSHd* and *Bitvise WinSSHD* and I get the same
> failure.
> The test {{org.apache.commons.vfs2.test.ContentTests}} asks for the children
> ({{getChildren()}}) of a {{file1.txt}} file (not a folder) and does not fail.
> The test expects the {{getChildren()}} method to throw an exception.
> Instead, it returns one file, file1.txt itself.
> Under the covers, we do a "ls file1.txt", which returns "file1.txt".
> It looks like [VFS-210] was an effort to optimize and reduce roundtrips but
> it may have broken this code.
> Thoughts on fixing this?
> In
> {{org.apache.commons.vfs2.provider.sftp.SftpFileObject.doListChildrenResolved()}}?
--
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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Fix Version/s: (was: 2.1) > Add new function FileUtils.isContained > -- > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Attachments: io-291-simple.diff, io-291-v5.patch > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: (was: io-291-simple.diff) > Add new function FileUtils.isContained > -- > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Fix For: 2.1 > > Attachments: FileUtils.isContained.patch, io-291-simple.diff, > io-291-v4.patch > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: io-291-simple.diff Let's try again: Attached is a much simpler implementation that works with: Unrealized File objects No recursion. Correct Javadoc No tabs. > Add new function FileUtils.isContained > -- > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Fix For: 2.1 > > Attachments: FileUtils.isContained.patch, io-291-simple.diff, > io-291-v4.patch > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: (was: io-291.diff) > Add new function FileUtils.isContained > -- > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Fix For: 2.1 > > Attachments: FileUtils.isContained.patch, io-291-simple.diff, > io-291-v4.patch > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (VFS-371) Add FileObject API deleteAll()
[
https://issues.apache.org/jira/browse/VFS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-371:
Description:
I see a lot of call sites within VFS 2 and some in my work server that do:
{code:java}
fileObject.delete(Selectors.SELECT_ALL);
{code}
It therefore seems like a sensible refactoring.
Add to {{FileObject}}:
{code:java}
/**
* Deletes all descendents of this file.
* Does nothing if this file does not exist.
* Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
*
* This method is not transactional. If it fails and throws an
* exception, this file will potentially only be partially deleted.
*
* @return the number of deleted objects
* @throws FileSystemException If this file or one of its descendents is
read-only, or on error
* deleting this file or one of its descendents.
*/
int deleteAll() throws FileSystemException;
{code}
And to {{AbstractFileObject}}:
{code:java}
/**
* Deletes this file, and all children.
*
* @return the number of deleted files.
* @throws FileSystemException if an error occurs.
*/
public int deleteAllDescendents() throws FileSystemException
{
return this.delete(Selectors.SELECT_ALL);
}
{code}
Thoughts?
Attaching patch.
was:
I see a lot of call sites within VFS 2 and some in my work server that do:
{code:java}
fileObject.delete(Selectors.SELECT_ALL);
{code}
It therefore seems like a sensible refactoring.
Add to {{FileObject}}:
{code:java}
/**
* Deletes all descendents of this file.
* Does nothing if this file does not exist.
* Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
*
* This method is not transactional. If it fails and throws an
* exception, this file will potentially only be partially deleted.
*
* @return the number of deleted objects
* @throws FileSystemException If this file or one of its descendents is
read-only, or on error
* deleting this file or one of its descendents.
*/
int deleteAllDescendents() throws FileSystemException;
{code}
And to {{AbstractFileObject}}:
{code:java}
/**
* Deletes this file, and all children.
*
* @return the number of deleted files.
* @throws FileSystemException if an error occurs.
*/
public int deleteAllDescendents() throws FileSystemException
{
return this.delete(Selectors.SELECT_ALL);
}
{code}
Thoughts?
Attaching patch.
> Add FileObject API deleteAll()
> --
>
> Key: VFS-371
> URL: https://issues.apache.org/jira/browse/VFS-371
> Project: Commons VFS
> Issue Type: New Feature
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Fix For: 2.1
>
> Attachments: FileObject-deleteAllDescendents.diff
>
>
> I see a lot of call sites within VFS 2 and some in my work server that do:
> {code:java}
> fileObject.delete(Selectors.SELECT_ALL);
> {code}
> It therefore seems like a sensible refactoring.
> Add to {{FileObject}}:
> {code:java}
> /**
> * Deletes all descendents of this file.
> * Does nothing if this file does not exist.
> * Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
> *
> * This method is not transactional. If it fails and throws an
> * exception, this file will potentially only be partially deleted.
> *
> * @return the number of deleted objects
> * @throws FileSystemException If this file or one of its descendents is
> read-only, or on error
> * deleting this file or one of its
> descendents.
> */
> int deleteAll() throws FileSystemException;
> {code}
> And to {{AbstractFileObject}}:
> {code:java}
> /**
> * Deletes this file, and all children.
> *
> * @return the number of deleted files.
> * @throws FileSystemException if an error occurs.
> */
> public int deleteAllDescendents() throws FileSystemException
> {
> return this.delete(Selectors.SELECT_ALL);
> }
> {code}
> Thoughts?
> Attaching patch.
--
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] (VFS-371) Add FileObject API deleteAll()
[
https://issues.apache.org/jira/browse/VFS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-371:
Summary: Add FileObject API deleteAll() (was: Add FileObject API
deleteAllDescendents())
> Add FileObject API deleteAll()
> --
>
> Key: VFS-371
> URL: https://issues.apache.org/jira/browse/VFS-371
> Project: Commons VFS
> Issue Type: New Feature
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Fix For: 2.1
>
> Attachments: FileObject-deleteAllDescendents.diff
>
>
> I see a lot of call sites within VFS 2 and some in my work server that do:
> {code:java}
> fileObject.delete(Selectors.SELECT_ALL);
> {code}
> It therefore seems like a sensible refactoring.
> Add to {{FileObject}}:
> {code:java}
> /**
> * Deletes all descendents of this file.
> * Does nothing if this file does not exist.
> * Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
> *
> * This method is not transactional. If it fails and throws an
> * exception, this file will potentially only be partially deleted.
> *
> * @return the number of deleted objects
> * @throws FileSystemException If this file or one of its descendents is
> read-only, or on error
> * deleting this file or one of its
> descendents.
> */
> int deleteAllDescendents() throws FileSystemException;
> {code}
> And to {{AbstractFileObject}}:
> {code:java}
> /**
> * Deletes this file, and all children.
> *
> * @return the number of deleted files.
> * @throws FileSystemException if an error occurs.
> */
> public int deleteAllDescendents() throws FileSystemException
> {
> return this.delete(Selectors.SELECT_ALL);
> }
> {code}
> Thoughts?
> Attaching patch.
--
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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: (was: io-291-simple.diff) > Add new function FileUtils.isContained > -- > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Fix For: 2.1 > > Attachments: FileUtils.isContained.patch, io-291-simple.diff, > io-291.diff > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: io-291-simple.diff Attached is a much simpler implementation that works with: - Unrealized File objects - No recursion. - Correct Javadoc - No tabs. > Add new function FileUtils.isContained > -- > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Fix For: 2.1 > > Attachments: FileUtils.isContained.patch, io-291-simple.diff, > io-291.diff > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: io-291-simple.diff Attached is a much simpler implementation that works with: - Unrealized File objects - No recursion. - Correct Javadoc > Add new function FileUtils.isContained > -- > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Fix For: 2.1 > > Attachments: FileUtils.isContained.patch, io-291-simple.diff, > io-291.diff > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: (was: io-291-simple.diff) > Add new function FileUtils.isContained > -- > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Fix For: 2.1 > > Attachments: FileUtils.isContained.patch, io-291.diff > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: io-291-simple.diff Attached is a much simpler implementation that works with: - Unrealized File objects - No recursion. > Add new function FileUtils.isContained > -- > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Fix For: 2.1 > > Attachments: FileUtils.isContained.patch, io-291-simple.diff, > io-291.diff > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- 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] (IO-291) Add new function FileUtils.isContained
[
https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-291:
---
Attachment: io-291.diff
Attaching my version of the patch with discussed changes. What is not clear to
me is if this is the best choice:
{code:java}
public void testUnrealizedContainment() throws IOException {
final File dir = new File("DOESNOTEXIST");
final File file = new File(dir, "DOESNOTEXIST2");
assertFalse(dir.exists());
assertFalse(file.exists());
assertFalse(FileUtils.contains(dir, file));
}
{code}
as opposed to:
{code:java}
assertFalse(FileUtils.contains(dir, file));
{code}
The relationship in b/w parent and child is valid but unrealized on disk.
Shouldn't contain value the relationship as valid even if unrealized? I am
inclined to say yes.
Thoughts?
> Add new function FileUtils.isContained
> --
>
> Key: IO-291
> URL: https://issues.apache.org/jira/browse/IO-291
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Affects Versions: 2.1
>Reporter: Pier-Luc Caron St-Pierre
>Assignee: Gary D. Gregory
> Labels: patch
> Fix For: 2.1
>
> Attachments: FileUtils.isContained.patch, io-291.diff
>
>
> I added a function that determines whether the specified leaf is contains by
> the specified composite.
--
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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: Daemon-219.zip Using --StopClass still causes a 1067 error. > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Mladen Turk > Fix For: 1.0.8 > > Attachments: Daemon-219.zip, Daemon-219.zip, Daemon-219.zip, > LdeServer3.reg, NoKey.PNG, SystemLdeService3.txt, > WER8D3F.tmp.WERInternalMetadata.xml, WERA3BC.tmp.appcompat.txt, > WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, install-lde-service.cmd, > ldeservice3-stderr.2011-10-03.log, ldeservice3-stdout.2011-10-03.log, > register.cmd, unregister.cmd > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: Daemon-219.zip New version of the test zip which is a little cleaner and generates procrun logs in a logs folder in the project (included). > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Mladen Turk > Attachments: Daemon-219.zip, Daemon-219.zip, LdeServer3.reg, > NoKey.PNG, SystemLdeService3.txt, WER8D3F.tmp.WERInternalMetadata.xml, > WERA3BC.tmp.appcompat.txt, WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, > install-lde-service.cmd, ldeservice3-stderr.2011-10-03.log, > ldeservice3-stdout.2011-10-03.log, register.cmd, unregister.cmd > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: Daemon-219.zip Reproduces the issue. See readme.txt in the ZIP for instructions. > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Mladen Turk > Attachments: Daemon-219.zip, LdeServer3.reg, NoKey.PNG, > SystemLdeService3.txt, WER8D3F.tmp.WERInternalMetadata.xml, > WERA3BC.tmp.appcompat.txt, WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, > install-lde-service.cmd, ldeservice3-stderr.2011-10-03.log, > ldeservice3-stdout.2011-10-03.log, register.cmd, unregister.cmd > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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] (COLLECTIONS-386) CollectionUtils.removeAll(Collection, Collection) has an CopyPaste-Failure
[
https://issues.apache.org/jira/browse/COLLECTIONS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated COLLECTIONS-386:
Affects Version/s: 3.2.1
Fix Version/s: Nightly Builds
> CollectionUtils.removeAll(Collection, Collection) has an CopyPaste-Failure
> --
>
> Key: COLLECTIONS-386
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-386
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.2.1
> Environment: commons-collections-3.2.1.jar
>Reporter: Steininger Thomas
>Priority: Critical
> Fix For: Nightly Builds
>
>
> public static Collection removeAll(Collection collection, Collection remove) {
> return ListUtils.retainAll(collection, remove);
> }
--
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] (VFS-380) FTP connect.error message used instead of SFTP connect.error message
[
https://issues.apache.org/jira/browse/VFS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-380:
Summary: FTP connect.error message used instead of SFTP connect.error
message (was: FTP messages used instead of SFTP messages )
> FTP connect.error message used instead of SFTP connect.error message
>
>
> Key: VFS-380
> URL: https://issues.apache.org/jira/browse/VFS-380
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
> Fix For: Nightly Builds
>
>
> If connecting to SFTP fails, the code uses the message key
> {{vfs.provider.ftp/connect.error}} but the resource file defines the SFTP
> specific message {{vfs.provider.sftp/connect.error}}
--
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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: unregister.cmd register.cmd LdeServer3.reg Regedit export and cmd files. > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Mladen Turk > Attachments: LdeServer3.reg, NoKey.PNG, SystemLdeService3.txt, > WER8D3F.tmp.WERInternalMetadata.xml, WERA3BC.tmp.appcompat.txt, > WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, install-lde-service.cmd, > ldeservice3-stderr.2011-10-03.log, ldeservice3-stdout.2011-10-03.log, > register.cmd, unregister.cmd > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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] (VFS-378) Tar error message are missing from resource file
[
https://issues.apache.org/jira/browse/VFS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-378:
Description:
Right you get:
{noformat}
"Unknown message with code "vfs.provider.tar/open-tar-file.error"."
{noformat}
Instead of:
{noformat}
"Could not open Tar file "C:\some\path\to\a\file".".
{noformat}
The following are missing from
{{core/bin/org/apache/commons/vfs2/Resources.properties}}:
{noformat}
vfs.provider.tar/open-tar-file.error=Could not open Tar file "{0}".
vfs.provider.tar/close-tar-file.error=Could not close Tar file "{0}".
{noformat}
was:
The following are missing from
{{core/bin/org/apache/commons/vfs2/Resources.properties}}:
vfs.provider.tar/open-tar-file.error=Could not open Tar file "{0}".
vfs.provider.tar/close-tar-file.error=Could not close Tar file "{0}".
> Tar error message are missing from resource file
>
>
> Key: VFS-378
> URL: https://issues.apache.org/jira/browse/VFS-378
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
> Fix For: Nightly Builds
>
>
> Right you get:
> {noformat}
> "Unknown message with code "vfs.provider.tar/open-tar-file.error"."
> {noformat}
> Instead of:
> {noformat}
> "Could not open Tar file "C:\some\path\to\a\file".".
> {noformat}
> The following are missing from
> {{core/bin/org/apache/commons/vfs2/Resources.properties}}:
> {noformat}
> vfs.provider.tar/open-tar-file.error=Could not open Tar file "{0}".
> vfs.provider.tar/close-tar-file.error=Could not close Tar file "{0}".
> {noformat}
--
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] (VFS-375) Upgrade to Apache Commons Compress 1.3 from 1.2.
[ https://issues.apache.org/jira/browse/VFS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-375: Description: Upgrade to Apache Commons Compress 1.3 from 1.2. In 2.0, only the tests use ACC. was:Upgrade to Apache Commons Compress 1.3 from 1.2. > Upgrade to Apache Commons Compress 1.3 from 1.2. > > > Key: VFS-375 > URL: https://issues.apache.org/jira/browse/VFS-375 > Project: Commons VFS > Issue Type: Task >Affects Versions: 2.0 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: Nightly Builds > > > Upgrade to Apache Commons Compress 1.3 from 1.2. > In 2.0, only the tests use ACC. -- 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] (VFS-371) Add FileObject API deleteAllDescendents()
[
https://issues.apache.org/jira/browse/VFS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-371:
Attachment: FileObject-deleteAllDescendents.diff
Patch with tests.
> Add FileObject API deleteAllDescendents()
> -
>
> Key: VFS-371
> URL: https://issues.apache.org/jira/browse/VFS-371
> Project: Commons VFS
> Issue Type: New Feature
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Fix For: 2.1
>
> Attachments: FileObject-deleteAllDescendents.diff
>
>
> I see a lot of call sites within VFS 2 and some in my work server that do:
> {code:java}
> fileObject.delete(Selectors.SELECT_ALL);
> {code}
> It therefore seems like a sensible refactoring.
> Add to {{FileObject}}:
> {code:java}
> /**
> * Deletes all descendents of this file.
> * Does nothing if this file does not exist.
> * Shorthand for {@code delete(Selectors.Selectors.SELECT_ALL)}
> *
> * This method is not transactional. If it fails and throws an
> * exception, this file will potentially only be partially deleted.
> *
> * @return the number of deleted objects
> * @throws FileSystemException If this file or one of its descendents is
> read-only, or on error
> * deleting this file or one of its
> descendents.
> */
> int deleteAllDescendents() throws FileSystemException;
> {code}
> And to {{AbstractFileObject}}:
> {code:java}
> /**
> * Deletes this file, and all children.
> *
> * @return the number of deleted files.
> * @throws FileSystemException if an error occurs.
> */
> public int deleteAllDescendents() throws FileSystemException
> {
> return this.delete(Selectors.SELECT_ALL);
> }
> {code}
> Thoughts?
> Attaching patch.
--
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] (POOL-191) ConcurrentModificationException in GenericObjectPool LinkedList
[
https://issues.apache.org/jira/browse/POOL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated POOL-191:
-
Description:
It is possible to get a {{ConcurrentModificationException}} in a {{LinkedList}}
from a {{GenericObjectPool}}.
This happens when I call {{ReflectionToStringBuilder.toString(this)}} from a
subclass of {{GenericObjectPool}}. My guess is that it would happen with just
{{ReflectionToStringBuilder.toString(gop)}}. IOW, subclassing does not have
anything to do with it I would venture.
For example, in this stack trace {{JmsSessionPool}} is a subclass of
{{GenericObjectPool}}.
{noformat}
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
at java.util.LinkedList$ListItr.next(LinkedList.java:696)
at java.util.AbstractCollection.toString(AbstractCollection.java:421)
at java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuffer.append(StringBuffer.java:219)
at
org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:598)
at
org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:473)
at org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436)
at
org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:692)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119)
at
com.seagullsw.appinterface.comm.jms.JmsSessionPool.toString(JmsSessionPool.java:120)
at java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuffer.append(StringBuffer.java:219)
at
org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:586)
at
org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:550)
at org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436)
at
org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:689)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119)
at
com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:828)
at
com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:817)
at java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
com.seagullsw.appinterface.server.AisHelper.waitForCommuncationManagers(AisHelper.java:217)
at com.seagullsw.appinterface.server.AisHelper.start(AisHelper.java:136)
at
com.seagullsw.appinterface.server.AisHelper.startFromResource(AisHelper.java:161)
at
com.seagullsw.appinterface.server.AbstractServerJunit4.startServer(AbstractServerJunit4.java:179)
at
com.seagullsw.appinterface.server.comm.jms.AbstractJmsRoundtripMaxConcurrencyTestCase.setUpOnce(AbstractJmsRoundtripMaxConcurrencyTestCase.java:141)
at
com.seagullsw.appinterface.server.comm.jms.ibmmq.JmsRoundtripMaxConcurrency032TestCase.setUpOnce(JmsRoundtripMaxConcurrency032TestCase.java:40)
{noformat}
was:
{noformat}
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
at java.util.LinkedList$ListItr.next(LinkedList.java:696)
at java.util.AbstractCollection.toString(AbstractCollection.java:421)
at java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuffer.append(StringBuffer.java:219)
at
org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:598)
at
org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:473)
at org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436)
at
org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:692)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288)
at
org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119)
at
com.seagullsw.appinterface.comm.jm
[jira] [Updated] (VFS-367) Add APIs FileObject isFile(), FileObject isFolder(), and FileName isFile()
[
https://issues.apache.org/jira/browse/VFS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-367:
Description:
As a call site, I want to say {{fileObject.isFile()}}, not
{{FileType.FILE.equals(fileObject.getType())}} or {{fileObject.getType() ==
FileType.FILE}}
It turns out this {{equals()/==}} pattern is repeated internally quit a bit.
Refactor that to use the new API.
Same idea for FileName isFile (but there are fewer call sites to refactor.)
was:
As a call site, I want to say {{fileObject.isFile()}}, not
{{FileType.FILE.equals(fileObject.getType())}}
It turns out this {{equals()}} pattern is repeated internally quit a bit with
both equals, and ==. I'll refactor that to use the new API.
Same idea for FileName (but there are fewer call sites to refactor.)
Summary: Add APIs FileObject isFile(), FileObject isFolder(), and
FileName isFile() (was: Add API FileObject and FileName isFile())
> Add APIs FileObject isFile(), FileObject isFolder(), and FileName isFile()
> --
>
> Key: VFS-367
> URL: https://issues.apache.org/jira/browse/VFS-367
> Project: Commons VFS
> Issue Type: Improvement
>Affects Versions: 1.0, 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
> Fix For: 2.1
>
>
> As a call site, I want to say {{fileObject.isFile()}}, not
> {{FileType.FILE.equals(fileObject.getType())}} or {{fileObject.getType() ==
> FileType.FILE}}
> It turns out this {{equals()/==}} pattern is repeated internally quit a bit.
> Refactor that to use the new API.
> Same idea for FileName isFile (but there are fewer call sites to refactor.)
--
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] (VFS-367) Add API FileObject and FileName isFile()
[
https://issues.apache.org/jira/browse/VFS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-367:
Description:
As a call site, I want to say {{fileObject.isFile()}}, not
{{FileType.FILE.equals(fileObject.getType())}}
It turns out this {{equals()}} pattern is repeated internally quit a bit with
both equals, and ==. I'll refactor that to use the new API.
Same idea for FileName (but there are fewer call sites to refactor.)
was:
As a call site, I want to say {{fileObject.isFile()}}, not
{{FileType.FILE.equals(fileObject.getType())}}
It turns out this {{equals()}} pattern is repeated internally quit a bit with
both equals, and ==. I'll refactor that to use the new API.
Summary: Add API FileObject and FileName isFile() (was: Add API
FileObject isFile())
> Add API FileObject and FileName isFile()
>
>
> Key: VFS-367
> URL: https://issues.apache.org/jira/browse/VFS-367
> Project: Commons VFS
> Issue Type: Improvement
>Affects Versions: 1.0, 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
> Fix For: 2.1
>
>
> As a call site, I want to say {{fileObject.isFile()}}, not
> {{FileType.FILE.equals(fileObject.getType())}}
> It turns out this {{equals()}} pattern is repeated internally quit a bit with
> both equals, and ==. I'll refactor that to use the new API.
> Same idea for FileName (but there are fewer call sites to refactor.)
--
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] (VFS-367) Add API FileObject and FileName isFile()
[
https://issues.apache.org/jira/browse/VFS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated VFS-367:
Fix Version/s: 2.1
> Add API FileObject and FileName isFile()
>
>
> Key: VFS-367
> URL: https://issues.apache.org/jira/browse/VFS-367
> Project: Commons VFS
> Issue Type: Improvement
>Affects Versions: 1.0, 2.0
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
> Fix For: 2.1
>
>
> As a call site, I want to say {{fileObject.isFile()}}, not
> {{FileType.FILE.equals(fileObject.getType())}}
> It turns out this {{equals()}} pattern is repeated internally quit a bit with
> both equals, and ==. I'll refactor that to use the new API.
> Same idea for FileName (but there are fewer call sites to refactor.)
--
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] (IO-280) Dubious use of mkdirs() return code
[
https://issues.apache.org/jira/browse/IO-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-280:
---
Fix Version/s: 2.1
> Dubious use of mkdirs() return code
> ---
>
> Key: IO-280
> URL: https://issues.apache.org/jira/browse/IO-280
> Project: Commons IO
> Issue Type: Bug
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.1
>
>
> FileUtils.openOutputStream() has the following code:
> {code}
> File parent = file.getParentFile();
> if (parent != null && parent.exists() == false) {
> if (parent.mkdirs() == false) {
> throw new IOException("File '" + file + "' could not be created");
> }
> }
> {code}
> Now mkdirs() returns true only if the method actually created the
> directories; it's theoretically possible for the directory to be created in
> the window between the exists() and mkdirs() invocations. [Indeed the class
> actually checks for this in the forceMkdir() method]
> It would be safer to use:
> {code}
> File parent = file.getParentFile();
> if (parent != null && !parent.mkdirs() && !parent.isDirectory()) {
> throw new IOException("Directory '" + parent + "' could not be
> created"); // note changed text
> }
> }
> {code}
> Similarly elsewhere in the class where mkdirs() is used.
--
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] (IO-274) Tailer returning partial lines when reaching EOF before EOL
[ https://issues.apache.org/jira/browse/IO-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-274: --- Fix Version/s: 2.1 > Tailer returning partial lines when reaching EOF before EOL > --- > > Key: IO-274 > URL: https://issues.apache.org/jira/browse/IO-274 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Frank Grimes > Fix For: 2.1 > > Attachments: TailerTest.patch > > > As reported here: > http://mail-archives.apache.org/mod_mbox/commons-user/201105.mbox/%3cbanlktim6ha-xgjn8ca6ffcpkva6ax6k...@mail.gmail.com%3e -- 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] (IO-226) Rounding issue with byteCountToDisplaySize(long size)
[ https://issues.apache.org/jira/browse/IO-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-226: --- Summary: Rounding issue with byteCountToDisplaySize(long size) (was: question with byteCountToDisplaySize(long size)) > Rounding issue with byteCountToDisplaySize(long size) > - > > Key: IO-226 > URL: https://issues.apache.org/jira/browse/IO-226 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: shu kai yuan > Fix For: 2.0 > > > I do not understand the byteCountToDisplaySize(long size) method which is in > class FileUtils of the package org.apache.commons.io. > If the parameter size is 2047 , the method will return 1 KB.Why it will lose > precision. > I read the code. > Maybe it is a bug? -- 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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: SystemLdeService3.txt > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Attachments: NoKey.PNG, SystemLdeService3.txt, > WER8D3F.tmp.WERInternalMetadata.xml, WERA3BC.tmp.appcompat.txt, > WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, install-lde-service.cmd, > ldeservice3-stderr.2011-10-03.log, ldeservice3-stdout.2011-10-03.log > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: (was: CurrentControlSet.reg) > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Attachments: NoKey.PNG, SystemLdeService3.txt, > WER8D3F.tmp.WERInternalMetadata.xml, WERA3BC.tmp.appcompat.txt, > WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, install-lde-service.cmd, > ldeservice3-stderr.2011-10-03.log, ldeservice3-stdout.2011-10-03.log > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: NoKey.PNG CurrentControlSet.reg > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Attachments: CurrentControlSet.reg, NoKey.PNG, > WER8D3F.tmp.WERInternalMetadata.xml, WERA3BC.tmp.appcompat.txt, > WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, install-lde-service.cmd, > ldeservice3-stderr.2011-10-03.log, ldeservice3-stdout.2011-10-03.log > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: install-lde-service.cmd > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Attachments: WER8D3F.tmp.WERInternalMetadata.xml, > WERA3BC.tmp.appcompat.txt, WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, > install-lde-service.cmd, ldeservice3-stderr.2011-10-03.log, > ldeservice3-stdout.2011-10-03.log > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: (was: install-lde-service.cmd) > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Attachments: WER8D3F.tmp.WERInternalMetadata.xml, > WERA3BC.tmp.appcompat.txt, WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, > install-lde-service.cmd, ldeservice3-stderr.2011-10-03.log, > ldeservice3-stdout.2011-10-03.log > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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] (DAEMON-219) prunsrv error 1067 and crash on Windows 7
[ https://issues.apache.org/jira/browse/DAEMON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DAEMON-219: --- Attachment: install-lde-service.cmd ldeservice3-stdout.2011-10-03.log ldeservice3-stderr.2011-10-03.log commons-daemon.2011-10-03.log WERA3BD.tmp.mdmp WERA3BC.tmp.appcompat.txt WER8D3F.tmp.WERInternalMetadata.xml > prunsrv error 1067 and crash on Windows 7 > - > > Key: DAEMON-219 > URL: https://issues.apache.org/jira/browse/DAEMON-219 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Attachments: WER8D3F.tmp.WERInternalMetadata.xml, > WERA3BC.tmp.appcompat.txt, WERA3BD.tmp.mdmp, commons-daemon.2011-10-03.log, > install-lde-service.cmd, ldeservice3-stderr.2011-10-03.log, > ldeservice3-stdout.2011-10-03.log > > > I've defined attached cmd file on Windows 7 to install a service. > I try to run the service with "prunsrv //TS/LdeService3" and I get "Commons > Daemon Service Runner has stopped working" > Attaching all details. > Is there more debug logging I can turn on? The current debug output seems > minimal. > This is probably a configuration user error but I cannot tell due to the lack > of logging. > Thank you. -- 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
