[jira] [Commented] (VFS-296) [FTP] Socket timeout setting doesn't work if connect hangs
[ https://issues.apache.org/jira/browse/VFS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610894#comment-14610894 ] Bernd Eckenfels commented on VFS-296: - As of the ASF bylaws we make nightly builds not officially available, but if you check out the staged (future) site of commons-vfs on http://people.apache.org/~ecki/commons-vfs/integration.html you can find the integration server. It contains a trunk build (w/o sandbox). I would recommend to build it yourself, it just needs maven and JDK 7. [FTP] Socket timeout setting doesn't work if connect hangs -- Key: VFS-296 URL: https://issues.apache.org/jira/browse/VFS-296 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Reporter: Andreas Persson Fix For: 2.1 Attachments: sotimeout.patch, sotimeout_v2.patch The fix from VFS-216 doesn't help if the ftp server doesn't reply with any messages at all (could happen if it's behind a badly configured firewall for example). What happens is that the client.connect() called from FtpClientFactory hangs, and this line is before timeout parameter is set. I suggest the change in the attached patch. The scenario can be tested with netcat -l instead of a real ftp server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-296) [FTP] Socket timeout setting doesn't work if connect hangs
[ https://issues.apache.org/jira/browse/VFS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610897#comment-14610897 ] Bernd Eckenfels commented on VFS-296: - It is not a question of a blocker bug, it is a question of time for all the other todos. [FTP] Socket timeout setting doesn't work if connect hangs -- Key: VFS-296 URL: https://issues.apache.org/jira/browse/VFS-296 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Reporter: Andreas Persson Fix For: 2.1 Attachments: sotimeout.patch, sotimeout_v2.patch The fix from VFS-216 doesn't help if the ftp server doesn't reply with any messages at all (could happen if it's behind a badly configured firewall for example). What happens is that the client.connect() called from FtpClientFactory hangs, and this line is before timeout parameter is set. I suggest the change in the attached patch. The scenario can be tested with netcat -l instead of a real ftp server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-570) Write Ability for HDFS Provider
[ https://issues.apache.org/jira/browse/VFS-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610933#comment-14610933 ] Dave Marion commented on VFS-570: - Just had time for a quick glance. Is there a reason that you are not checking the boolean return values for the .delete(), .setTimes(), .rename(), and other calls and throwing an exception when false is returned? Write Ability for HDFS Provider --- Key: VFS-570 URL: https://issues.apache.org/jira/browse/VFS-570 Project: Commons VFS Issue Type: New Feature Reporter: Aron Lurie Attachments: 6-26-15-vfs-hdfs.patch, 6-3-15-vfs-hdfs.patch, 6-4-15-vfs-hdfs.patch Currently, the HDFS Provider only supports reading of files. Write ability should be added to facilitate broader uses of VFS with respect to HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-570) Write Ability for HDFS Provider
[ https://issues.apache.org/jira/browse/VFS-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610943#comment-14610943 ] Aron Lurie commented on VFS-570: No reason. I will add that improvement and post a new patch. Write Ability for HDFS Provider --- Key: VFS-570 URL: https://issues.apache.org/jira/browse/VFS-570 Project: Commons VFS Issue Type: New Feature Reporter: Aron Lurie Attachments: 6-26-15-vfs-hdfs.patch, 6-3-15-vfs-hdfs.patch, 6-4-15-vfs-hdfs.patch Currently, the HDFS Provider only supports reading of files. Write ability should be added to facilitate broader uses of VFS with respect to HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-570) Write Ability for HDFS Provider
[ https://issues.apache.org/jira/browse/VFS-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610927#comment-14610927 ] Dave Marion commented on VFS-570: - I believe I updated to Hadoop 2.6.0 in VFS-530. 2.7.0 is the latest, but I believe it's unstable and not ready for production. That's what I remember seeing on their mailing list anyway. Write Ability for HDFS Provider --- Key: VFS-570 URL: https://issues.apache.org/jira/browse/VFS-570 Project: Commons VFS Issue Type: New Feature Reporter: Aron Lurie Attachments: 6-26-15-vfs-hdfs.patch, 6-3-15-vfs-hdfs.patch, 6-4-15-vfs-hdfs.patch Currently, the HDFS Provider only supports reading of files. Write ability should be added to facilitate broader uses of VFS with respect to HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-296) [FTP] Socket timeout setting doesn't work if connect hangs
[ https://issues.apache.org/jira/browse/VFS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611160#comment-14611160 ] Sebb commented on VFS-296: -- Or you can use builds from the ASF SNAPSHOT repository. Most Commons components are regularly built on CI servers and the jars are normally uploaded to the snapshot repo. Such builds are not subject to review or QA and are used at the developer's risk; they should never be used in production code. However developers are welcome to use them to help solve bugs. Note that the snapshot builds are not stable, as they will be superseded whenever there is a new CI build. [FTP] Socket timeout setting doesn't work if connect hangs -- Key: VFS-296 URL: https://issues.apache.org/jira/browse/VFS-296 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Reporter: Andreas Persson Fix For: 2.1 Attachments: sotimeout.patch, sotimeout_v2.patch The fix from VFS-216 doesn't help if the ftp server doesn't reply with any messages at all (could happen if it's behind a badly configured firewall for example). What happens is that the client.connect() called from FtpClientFactory hangs, and this line is before timeout parameter is set. I suggest the change in the attached patch. The scenario can be tested with netcat -l instead of a real ftp server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-443) Need an easy way to convert from a FileObject to a File
[
https://issues.apache.org/jira/browse/VFS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611158#comment-14611158
]
Bernd Eckenfels commented on VFS-443:
-
I think it is good to reduce the exposure of provider classes/packages. All
access should be done through the main api packages (which needs to be
defined:) Otherwise it would be really hard to gurante compatibility.
We already have a `FileSystemManager#toFileObject(File)` so we can add a
FileSystemManager#toFile(FileObject)` as well?
Need an easy way to convert from a FileObject to a File
---
Key: VFS-443
URL: https://issues.apache.org/jira/browse/VFS-443
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Nicholas Allen
Assignee: Gary Gregory
I've seen the reasons why Apache does not want to provide an easy way to
convert from a FileObject to a java.io.File and those reasons make sense -
however, I think that some things are being overlooked and there are still
valid reasons for needing to convert from a FileObject to a File.
Firstly, I would like to always use Apache VFS for everything I do - even if
I know it's only on the local file system. The reasons for this are:
1. it makes the code more flexible (it might start of being local file system
and then as specs change it could become a requirement to work over http or
inside zip files for example).
2. The API is nicer to use than the java.io.File and it's easier to write
cross platform code using it (file separator is always / etc).
So if I work with Apache VFS for local file system use I would like to be
able to get back to a java.io.File in case I need to interface with same
other library. I would like a method that converted to a File or null if not
possible. This would allow me to take an alternate action (eg copy file to
local temp file if it's not already a local file). There's no need to copy
the file if it is already local.
The simplest fix for this is to just make the getLocalFile() method in
LocalFile public. Once the user knows it's a LocalFile object it makes sense
to call this method to obtain the java.io.File. So I could write a method
like this:
{code:title=FileUtilities.java}
/**
* If the supplied {@link FileObject} represents a local file then this
returns that, otherwise
* returns null.
*/
public File getLocalFile(final FileObject fileObject)
{
if (fileObject instanceof LocalFile)
{
final LocalFile localFile = (LocalFile)fileObject;
return localFile.getLocalFile();
}
return null;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VFS-296) [FTP] Socket timeout setting doesn't work if connect hangs
[ https://issues.apache.org/jira/browse/VFS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609647#comment-14609647 ] Philipp Brügger commented on VFS-296: - Hi Bernd, so the only blocking ticket to release 2.1 is the VFS-498 ? Please let us know how we can help you releasing finally a next version? We are all waiting for this release!!! [FTP] Socket timeout setting doesn't work if connect hangs -- Key: VFS-296 URL: https://issues.apache.org/jira/browse/VFS-296 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Reporter: Andreas Persson Fix For: 2.1 Attachments: sotimeout.patch, sotimeout_v2.patch The fix from VFS-216 doesn't help if the ftp server doesn't reply with any messages at all (could happen if it's behind a badly configured firewall for example). What happens is that the client.connect() called from FtpClientFactory hangs, and this line is before timeout parameter is set. I suggest the change in the attached patch. The scenario can be tested with netcat -l instead of a real ftp server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang pull request: Changes in Capitalize methods in WordUt...
GitHub user kaching88 opened a pull request: https://github.com/apache/commons-lang/pull/102 Changes in Capitalize methods in WordUtils class. This commit do some refactorization and improvements in Capitalization section methods. I removed overloaded methods with null parameter and add some code to prevent duplications in delimeters parameters. Commit passes all tests. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kaching88/commons-lang master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/102.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #102 commit c609964190bec29e83512a1dc93fe6811d802927 Author: kaching88 wa...@o2.pl Date: 2015-07-02T00:55:25Z Changes in Capitalize methods in WordUtils class. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
