[jira] Commented: (NET-163) [contribution] DNS utils
[ https://issues.apache.org/jira/browse/NET-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513392 ] Rory Winston commented on NET-163: -- Hey Nikolay Thank you for the contribution. Does this require JDK 6? [contribution] DNS utils Key: NET-163 URL: https://issues.apache.org/jira/browse/NET-163 Project: Commons Net Issue Type: New Feature Reporter: Nikolay Chugunov Attachments: dnsutils.zip Hi all, I developed DNS methods for resolving IP address by host name and vice verse; receiving mail exchange and authoritative name servers for domain; and receiving other information about domain from DNS server. JDK provides above functionality in JNDI DNS service provider [1]. But JNDI technology is too abstract and obfuscates communication with DNS servers, which leads to users don't use JNDI DNS SP. Attached classes provide evident API for receiving information from DNS server as wrapper for JNDI DNS SP. Also these classes provide necessary additional parsing of answers. Examples how to use created API can be found in DNSClientTest unit test. This library requires only JDK and JUnit to run the test. [1] http://java.sun.com/javase/6/docs/technotes/guides/jndi/jndi-dns.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MATH-167) ConvergenceException in normal CDF
I think (2) may be simplest and best I dont really think that throwing an exception here is appropriate at all. It mat be possible however, to determine the resolution as you suggest in (1). I'm not sure what packages like R do internally currently. pnorm(-100) [1] 0 pnorm(100) [1] 1 Rory Phil Steitz (JIRA) wrote: [ https://issues.apache.org/jira/browse/MATH-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510905 ] Phil Steitz commented on MATH-167: -- Thanks for reporting this. I see three alternatives to address - appreciate comments. 1) Determine tail resolution possible with current impl (hopefully not different on different JDKs, platforms) and top code, checking arguments and returning 0 or 1, resp if argument is too far in SD units from the mean. To find the cut points, empirically determine where convergence starts to fail. Document the cut points in javadoc for Impl. 2) Catch ConvergenceException and return 0 or 1, resp if argument is far from the mean; rethrow otherwise (though this should never happen). 3) Resolve as WONTFIX and leave it to client to catch and handle ConvergenceException, examining argument. Document algorithm more fully and warn that ConvergenceException will be thrown if tail probability cannot be accurately estimated or distinguished from 0. My first thought was 2 and I guess I still favor that, since 3) is inconvenient for users and 1) may not be stable unless cut points are conservative. Note that this same problem may apply to tail probablilities of other continuous distributions and we should check and address all of these before resolving this issue. ConvergenceException in normal CDF -- Key: MATH-167 URL: https://issues.apache.org/jira/browse/MATH-167 Project: Commons Math Issue Type: Bug Reporter: Mikko Kauppila Priority: Minor NormalDistributionImpl::cumulativeProbability(double x) throws ConvergenceException if x deviates too much from the mean. For example, when x=+/-100, mean=0, sd=1. Of course the value of the CDF is hard to evaluate in these cases, but effectively it should be either zero or one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need to delete message in Archive
No. Why would you want to do that anyway? Rory Askar Zaidi wrote: Hi, A few weeks ago I posted an email to Commons developer list. This message appears on Google listing while searching for a word. Is there a way I could delete this email from archives so that it does not appear on the Google listings ? thanks, Askar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Rahul Akolkar to join the Apache Commons PMC
+1 for sure. Rory Oliver Heger wrote: Niall Pemberton wrote: [X] +1, don't let Rahul get away - lets try to get him to join the new PMC [ ] -1, no leave him out Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: centralized KEYS file?
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-160) FTP Client API Hangs - Attached Scenario.
[
https://issues.apache.org/jira/browse/NET-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503293
]
Rory Winston commented on NET-160:
--
Hi
Can you attach a thread dump? This would be more useful than truss output if
you can get it.
FTP Client API Hangs - Attached Scenario.
-
Key: NET-160
URL: https://issues.apache.org/jira/browse/NET-160
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Environment: Suse Enterprise Linux 9.0, Intel
Reporter: Lvenkataraman
FTP client hangs with the following error. Here is the truss output. The
client hangs indefinitely and no work is being done other than this error
when you truss the process. I use Java 1.5 to run this. We wrote a
long-running ftp daemon and this happens after 20-23 hours of continuous
running.
Here is the code to pull files from the ftp server. This one lists files that
are received after this particular incal time (currently it lists but the
intention is to implement an incremental download). We initially thought
doing periodic noop would keep the client alive by sending dummy commands to
the server. But we found this probelm still occurs.
public void ListIncrementalFiles (String directory, Calendar incal)
{
try
{
FTPFile[] files = listFiles(directory);
int total_files = 0;
System.out.println(FileName\tFileSize\t\tDate Time
Stamp);
for (int i = 0; i files.length; i++)
{
FTPFile file = files[i];
if ((i % 1000) == 0)
{
System.out.println(noop
occurred at this instance--- + i + \n);
noop();
}
if (file.isFile())
{
Calendar c =
file.getTimestamp();
if (c.after(incal) ||
c.equals(incal))
{
System.out.println(file.getName() + \t + file.getSize() + \t\t +
c.getTime());
total_files++;
}
}
}
System.out.println(Total Files in the listing
+ total_files);
}
catch (Exception e)
{
System.out.println(FTP Getfiles exception occured);
e.printStackTrace();
}
}
-Truss
output begins
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/6: lwp_cond_wait(0x00035F08, 0x00035EF0, 0xB477FBE0, 0) Err#62 ETIME
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/9: lwp_park(0x, 0) (sleeping...)
/3: lwp_cond_wait(0x000B77C0, 0x000B77A8, 0x, 0) (sleeping...)
/8: lwp_cond_wait(0x0014A908, 0x0014A8F0, 0x, 0) (sleeping...)
/10
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one year
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502143 ] Rory Winston commented on NET-159: -- Hi Julien 1. We cant make the assumption that remote timestamps will be GMT, they can in fact be an arbitrary timezone. 2. We may need to tweak the logic, however, I think your example is incorrect here. Disabling rollback on e.g. 1-Jan-2007 should display all recent format files correctly. Unless you are talking about files created on, for example, December 31st, and displayed using a recent file format, in which case, I think there may be a possibility that these files could be marked with the incorrect year. So maybe there might be a case for some sort of change along the lines you have mentioned - maybe something like: if (remote is recent_date_format and remote.time now) if (now.day == remote.day now.month == remote.month) then dont rollback else rollback 3. The changes are on the 2.0 branch: http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/?sortby=date FTPFile.getTimestamp() is off by one year - Key: NET-159 URL: https://issues.apache.org/jira/browse/NET-159 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: winxp, jdk 1.5 Reporter: dangerOp Priority: Minor Fix For: 2.0 The Calendar object returned by FTPFile.getTimestamp seems to be short by one year. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (NET-158) login in FTPClient does not always read the complete server response
[
https://issues.apache.org/jira/browse/NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston resolved NET-158.
--
Resolution: Fixed
Fix Version/s: 2.0
This will be in the 2.0 version
login in FTPClient does not always read the complete server response
Key: NET-158
URL: https://issues.apache.org/jira/browse/NET-158
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Reporter: Gilles Gaillard
Priority: Trivial
Fix For: 2.0
When a password is required to connect the FTP server, the implementation of
method login in class FTPClient ends with:
return FTPReply.isPositiveCompletion(pass(password))
which returns false for any code = 300.
However, some servers send a code 451 before returning the code 530
(NOT_LOGGED_IN). Ignoring this addtional answer,
leads to desynch the client with the server, hence leading to unexpected
behaviors in next exchanges.
Threfore i propose to replace the above code in the end of the method with:
_replyCode = p_Client.pass(p_Password);
boolean result = FTPReply.isPositiveCompletion(_replyCode);
if (!result _replyCode==FTPReply.ACTION_ABORTED){
try {
_replyCode = p_Client.getReply();
} catch (Exception e){
e.printStackTrace();
}
}
return result;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-140) FTPClient listFiles returns incorrect timestamp on freshly uploaded file but corrects itself after about 15 minutes
[ https://issues.apache.org/jira/browse/NET-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-140. Resolution: Fixed Fix Version/s: 2.0 The only reason I can see that the timestamp will be out of sync for 15 minutes and then ok is if the FTP server sends a different timestamp for files that are older than 15 minutes. This will result in the above behaviour. I have implemented a workaround for this problem - by calling FTPClient::setDateRollbackPermitted(false), the rollback by 1year should not occur for these situations. Any issues, feel free to reopen. FTPClient listFiles returns incorrect timestamp on freshly uploaded file but corrects itself after about 15 minutes --- Key: NET-140 URL: https://issues.apache.org/jira/browse/NET-140 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: Windows local client site, Linux remote server site Reporter: Bill Giel Fix For: 2.0 This is an odd one: We upload GPS data each hour to a public site using FTPClient. Every 24 hours we check for files older than 60 days using listFiles and getting the timestamps do decide if we want to delete older files. When we list the files, the most recently uploaded files have a time stamp exactly one year too old. After about 15 minutes, it seems to correct itself and eventually displays the correct timestamp. During this time while FTPFile.getTimestamp is giving the incorrect timestamp, browsing the folder with a web browser, a commercial FTP client, or actually checking the file info in a shell shows the correct timestamp (i.e. does not seem to be a problem on the remote site) commons-net-1.4.1 (as well as commons-net-20060901) exhibits this behavior. commons-net-1.3.0 works properly I did a little investigating, and it seems to happen with every file written to the remote directory each hour, and the incorrect timestamp will be returned using listFiles for about 15 minutes... and then it corrects itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons net question
[Cc:ing jakarta-commons-dev for infor purposes] type() is a lower-level method , in fact setFileType() calls type() internally, but setFileType() also does some book-keeping..i.e. it sets a couple of internal variables, that are used when storing or retrieving files. If these are not set, then you may not get the correct stream type. Rory Echevarria, Octavio wrote: Thanks for your reply. Ahhh... there is nothing like seeing sample code. I replaced a call to type() with setFileType() and it works now!! So the question now is: what is the difference between the two? I have not looked at the source code but both take the same argument. One is defined in FTP and the other in FTPClient. BTW, the call to completePendingCommand() causes my program to hang. This is right after I make the call to storeFile(). I have unit tested my change but I will wait until tonight for the official build and I will let you know. Regards, Octavio Octavio Echevarria CA Senior Software Engineer AllFusion Gen Development tel: +1 214 473 1281 fax: +1 214 473 1323 [EMAIL PROTECTED] -Original Message- From: Rory Winston [mailto:[EMAIL PROTECTED] Sent: Sunday, June 03, 2007 10:46 AM To: Echevarria, Octavio Subject: Re: commons net question Hi Octavio Firstly, sorry for not replying sooner - I have been out of the country. As to your issue, it may be related to you not calling completePendingCommand(). See the following FAQ entry *Q:After I perform a file transfer to the server, printWorkingDirectory() returns null. *on the FAQ page http://wiki.apache.org/jakarta-commons/Net/FrequentlyAskedQuestions If this does not fix your issue, then feel free to send me your code and I will take a look. Best, Rory ** Echevarria, Octavio wrote: Rory, I am new to the commons net package. I have written a small java utility to transfer files using FTP from a workstation to a server. When I transfer files in ASCII mode everything seems to work fine. However when I do the same for binary files, the files are corrupted on arrival. Is there a special sequence of commands that must be issued for this to work? FTPing the same file using the standard windows/dos ftp command works fine. I am also able to use FTP capabilities within a terminal emulator package and everything works fine. In both situations I target the same server. So I know that the FTP server is able to accept to the upload commands for both binary and asccii files. I am trying to figure out if there is perhaps a bug in the commons net package. I can send the code if you need me to. I apologize if this is not the proper medium for solving this, but any help would be greatly appreciated. Regards, Octavio Octavio Echevarria CA Senior Software Engineer AllFusion Gen Development tel: +1 214 473 1281 fax: +1 214 473 1323 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-153) Add getCause method to CopyStreamException
[ https://issues.apache.org/jira/browse/NET-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-153. Resolution: Fixed Fix Version/s: 2.0 Added getCause() Add getCause method to CopyStreamException -- Key: NET-153 URL: https://issues.apache.org/jira/browse/NET-153 Project: Commons Net Issue Type: Improvement Affects Versions: 1.4 Reporter: Dan Godfrey Priority: Trivial Fix For: 2.0 Attachments: CopyStreamException.patch Add a getCause method to CopyStreamException that has the same signature as Throwable#getCause from JDK 1.4 and returns the wrapped IOException. This will override the existing getCause method in version of Java 1.4 and hence include the IOExceptions stack trace in the CopyStreamExceptions stack trace or just be ignored in Java 1.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-159) FTPFile.getTimestamp() is off by one year
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-159. Resolution: Fixed Fix Version/s: 2.0 Added a method to disable the default rollback behaviour. FTPFile.getTimestamp() is off by one year - Key: NET-159 URL: https://issues.apache.org/jira/browse/NET-159 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: winxp, jdk 1.5 Reporter: dangerOp Priority: Minor Fix For: 2.0 The Calendar object returned by FTPFile.getTimestamp seems to be short by one year. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-159) FTPFile.getTimestamp() is off by one year
[ https://issues.apache.org/jira/browse/NET-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501047 ] Rory Winston commented on NET-159: -- Hi guys Thanks for the comments. I have analysed the issue, and here are my conclusions: 1. The synopsis you guys have given of the root cause of this issue is correct. If the date fits the recent date format, and the server timestamp local timestamp, excluding any explicitly specified drift due to timezone differentials, then this problem will occur. 2. FTPClient has no way of knowing when it is and when it is not correct to roll back the date. The default bahviour is to always roll back. I have added a method to FTPClient (setDateRollbackPermitted(boolean)). Call this method with value of false to explicitly disallow this behaviour. This should fix what you are seeing. I am marking this as fixed and doing a checkin. If any of you guys would like to check out the source and try my patch, you are most welcome. As usual, any problems, let me know. FTPFile.getTimestamp() is off by one year - Key: NET-159 URL: https://issues.apache.org/jira/browse/NET-159 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: winxp, jdk 1.5 Reporter: dangerOp Priority: Minor Fix For: 2.0 The Calendar object returned by FTPFile.getTimestamp seems to be short by one year. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-148) Relaxed condition in __getReply causes other failures.
[
https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498429
]
Rory Winston commented on NET-148:
--
Thanks Matthew , that is very helpful. I can reproduce the issue now. I think
we may need to modify that condition to fix this.
Relaxed condition in __getReply causes other failures.
--
Key: NET-148
URL: https://issues.apache.org/jira/browse/NET-148
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4, Nightly Builds
Reporter: Matthew Simoneau
Assigned To: Rory Winston
In FTP.java's __getReply() method, this do/while loop reads multi-line
responses from the server:
do
{
line = _controlInput.readLine();
...
}
while (!(line.length() = 4 line.charAt(3) != '-'
Character.isDigit(line.charAt(0;
// This is too strong a condition because of non-conforming ftp
// servers like ftp.funet.fi which sent 226 as the last line of a
// 426 multi-line reply in response to ls /. We relax the
condition to
// test that the line starts with a digit rather than starting
with
// the code.
// line.startsWith(code)));
}
Note the comment and the commented-out termination condition. I think the
relevant spec is http://www.ietf.org/rfc/rfc0959.txt and the section is
4.2. FTP REPLIES. This is causing problems with the return from the STAT
command from Geocities' FTP servers. Here is an example reply.
211- ftp.us.geocities.com FTP server status:
Version wu-2.6.0(48) Tue Jan 2 16:30:15 PST 2007
Connected to 144.212.217.85
Logged in anonymously
TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream
No data connection
0 data bytes received in 0 files
0 data bytes transmitted in 0 files
0 data bytes total in 0 files
57 traffic bytes received in 0 transfers
733 traffic bytes transmitted in 0 transfers
834 traffic bytes total in 0 transfers
211 End of status
Note that the line 0 data bytes total in 0 files starts with a digit, but
it isn't a reply code. This prematurely halts reading of lines from the
server, and the remaining lines will look like a reply from the next command.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (NET-148) Relaxed condition in __getReply causes other failures.
[
https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston updated NET-148:
-
Fix Version/s: 2.0
Relaxed condition in __getReply causes other failures.
--
Key: NET-148
URL: https://issues.apache.org/jira/browse/NET-148
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4, Nightly Builds
Reporter: Matthew Simoneau
Assigned To: Rory Winston
Fix For: 2.0
In FTP.java's __getReply() method, this do/while loop reads multi-line
responses from the server:
do
{
line = _controlInput.readLine();
...
}
while (!(line.length() = 4 line.charAt(3) != '-'
Character.isDigit(line.charAt(0;
// This is too strong a condition because of non-conforming ftp
// servers like ftp.funet.fi which sent 226 as the last line of a
// 426 multi-line reply in response to ls /. We relax the
condition to
// test that the line starts with a digit rather than starting
with
// the code.
// line.startsWith(code)));
}
Note the comment and the commented-out termination condition. I think the
relevant spec is http://www.ietf.org/rfc/rfc0959.txt and the section is
4.2. FTP REPLIES. This is causing problems with the return from the STAT
command from Geocities' FTP servers. Here is an example reply.
211- ftp.us.geocities.com FTP server status:
Version wu-2.6.0(48) Tue Jan 2 16:30:15 PST 2007
Connected to 144.212.217.85
Logged in anonymously
TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream
No data connection
0 data bytes received in 0 files
0 data bytes transmitted in 0 files
0 data bytes total in 0 files
57 traffic bytes received in 0 transfers
733 traffic bytes transmitted in 0 transfers
834 traffic bytes total in 0 transfers
211 End of status
Note that the line 0 data bytes total in 0 files starts with a digit, but
it isn't a reply code. This prematurely halts reading of lines from the
server, and the remaining lines will look like a reply from the next command.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-160) FTP Client API Hangs - Attached Scenario.
[
https://issues.apache.org/jira/browse/NET-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494517
]
Rory Winston commented on NET-160:
--
Hi
There are known issues where [net] 1.4 and previous versions will hang - can
you try it with this version and see if you have the same problem?
http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHOT.jar
FTP Client API Hangs - Attached Scenario.
-
Key: NET-160
URL: https://issues.apache.org/jira/browse/NET-160
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Environment: Suse Enterprise Linux 9.0, Intel
Reporter: Lvenkataraman
FTP client hangs with the following error. Here is the truss output. The
client hangs indefinitely and no work is being done other than this error
when you truss the process. I use Java 1.5 to run this. We wrote a
long-running ftp daemon and this happens after 20-23 hours of continuous
running.
Here is the code to pull files from the ftp server. This one lists files that
are received after this particular incal time (currently it lists but the
intention is to implement an incremental download). We initially thought
doing periodic noop would keep the client alive by sending dummy commands to
the server. But we found this probelm still occurs.
public void ListIncrementalFiles (String directory, Calendar incal)
{
try
{
FTPFile[] files = listFiles(directory);
int total_files = 0;
System.out.println(FileName\tFileSize\t\tDate Time
Stamp);
for (int i = 0; i files.length; i++)
{
FTPFile file = files[i];
if ((i % 1000) == 0)
{
System.out.println(noop
occurred at this instance--- + i + \n);
noop();
}
if (file.isFile())
{
Calendar c =
file.getTimestamp();
if (c.after(incal) ||
c.equals(incal))
{
System.out.println(file.getName() + \t + file.getSize() + \t\t +
c.getTime());
total_files++;
}
}
}
System.out.println(Total Files in the listing
+ total_files);
}
catch (Exception e)
{
System.out.println(FTP Getfiles exception occured);
e.printStackTrace();
}
}
-Truss
output begins
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/6: lwp_cond_wait(0x00035F08, 0x00035EF0, 0xB477FBE0, 0) Err#62 ETIME
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/14: pollsys(0x, 0, 0xB3F7FC10, 0x) = 0
/9: lwp_park(0x, 0) (sleeping...)
/3
Re: [VOTE] Release commons-parent 2
Jochen Wiedmann wrote: +1 +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-158) login in FTPClient does not always read the complete server response
[
https://issues.apache.org/jira/browse/NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489702
]
Rory Winston commented on NET-158:
--
HI Gilles
Thanks for the submission. What FTP server (version, OS ) is this happening
with? Would you be able to include a trace of the server/client conversation
(by using the PrintCommandListener) e.g.
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
Thanks,
Rory
login in FTPClient does not always read the complete server response
Key: NET-158
URL: https://issues.apache.org/jira/browse/NET-158
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Reporter: Gilles Gaillard
Priority: Trivial
When a password is required to connect the FTP server, the implementation of
method login in class FTPClient ends with:
return FTPReply.isPositiveCompletion(pass(password))
which returns false for any code = 300.
However, some servers send a code 451 before returning the code 530
(NOT_LOGGED_IN). Ignoring this addtional answer,
leads to desynch the client with the server, hence leading to unexpected
behaviors in next exchanges.
Threfore i propose to replace the above code in the end of the method with:
_replyCode = p_Client.pass(p_Password);
boolean result = FTPReply.isPositiveCompletion(_replyCode);
if (!result _replyCode==FTPReply.ACTION_ABORTED){
try {
_replyCode = p_Client.getReply();
} catch (Exception e){
e.printStackTrace();
}
}
return result;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-158) login in FTPClient does not always read the complete server response
[
https://issues.apache.org/jira/browse/NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489777
]
Rory Winston commented on NET-158:
--
Thanks Gilles, I will have a look at this. Do you happen to know what the FTP
server is (i.e,. what software - wuftpd)?
login in FTPClient does not always read the complete server response
Key: NET-158
URL: https://issues.apache.org/jira/browse/NET-158
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Reporter: Gilles Gaillard
Priority: Trivial
When a password is required to connect the FTP server, the implementation of
method login in class FTPClient ends with:
return FTPReply.isPositiveCompletion(pass(password))
which returns false for any code = 300.
However, some servers send a code 451 before returning the code 530
(NOT_LOGGED_IN). Ignoring this addtional answer,
leads to desynch the client with the server, hence leading to unexpected
behaviors in next exchanges.
Threfore i propose to replace the above code in the end of the method with:
_replyCode = p_Client.pass(p_Password);
boolean result = FTPReply.isPositiveCompletion(_replyCode);
if (!result _replyCode==FTPReply.ACTION_ABORTED){
try {
_replyCode = p_Client.getReply();
} catch (Exception e){
e.printStackTrace();
}
}
return result;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-54) [net] FTPReply.isPositivePreliminary(int) returns false when reply = 220 (Server ready) Causes FTPClient.retrieveFile(String, OutputStream) to fail
[
https://issues.apache.org/jira/browse/NET-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston closed NET-54.
---
Resolution: Invalid
The code shown is correct. 220 is not a positive preliminary value, rather it
is a positive completion value. Hence isPositivePreliminary() should return
false.
[net] FTPReply.isPositivePreliminary(int) returns false when reply = 220
(Server ready) Causes FTPClient.retrieveFile(String, OutputStream) to fail
---
Key: NET-54
URL: https://issues.apache.org/jira/browse/NET-54
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Environment: Operating System: other
Platform: PC
Reporter: Jeff Barnes
public static boolean isPositivePreliminary(int reply)
{
return (reply = 100 reply 200);
}
should be changed to
public static boolean isPositivePreliminary(int reply)
{
return (reply = 100 reply 220); //or is it some other magic
number?
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-154) Typo in NNTPClient javadoc comment
[ https://issues.apache.org/jira/browse/NET-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-154. Resolution: Fixed Fix Version/s: 2.0 Typo in NNTPClient javadoc comment -- Key: NET-154 URL: https://issues.apache.org/jira/browse/NET-154 Project: Commons Net Issue Type: Improvement Reporter: Brian Lewis Priority: Trivial Fix For: 2.0 In NNTPClient's NNTPClient() javadoc comment, NNTPConectionClosedException is missing an n. It should be NNTPConnectionClosedException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Proposal: move build to m2
Definite +1 for moving to m2. I moved [net] to m2 a while back, and it's been all good so far. Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: As we ramp up to a 1.2 release, I think its a good idea to move to Maven 2 as the standard build. That means deprecating the m1 build (leaving in the 1.2 release, if possible), moving the site and nightlies, etc. Lets view this as lazy consensus - i.e., scream now or forever hold your peace. Assuming no objections in the next couple of days, we can start battling - er, I mean working - with m2. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Proposal: move build to m2
Definite +1 for moving to m2. I moved [net] to m2 a while back, and it's been all good so far. Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: As we ramp up to a 1.2 release, I think its a good idea to move to Maven 2 as the standard build. That means deprecating the m1 build (leaving in the 1.2 release, if possible), moving the site and nightlies, etc. Lets view this as lazy consensus - i.e., scream now or forever hold your peace. Assuming no objections in the next couple of days, we can start battling - er, I mean working - with m2. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Proposal: move build to m2
Definite +1 for moving to m2. I moved [net] to m2 a while back, and it's been all good so far. Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: As we ramp up to a 1.2 release, I think its a good idea to move to Maven 2 as the standard build. That means deprecating the m1 build (leaving in the 1.2 release, if possible), moving the site and nightlies, etc. Lets view this as lazy consensus - i.e., scream now or forever hold your peace. Assuming no objections in the next couple of days, we can start battling - er, I mean working - with m2. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Proposal: move build to m2
Definite +1 for moving to m2. I moved [net] to m2 a while back, and it's been all good so far. Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: As we ramp up to a 1.2 release, I think its a good idea to move to Maven 2 as the standard build. That means deprecating the m1 build (leaving in the 1.2 release, if possible), moving the site and nightlies, etc. Lets view this as lazy consensus - i.e., scream now or forever hold your peace. Assuming no objections in the next couple of days, we can start battling - er, I mean working - with m2. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-163) The evaluate method and the getResult method of class Variance give different results
[
https://issues.apache.org/jira/browse/MATH-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485214
]
Rory Winston commented on MATH-163:
---
I guess the correct answer is Inf - although I can see that some other packages
return NaN. For instance in R:
x=c(1.0,2.0,Inf)
var(x)
[1] NaN
The evaluate method and the getResult method of class Variance give different
results
-
Key: MATH-163
URL: https://issues.apache.org/jira/browse/MATH-163
Project: Commons Math
Issue Type: Bug
Affects Versions: 1.1
Reporter: Nele Smeets
Consider the following test code:
// construct an array of input values, containing infinity
double[] values = new double[] {1.0, 2.0, Double.POSITIVE_INFINITY};
// find the variance using Variance.evaluate(double[])
Variance var1 = new Variance();
double value1 = var1.evaluate(values);
// find the variance using Variance.getResult()
Variance var2 = new Variance();
var2.incrementAll(values);
double value2 = var2.getResult();
// print out the results
System.out.println(value1);
System.out.println(value2);
This code prints out:
NaN
Infinity
So, we get two different variances, depending on the method we use.
(The same is true when we use Double.NEGATIVE_INFINITY as input value instead
of Double.POSITIVE_INFINITY.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (NET-148) Relaxed condition in __getReply causes other failures.
[
https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston resolved NET-148.
--
Resolution: Cannot Reproduce
I have tried this with Geocities servers, but I cant reproduce the issue with
2.0 RC? Can you provide some more info?
Relaxed condition in __getReply causes other failures.
--
Key: NET-148
URL: https://issues.apache.org/jira/browse/NET-148
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matthew Simoneau
In FTP.java's __getReply() method, this do/while loop reads multi-line
responses from the server:
do
{
line = _controlInput.readLine();
...
}
while (!(line.length() = 4 line.charAt(3) != '-'
Character.isDigit(line.charAt(0;
// This is too strong a condition because of non-conforming ftp
// servers like ftp.funet.fi which sent 226 as the last line of a
// 426 multi-line reply in response to ls /. We relax the
condition to
// test that the line starts with a digit rather than starting
with
// the code.
// line.startsWith(code)));
}
Note the comment and the commented-out termination condition. I think the
relevant spec is http://www.ietf.org/rfc/rfc0959.txt and the section is
4.2. FTP REPLIES. This is causing problems with the return from the STAT
command from Geocities' FTP servers. Here is an example reply.
211- ftp.us.geocities.com FTP server status:
Version wu-2.6.0(48) Tue Jan 2 16:30:15 PST 2007
Connected to 144.212.217.85
Logged in anonymously
TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream
No data connection
0 data bytes received in 0 files
0 data bytes transmitted in 0 files
0 data bytes total in 0 files
57 traffic bytes received in 0 transfers
733 traffic bytes transmitted in 0 transfers
834 traffic bytes total in 0 transfers
211 End of status
Note that the line 0 data bytes total in 0 files starts with a digit, but
it isn't a reply code. This prematurely halts reading of lines from the
server, and the remaining lines will look like a reply from the next command.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (NET-155) Integer is too small to hold article number value (NNTPClient __parseNewsgroupListEntry() function)
[
https://issues.apache.org/jira/browse/NET-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston resolved NET-155.
--
Resolution: Fixed
Fix Version/s: 2.0
Fix applied.
Integer is too small to hold article number value (NNTPClient
__parseNewsgroupListEntry() function)
---
Key: NET-155
URL: https://issues.apache.org/jira/browse/NET-155
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Environment: any
Reporter: Krzysztof Jakubczyk
Fix For: 2.0
running the following code:
client.connect(news.icm.edu.pl);
NewsgroupInfo[] grps = client.listNewsgroups();
results MalformedServerReplyException (alt.atheism 2147485259 2147483647 y)
it's because in function NNTPClient.__parseNewsgroupListEntry():
last = tokenizer.nextToken();
first = tokenizer.nextToken();
permission = tokenizer.nextToken();
try
{
lastNum = Integer.parseInt(last);
firstNum = Integer.parseInt(first);
result._setFirstArticle(firstNum);
result._setLastArticle(lastNum);
if((firstNum == 0) (lastNum == 0))
result._setArticleCount(0);
else
result._setArticleCount(lastNum - firstNum + 1);
}
catch (NumberFormatException e)
{
return null;
}
lastNum and firstNum are Integer (too small for received values)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-152) FTPClient.retrieveFileStream hangs occassionally
[ https://issues.apache.org/jira/browse/NET-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478809 ] Rory Winston commented on NET-152: -- Can you try the 2.0-snapshot? It is available here: http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHOT.jar Note that you will need JDK 5+ FTPClient.retrieveFileStream hangs occassionally Key: NET-152 URL: https://issues.apache.org/jira/browse/NET-152 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: Redhat Enterprise Linux 4 Reporter: Shashi Anand B Occassionally, retrieveFileStream on FTPClient hangs. The thread dump gives the following trace: java.net.PlainSocketImpl.socketAccept (native method) java.net.PlainSocketImpl.accept (PlainSocketImpl.java:353) java.net.ServerSocket.implAccept (ServerSocket.java:448) java.net.ServerSocket.accept (ServerSocket.java:419) org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502) org.apache.commons.net.ftp.FTPClient.retrieveFileStream(FTPClient.java:1,342) This seems to occur randomly. Hence, I have not been able to get any specific information for further debugging. Is this a known issue? Is there any work-around for this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-152) FTPClient.retrieveFileStream hangs occassionally
[ https://issues.apache.org/jira/browse/NET-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478949 ] Rory Winston commented on NET-152: -- The fix to this problem involved a substantial change in the class hierarchy, and the changes are only availble in the 2.0 branch. There are no plans at present to port any of the major 2.0 changes to the 1.4.x branch. However, if you are desperate for a fix on JDK 1.4.x , and you have the inclination and energy, you may be able to backport the code to a 1.4.x platform. The JDK 5+ specific changes as far as I can recall are: * Some of the regex code is 1.5+ only (possibly just one method, IIRC) * Use of generics * Some SocketFactory-related code, which could be easily backported There may be more, but I would think that is the bulk of it. The source code is available here: http://people.apache.org/~rwinston/commons-net-2.0/commons-net-2.0.0-SNAPSHOT-src.zip Or here in SVN (recommended) http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/ FTPClient.retrieveFileStream hangs occassionally Key: NET-152 URL: https://issues.apache.org/jira/browse/NET-152 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: Redhat Enterprise Linux 4 Reporter: Shashi Anand B Occassionally, retrieveFileStream on FTPClient hangs. The thread dump gives the following trace: java.net.PlainSocketImpl.socketAccept (native method) java.net.PlainSocketImpl.accept (PlainSocketImpl.java:353) java.net.ServerSocket.implAccept (ServerSocket.java:448) java.net.ServerSocket.accept (ServerSocket.java:419) org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502) org.apache.commons.net.ftp.FTPClient.retrieveFileStream(FTPClient.java:1,342) This seems to occur randomly. Hence, I have not been able to get any specific information for further debugging. Is this a known issue? Is there any work-around for this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IPv6 enablement of commons-net
Hi Deepa There are no plans to do this at present. If you are planning to do some work in this regard, any submissions would be gratefully accepted. regards Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: --=_alternative 0032093F65257291_= Content-Type: text/plain; charset=US-ASCII Hi, I am from the file adapter development background. We have been using the FTP client implementation of the commons-net in our usage extensively. I was just wondering about the plans for enabling the commons-net package for handling IPv6 addresses. I couldnt find info rgd that on the jakarta.commons pages. I am eager to volunteer for this feature enablement. Thanks, Deepa ___ Deepa Rao WebSphere Adapter Development, Embassy Golf Links Business Park, C Block, 6th Floor, India Software Labs, IBM India, Bangalore - 560071. EGL Extn: 7560Direct Ph: 91-80-41927560Cell: 9845820273 --=_alternative 0032093F65257291_=-- - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IPv6 enablement of commons-net
Hi Deepa There are no plans to do this at present. If you are planning to do some work in this regard, any submissions would be gratefully accepted. regards Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: --=_alternative 0032093F65257291_= Content-Type: text/plain; charset=US-ASCII Hi, I am from the file adapter development background. We have been using the FTP client implementation of the commons-net in our usage extensively. I was just wondering about the plans for enabling the commons-net package for handling IPv6 addresses. I couldnt find info rgd that on the jakarta.commons pages. I am eager to volunteer for this feature enablement. Thanks, Deepa ___ Deepa Rao WebSphere Adapter Development, Embassy Golf Links Business Park, C Block, 6th Floor, India Software Labs, IBM India, Bangalore - 560071. EGL Extn: 7560Direct Ph: 91-80-41927560Cell: 9845820273 --=_alternative 0032093F65257291_=-- - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-151) [PATCH] Allow user to force passive connections to use connected host in FTPClient
[ https://issues.apache.org/jira/browse/NET-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-151. Resolution: Fixed Fix Version/s: 2.0 Patch applied. [PATCH] Allow user to force passive connections to use connected host in FTPClient -- Key: NET-151 URL: https://issues.apache.org/jira/browse/NET-151 Project: Commons Net Issue Type: Improvement Affects Versions: 2.0 Environment: Windows XP, Java 1.5.0, Intel processor Reporter: Neil Aggarwal Fix For: 2.0 Attachments: FTPClient.patch.txt, FTPClientOverrideHost.patch.txt Currently, FTPClient always uses the host and port returned to it from the reply to a passive connection request. Some FTP hosts are set incorrectly or are set behind a NAT so they report the incorrect IP address to use for the connection and the transfer will fail to connect. This patch allows the user to tell FTPClient to use the connected host instead of the host given from the passive reply. Doing so will allow successful transfers even when the report FTP server returns an incorrect IP address. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Latest 2.0 RC Ready
Thanks Niall I've actually fixed most of these, I just havent cut an RC with the changes yet. I'm tempted to wait until commons-parent-2 gets released before I call a vote on [net] again, as it seems to be pretty much there. Rory Niall Pemberton wrote: On 1/28/07, Rory Winston [EMAIL PROTECTED] wrote: (Resending as I left out commons-user) Hi all I have cut a new RC, with some changes and fixes, many of which were distribution-related and suggested by Niall earlier (thanks Niall). RC (minus MD5s etc for now) is here: http://people.apache.org/~rwinston/commons-net-2.0/ Some users have been testing out this 2.0 branch for a while, so I'm going to kick off a vote pretty soon. Any comments welcome. - TestClient and AllTests are missing license headers. - depends on the commons-parent 2-SNAPSHOT (needs releasing) - Jar Manifest is missing the usual entries (ftp jar seems to have them) - you must have an old version of commons-parent 2-SNAPSHOT because I re-built from the source distro and it contained them. - NOTICE.txt file has copyright statement to 2006 (rather than 2007) Niall Cheers Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Latest 2.0 RC Ready
Julius Possibly - the validation behaviour is pluggable in FTPSClient, so you can validate on whatever the user wishes Thanks Rory Julius Davies wrote: Should FTPS do hostname verification? (Where you check the hostname you're connecting to against the CN value of the certificate). Here's an implementation in HttpClient if you're interested: http://svn.apache.org/viewvc/jakarta/httpcomponents/httpclient/trunk/src/java/org/apache/http/conn/ssl/HostnameVerifier.java?view=markup I have a small fix I'd like to make to that code, though: https://issues.apache.org/jira/browse/HTTPCLIENT-617 I'll try and do that within the next 3 days. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Latest 2.0 RC Ready
Hi Jörg Thanks for the info about the Maven repo - I'm a bit confused with this one however, as when I leave out the snapshot repo that I have defined, it cant find the Maven changes plugin. Possibly I need to define a different repo? I'll need to check. As far as docs are concerned, [net] has never been too docs-heavy, but they were never really needed - usage is relatively basic. However, it may be a good idea to add a getting started page or such to the docs/site. Appreciate you taking the time! Thanks Rory Jörg Schaible wrote: Hi Rory, Rory Winston wrote: (Resending as I left out commons-user) Hi all I have cut a new RC, with some changes and fixes, many of which were distribution-related and suggested by Niall earlier (thanks Niall). RC (minus MD5s etc for now) is here: http://people.apache.org/~rwinston/commons-net-2.0/ Some users have been testing out this 2.0 branch for a while, so I'm going to kick off a vote pretty soon. Any comments welcome. Cheers Rory I've checked the src-tar.gz and I can build the package with M2 and all tests using Sun JDK 5 in Linux ... but The POM triggers SNAPSHOT versions of plugins! You cannot release this. The POM should also not define a SNAPSHOT repo at all. Also there is a big lack of docs. Not even a simple introduction. Minor topics: - Javadoc: example packages? - JIRA Report: Missing images Cheers, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Latest Commons-Net 2.0 RC ready
Hi all I have cut a new RC, with some changes and fixes, many of which were distribution-related and suggested by Niall earlier (thanks Niall). RC (minus MD5s etc for now) is here: http://people.apache.org/~rwinston/commons-net-2.0/ Some users have been testing out this 2.0 branch for a while, so I'm going to kick off a vote pretty soon. Any comments welcome. Cheers Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] Latest 2.0 RC Ready
(Resending as I left out commons-user) Hi all I have cut a new RC, with some changes and fixes, many of which were distribution-related and suggested by Niall earlier (thanks Niall). RC (minus MD5s etc for now) is here: http://people.apache.org/~rwinston/commons-net-2.0/ Some users have been testing out this 2.0 branch for a while, so I'm going to kick off a vote pretty soon. Any comments welcome. Cheers Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTP Client Using SSL
Hi Gene I am hoping to have it out soon, other commitments permitting. Any testing you can do is much appreciated. Thanks Rory [EMAIL PROTECTED] wrote: --NextPart_Webmail_9m3u9jl4l_5912_1169603225_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Rory - Thanks for the quick response! Do you have any sense for the timing / schedule for the final release? If you are interested, I may be able to propose a project at work that could excercise the functionality and give it some testing. Gene -- Original message -- From: Rory Winston [EMAIL PROTECTED] Yes indeed it has been extended to support SSL. You can find the pre-release candidate here (note, I will be updating this RX at the weekend to reflect some more recent changes): http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHO T.jar You will need Java 5.0+ Thanks Rory Jakarta Commons Developers List wrote: --NextPart_Webmail_9m3u9jl4l_12516_1169507565_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I was curious if anyone has extended the FTP Client provided in the commons.net package to support FTPS (i.e. FTP using SSL)? --NextPart_Webmail_9m3u9jl4l_12516_1169507565_0-- - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --NextPart_Webmail_9m3u9jl4l_5912_1169603225_0 Content-Type: text/html Content-Transfer-Encoding: 8bit htmlbody DIVRory -/DIV DIV /DIV DIVThanks for the quick response!/DIV DIV /DIV DIVDo you have any sense for the timing / schedule for the final release?/DIV DIV /DIV DIVIf you are interested, I may be able to propose a project at work that could excercise the functionality and give it some testing./DIV DIV /DIV DIVGene/DIV DIV /DIV BLOCKQUOTE style=PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid-- Original message -- BRFrom: Rory Winston [EMAIL PROTECTED] BRBR Yes indeed it has been extended to support SSL. You can find the pre-release BR candidate here (note, I will be updating this RX at the weekend to reflect some BR more recent changes): BR BR http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHO BR T.jar BR BR You will need Java 5.0+ BR BR Thanks BR Rory BR BR BR Jakarta Commons Developers List COMMONS-DEV@JAKARTA.APACHE.ORGwrote: BR BR BR --NextPart_Webmail_9m3u9jl4l_12516_1169507565_0 BR Content-Type: text/plain BR Content-Transfer-Encoding: 8bit BR BR I was curious if anyone has extended the FTP Client provided in the BR commons.net package to suppo rt FTPS (i.e. FTP using SSL)? BR --NextPart_Webmail_9m3u9jl4l_12516_1169507565_0-- BR BR BR BR BR - BR Find the home of your dreams with eircom net property BR Sign up for email alerts now http://www.eircom.net/propertyalerts BR BR BR BR - BR To unsubscribe, e-mail: [EMAIL PROTECTED] BR For additional commands, e-mail: [EMAIL PROTECTED] BR /BLOCKQUOTE/body/html --NextPart_Webmail_9m3u9jl4l_5912_1169603225_0-- - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTP Client Using SSL
Yes indeed it has been extended to support SSL. You can find the pre-release candidate here (note, I will be updating this RX at the weekend to reflect some more recent changes): http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHOT.jar You will need Java 5.0+ Thanks Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: --NextPart_Webmail_9m3u9jl4l_12516_1169507565_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I was curious if anyone has extended the FTP Client provided in the commons.net package to support FTPS (i.e. FTP using SSL)? --NextPart_Webmail_9m3u9jl4l_12516_1169507565_0-- - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTP Client Using SSL
Yes indeed it has been extended to support SSL. You can find the pre-release candidate here (note, I will be updating this RX at the weekend to reflect some more recent changes): http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHOT.jar You will need Java 5.0+ Thanks Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: --NextPart_Webmail_9m3u9jl4l_12516_1169507565_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I was curious if anyone has extended the FTP Client provided in the commons.net package to support FTPS (i.e. FTP using SSL)? --NextPart_Webmail_9m3u9jl4l_12516_1169507565_0-- - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP reply list never cleared
Hi Niklas Thanks for this, I will apply the patch. Cheers Rory Niklas Gustavsson wrote: Hi When using the net Java 5 branch, the replies returned from the server is stored in a list that is not emptied between commands. This means that when for example printing the replies with a ProtocolCommandListener you will get the full history of replies rather than the last one. The following patch seems to work: Index: src/main/java/org/apache/commons/net/ftp/FTP.java === --- src/main/java/org/apache/commons/net/ftp/FTP.java (revision 497851) +++ src/main/java/org/apache/commons/net/ftp/FTP.java (working copy) @@ -266,7 +266,7 @@ int length; _newReplyString = true; -//_replyLines. setSize(0); +_replyLines.clear(); String line = _controlInput_.readLine(); /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-91) commons.net.FTPClient hangs on disconnect or logout
[
https://issues.apache.org/jira/browse/NET-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston closed NET-91.
---
commons.net.FTPClient hangs on disconnect or logout
---
Key: NET-91
URL: https://issues.apache.org/jira/browse/NET-91
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: All
Platform: PC
Reporter: Joe
By repetitively calling
try {
// connect and login to the FTP server
ftpc.connect(getPropertyFromEnv(FTP_SERVER));
ftpc.login(getPropertyFromEnv(USERNAME), getPropertyFromEnv
(PASSWORD)); //technically we may have to break this into 2 blocks see
examples
// After connection attempt, check the reply code to verify
success.
reply = ftpc.getReplyCode();
response = ftpc.getReplyString();
if(!FTPReply.isPositiveCompletion(reply)) {
System.err.println(FTP server refused connection or login.);
killFTP(ftpc);
ftpc = null;
}
} catch(IOException e) {
System.err.println(Can't connect or login to server, reply
= +reply+ response = + response);
killFTP(ftpc);
ftpc = null;
}
and then
if (ftpc.isConnected()) {
try {
ftpc.logout();
} catch (Exception e) { // do nothing
System.out.println(Exception in ftpc.logout());
}
try {
ftpc.disconnect();
} catch (Exception e) { // do nothing
System.out.println(Exception in ftpc.disconnect());
}
}
one of the two bottom calls hangs and I'm assuming that it's in an infinite
loop waiting for something that the server isn't sending. We try and hook to
a Linux FTP server, and Windows FTP server and 99.99 % of the time it works,
but every once in a while, it hangs and we have to kill the FTP daemon.
After
doing that everything works again!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: UUID MAC configuration
Pradeep Getting the MAC address is problematic - normally it requires native code (which may use OS-level function calls or a native SNMP API, which is one of the approaches I have seen). Two options: 1. If you are using JDK 6, you may be in luck: see http://java.sun.com/javase/6/docs/api/java/net/NetworkInterface.html#getHardwareAddress() 2. Take a look at JUG (http://jug.safehaus.org/Home), which has a JNI portion for reading the MAC address Thanks Rory Pradeep Arumalla wrote: hi all, I am using VersionOneGenerator and I see that we need to configure the MAC addres in the xml file , I mean the uuid.state file .It works locally .But how do I give to other teams and ask them to work without having to enter the MAC address in the uuid.state file.I mean is there any better way to detect the MAC address automatically ? *My Idea is to give a jar file to different teams in my company to generate UUID's. * Thanks Pradeep - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1 Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: On Fri, 5 Jan 2007, Henri Yandell [EMAIL PROTECTED] wrote: As you can see on the list, Matt would like to help out with JXPath. +1 Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1 Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: On Fri, 5 Jan 2007, Henri Yandell [EMAIL PROTECTED] wrote: As you can see on the list, Matt would like to help out with JXPath. +1 Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
Steve
The problem was with TelnetClient's reader thread blocking on read() and
locking up - to be honest, I have yet to figure out exactly what caused
the deadlock, but one of the initial changes I made on the 2.0 branch
was to refactor FTPClient so it extended SocketClient directly, and thus
with no reader thread, the issue does not seem to arise. I think we
would need a detailed examination of TelnetClient to figure out what
were the circumstances that caused it to deadlock in this manner.
Cheers
Rory
Steve Cohen (JIRA) wrote:
[ http://issues.apache.org/jira/browse/NET-61?page=comments#action_12460625 ]
Steve Cohen commented on NET-61:
Rory, sorry I've been too busy to be involved here, but could you briefly sum
up what the change was? I banged my head on this one for quite awhile when it
was first logged.
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
Fix For: 2.0
A Java app that uses FTPClient to download a file from a website to Windows XP
works properly. But, when the same app runs on Linux to download the same file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
Henri
Thats a very good suggestion - I'll try and remember that for future
reference!
Cheers
Rory
Henri Yandell wrote:
This might be because I spend a lot of my day reading open source
JIRAs/Bugzillas; but it's really nice to tie the svn commit to the
JIRA issue. Technically JIRA is meant to listen to svn commits with
the issue number in, but I've never really bothered with that, rather
I do the following:
* Include the Bugzilla/JIRA number in the svn commit.
* Copy and paste the svn commit lines into the JIRA comment.
See: https://issues.apache.org/jira/browse/LANG-304
Pretty sure someone else here was doing that and I picked the habit up
from them. As I said - as I spend lots of time reading JIRAs etc, it's
a very appreciated habit when people do that and it's actually easier
as a developer - I don't have to comment on what the fix is etc
because that's already in the svn commit message that I'm c+p'ing.
Thought I'd share...
Hen
On 12/22/06, Steve Cohen (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/NET-61?page=comments#action_12460625
]
Steve Cohen commented on NET-61:
Rory, sorry I've been too busy to be involved here, but could you
briefly sum up what the change was? I banged my head on this one for
quite awhile when it was first logged.
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
Fix For: 2.0
A Java app that uses FTPClient to download a file from a website to
Windows XP
works properly. But, when the same app runs on Linux to download
the same file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version
of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The
following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
[ http://issues.apache.org/jira/browse/NET-61?page=all ]
Rory Winston closed NET-61.
---
Resolution: Fixed
This issue is fixed in 2.0
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
A Java app that uses FTPClient to download a file from a website to Windows
XP
works properly. But, when the same app runs on Linux to download the same
file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-36) [net] PATCH] FTP and FTPClient changes
[ http://issues.apache.org/jira/browse/NET-36?page=all ] Rory Winston closed NET-36. --- [net] PATCH] FTP and FTPClient changes -- Key: NET-36 URL: http://issues.apache.org/jira/browse/NET-36 Project: Commons Net Issue Type: Bug Affects Versions: 1.2 Final Environment: Operating System: other Platform: Other Reporter: Joseph Hindsley Attachments: FTP.java.patch.txt, FTPClient.java.patch.txt, FTPTest.java.patch.txt, FTPTest.java.patch.txt I've included 3 patch files for changes I've made to the FTP andFTPClient classes in the commons-net package. The first patch is for the FTP class making it extend SocketClientinstead of TelnetClient. I noticed that the behavior of theTelnetClient's input stream reader thread was effectively ignoring thesocket's SOTimeout causing reads to hang forever if the server decidednot to respond to a client request at all. This should also answer oneof the goals from the TODO list: Divorce FTPClient from TelnetClient, getting rid of the TelnetClientthreads which cause problems on some platforms (e.g., MacOS). The second patch is for an FTPTest unit test. I've covered most of thebasic methods (connect(), disconnect(), sendCommand(), getReplyCode(),etc). Ignored for now are the convenience methods since they all callsendCommand() underneath. Part of the FTPTest class is a DummyFTPServerinner class which is used to communicate to the test FTP class - don'tknow if that would be useful elsewhere (maybe part of FTPClient unittests), so you might consider making it a utility class for other unittests. Finally I've attached a patch for minor changes to FTPClient: - changed __storeFile() from private to protected so that it can beused by classes that extend FTPClient - added __storeFile(String, String) method - so that the commands itaccepts are not limited to what's found in FTPCommand. Note: the__storeFile(int, String) method now calls the __storeFile(String,String) method. - added _openDataConnection_(String, String) method - so that thecommands it accepts are not limited to what's found in FTPCommand. Note:the _openDataConnection_(int, String) method now calls the_openDataConnection_(String, String) method. Hopefully you'll find the changes agreeable and will incorporate theminto the code base. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-3) [net][PATCH] TelnetInputStream.read sometimes hangs if reader thread is disabled
[ http://issues.apache.org/jira/browse/NET-3?page=all ]
Rory Winston closed NET-3.
--
[net][PATCH] TelnetInputStream.read sometimes hangs if reader thread is
disabled
Key: NET-3
URL: http://issues.apache.org/jira/browse/NET-3
Project: Commons Net
Issue Type: Bug
Environment: Operating System: Windows XP
Platform: PC
Reporter: Rob Hasselbaum
Attachments: hanging_read_fix.patch
I'm trying to use TelnetClient with the reader thread disabled because I
don't
want socket timeouts to fire during planned periods of inactivity (COM-1554).
But when the thread is disabled, I'm finding that TelnetInputStream.read
occassionally hangs when I try to read output from the server.
The problem appears to be the first while loop in __processChar, which looks
like this:
synchronized (__queue)
{
while (__bytesAvailable = __queue.length - 1)
{
if(__threaded)
{
__queue.notify();
try
{
__queue.wait();
}
catch (InterruptedException e)
{
throw e;
}
}
...
}
If you get into this loop and the threaded flag is false, you are stuck
forever. That's what's happening in my case. If I suspend the thread, I can
see that (__bytesAvailable) is 2048 and (__queue.length -
1) is also 2048, so it's an infinite loop.
I'm not sure what triggers this, but it seems to happen most often when there
is a pause in server output or a pause before I initiate the next read.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-30) FTPClient deals badly with adverse network conditions
[ http://issues.apache.org/jira/browse/NET-30?page=all ] Rory Winston closed NET-30. --- FTPClient deals badly with adverse network conditions - Key: NET-30 URL: http://issues.apache.org/jira/browse/NET-30 Project: Commons Net Issue Type: Bug Environment: Operating System: Linux Platform: PC Reporter: Alain Knaff We are attempting to use the FTPClient included in commons-net 1.2.2 to write an application which has to deal with various outages: - connection closed by server, without 421 warning - connection frozen - server temporarily unreachable - ... However, it appears that in most of these cases, FTPClient becomes easily confused: - If the connection is closed without warning, FTPClient doesn't notice at first: ftp.isConnected() still returns true. However, when attempting to use such a closed connection, we do get the correct exception (FTPConnectionClosedException), at least most of the time (occasionnally we do get various SocketExceptions instead) - If the ftp server doesn't respond in time, FTPClient hangs forever, even after the ftp server responds eventually - If setSoTimeout is set, and if the server doesn't respond, the following behaviour happens: ** if the server becomes responsive again before the timeout happens, the client hangs until the timeout then receives SocketTimeoutException exception. We would prefer if the client just continued normally (as the server did respond before timeout) ** if on the other hand the server does not become responsive when the timeout happens, the client won't get any exception when timeout expires. Instead it will just hang. As soon as the server gets responsive again (i.e. _after_ the timeout had expired), the client immediately get the exception. We would prefer if the client got the exception at the timeout, rather than long afterwards. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (NET-142) FTPClient.listFiles() returns null for entries with space in group name
[ http://issues.apache.org/jira/browse/NET-142?page=all ]
Rory Winston resolved NET-142.
--
Fix Version/s: 2.0
Resolution: Cannot Reproduce
Hi Dmitry
I have tried the FTP entry that you gave me and the NTFTPEntryParser parses the
group name correctly (including spaces). Im not sure what the actual problem is
here - if you have any more info, please send it on.
FTPClient.listFiles() returns null for entries with space in group name
---
Key: NET-142
URL: http://issues.apache.org/jira/browse/NET-142
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Windows FTP server
Reporter: Dmitry Negoda
Fix For: 2.0
FTPClient fails parsing file list if the group name contains spaces, for
example Domain users in Windows. The following patch helps:
---
commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
Sat Dec 3 19:05:48 2005
+++
/u/ndv/sns_commons_io/src/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
Sat Sep 2 16:47:03 2006
@@ -21,6 +21,7 @@
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
+import java.util.Locale;
import java.util.TimeZone;
import org.apache.commons.net.ftp.Configurable;
@@ -98,9 +99,16 @@
if (parsed != null pp.getIndex() ==
timestampStr.length()) {
working.setTime(parsed);
} else {
- throw new ParseException(
- Timestamp could not be parsed with
older or recent DateFormat,
- pp.getIndex());
+ // H4cK3D by mAXm
+ SimpleDateFormat dmy = new
SimpleDateFormat(d MMM );
+ SimpleDateFormat dmh = new
SimpleDateFormat(d MMM HH:ss);
+
+ try {
+
working.setTime(dmh.parse(timestampStr));
+ working.set(Calendar.YEAR,
Calendar.getInstance().get(Calendar.YEAR));
+ } catch (ParseException ex) {
+
working.setTime(dmy.parse(timestampStr));
+ }
}
}
return working;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
[ http://issues.apache.org/jira/browse/NET-61?page=all ]
Rory Winston reopened NET-61:
-
Setting fix version to 2.0
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
Fix For: 2.0
A Java app that uses FTPClient to download a file from a website to Windows
XP
works properly. But, when the same app runs on Linux to download the same
file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
[ http://issues.apache.org/jira/browse/NET-61?page=all ]
Rory Winston resolved NET-61.
-
Fix Version/s: 2.0
Resolution: Fixed
Fix version is [net] 2.0
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
Fix For: 2.0
A Java app that uses FTPClient to download a file from a website to Windows
XP
works properly. But, when the same app runs on Linux to download the same
file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
[ http://issues.apache.org/jira/browse/NET-61?page=all ]
Rory Winston closed NET-61.
---
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
Fix For: 2.0
A Java app that uses FTPClient to download a file from a website to Windows
XP
works properly. But, when the same app runs on Linux to download the same
file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-145) Deadlock in TelnetInputStream
[ http://issues.apache.org/jira/browse/NET-145?page=all ]
Rory Winston closed NET-145.
Fix Version/s: 2.0
Resolution: Fixed
This issue is fixed in 2.0.
Deadlock in TelnetInputStream
-
Key: NET-145
URL: http://issues.apache.org/jira/browse/NET-145
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Heavy mutlithreaded environment using Jakarta VFS (which
uses Commons Net) for ftp file transfers
Reporter: Norbert Seekircher
Fix For: 2.0
Sometimes single threads of our application (each thread transfering data
from ftp servers) get locked forever. When monitoring our tool with JConsole,
I can see that such a thread usually hangs at
org.apache.commons.net.telnet.TelnetInputStream, line 339.
This line contains the statement
__queue.wait();
Unfortunately I haven't found a way to reproduce this issue, it just happens
about once a day (while running 24 hours and transfering about 5 files).
As a quick and dirty workaround: What do you think about replacing this line
with something like
long startTime = System.currentTimeMillis();
__queue.wait(6);
if ((System.currentTimeMillis() - startTime) 55000) {
throw new InterruptedException(Unknown strange and nasty blocker
detected);
}
So at least it would not just block the thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-146) wrong handling of timeouts
[ http://issues.apache.org/jira/browse/NET-146?page=all ] Rory Winston closed NET-146. Fix Version/s: 2.0 Resolution: Fixed Fixed in 2.0 branch. wrong handling of timeouts -- Key: NET-146 URL: http://issues.apache.org/jira/browse/NET-146 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Final Environment: linux 2.6, java 1.5.0_08 (but most probably any environment) Reporter: Koloom Fix For: 2.0 If you set a timeout on the control connection and then make a data transfer (upload, download) which takes longer than that timeout, the client throws the following exception. It seems like the client tries to read something from the control connection while the data transfer is in progress and then it just throws an exception. It makes the application think that the transfer failed even though it succeeded. aused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at java.io.FilterInputStream.read(FilterInputStream.java:66) at java.io.PushbackInputStream.read(PushbackInputStream.java:120) at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75) at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114) at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-65) [net] program hangs while trying to delete a file on a remote FTP Server after downloading same
[ http://issues.apache.org/jira/browse/NET-65?page=all ] Rory Winston closed NET-65. --- Fix Version/s: 2.0 Resolution: Fixed This is also related to the TelnetClient threading issue, which is fixed in 2.0. [net] program hangs while trying to delete a file on a remote FTP Server after downloading same --- Key: NET-65 URL: http://issues.apache.org/jira/browse/NET-65 Project: Commons Net Issue Type: Bug Affects Versions: 1.1.0 Environment: Operating System: other Platform: Other Reporter: Siddique Fix For: 2.0 I am using the commons-net-1.1.0.jar to perform FTP related activities. The process I am doing is as follows: 1. Logon to the remote FTP Server running on Solaris (which is behind a firewall) 2. Download a file 3. Delete the remote file after successful download But here I am facing a problem, once the file is downloaded, it does not get deleted in the remote FTP server and the program hangs. An interrupted IO Exception is being thrown and the program just hangs. Any suggestions will be appreciated -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-59) [net] NullpointerException on FTPClient.disconnect() if an Exception occured while FTPClient.connect
[ http://issues.apache.org/jira/browse/NET-59?page=all ] Rory Winston closed NET-59. --- Fix Version/s: 2.0 Resolution: Fixed Added null check in TelnetClient [net] NullpointerException on FTPClient.disconnect() if an Exception occured while FTPClient.connect Key: NET-59 URL: http://issues.apache.org/jira/browse/NET-59 Project: Commons Net Issue Type: Bug Affects Versions: 1.2 Final Environment: Operating System: All Platform: Other Reporter: Christian Hufgard Fix For: 2.0 Hello, think this bug is the same (or at least similiar) to the following one: http://issues.apache.org/bugzilla/show_bug.cgi?id=26296 but since I was not sure, I opened it as a seperate report. Versions affected: commons-net-1.2.2, think also commons-net-1.4.0 Problem: If an exception occures while FTPClient.connect() is running, a call to FTPClient.disconnect() in a finally-block might throw a NullPointerException. I am pretty shure, that this might cause some Threads so keep alive, also they cannot be interrupted anymore. Reason: This happens since TelnetClient.disconnect() does not check whether the Streams (__input and __ouput) it tries to close are NULL or not. Normally it is sufficent to check FTPClient.isConnected(), but if a exceptions is thrown after SocketClient.__connectAction_ has been excecuted, SocketClient. _isConnected_ is set to true, so the check will indicate that the connection is alive. Christian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-84) [net] TelnetClient#disconnect() causes NullPointerException from Linux when connected to Windows 2000 Telnet Server
[ http://issues.apache.org/jira/browse/NET-84?page=all ] Rory Winston closed NET-84. --- Fix Version/s: 2.0 Resolution: Fixed Fixed in 2.0 [net] TelnetClient#disconnect() causes NullPointerException from Linux when connected to Windows 2000 Telnet Server --- Key: NET-84 URL: http://issues.apache.org/jira/browse/NET-84 Project: Commons Net Issue Type: Bug Affects Versions: 1.1.0 Environment: Operating System: Linux Platform: PC Reporter: Clark E. Archer Fix For: 2.0 Attachments: disconnect_npe_patch.txt When calling TelnetClient#disconnect(), a NullPointerException is thrown because either __input or __output is already null. After fixing my working copy of the source, an additional NPE is thrown in SocketClient#disconnect() because the _socket_ variable is already null. I've patched both files to check for null of the affected intasnce variables before calling the close() methods and will be submitting a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Commons-Net 2.0?
Hi guys I know I have gone through the voting process a while back, but there have been many more changed added in to the 2.0 branch of [net] since then. I also remembered that the concept of a JDK 5.0+ only release got a somewhat lukewarm reception at the time, but sparked a lot of constructive dialogue on the topic. Soif I leave this vote thread open for 24 hours or so, I can attempt to release at the end of the week if it passes. The changes are here: http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0 Artefacts are available here: http://people.apache.org/~rwinston/commons-net-2.0/ So please, give it your relevant +1, +0, -0, -1. - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons-Net 2.0?
Niall Thanks a lot for this very helpful and comprehensive list. I was actually going to leave most of the release admin stuff until after the vote, but that does not seem like a good idea now :-). A couple of things had passed me by, the license changes being one. I'll get cracking on this and update the RC asap. Thanks again Rory Niall Pemberton wrote: Hi Rory, Voting threads are usually +72 hours and we should only deviate from that if theres a good reason IMO. I have the following comments on the release: 1) ASF Source Header and Copyright Notice Policy The release needs to conform to the new ASF policy. Henri used a script to update most of commons, but I think this got missed because you're releasing from a branch? http://www.apache.org/legal/src-headers.html (N.B. As well as source file headers the NOTICE.txt also needs updating for this). 2) Tagging the Release Candidate Can you tag the release candidate in subversion - svn tags are cheap and it clearly defines where the release has been cut from - more important IMO if your doing it from a branch. Also when preparing the RC its a good idea to check out a fresh copy from the tag - which ensures that any local crud doesn't get accidentally included. 3) Both jar files don't include the LICENSE file 4) commons-net-2.0.0-SNAPSHOT.jar manifest is missing the following elements: Extension-Name Specification-Title Specification-Vendor Specification-Version Implementation-Title Implementation-Vendor Implementation-Version Implementation-Vendor-Id 5) commons-net-ftp-2.0.0-SNAPSHOT.jar manifest is missing the following elements: Implementation-Title Implementation-Vendor Implementation-Version Implementation-Vendor-Id 6) The binary distro doesn't include release notes - most components include a RELEASE-NOTES.txt file, even if it only refers to maven's changes-report 7) The binary distro doesn't include any docs - we usually at least include the javadoc. 8) The pom.xml doesn't inherit from commons-parent 9) The source distro looks like its missing a few files that are in the JDK_1_5_BRANCH (assembly-bin.xml, assembly-src.xml, project.properties - which also should have license headers) 10) The following source files are missing headers: src\main\java\examples\NetClient.java src\main\java\examples\nntp\NNTPUtils.java src\main\java\org\apache\commons\net\nntp\Article.java src\test\java\org\apache\commons\net\ftp\parser\AllTests.java src\test\java\org\apache\commons\net\ntp\TimeStampTest.java src\test\java\org\apache\commons\net\time\TimeTCPClientTest.java src\test\java\org\apache\commons\net\time\TimeTestSimpleServer.java 11) On the site: - mail archives are pointing to eyebrowse (this would be fixed if inherited from commons-parent pom) - project summary has invalid url for commons net home page - source repository page points to the trunk - but looks to me like its built from the branch - download page just points to the general Jakarta downloads - rather than the net specific one: http://jakarta.apache.org/site/downloads/downloads_commons-net.cgi Since this version has move to JDK 1.5 there isn't binary compatibility with previous releases, but besides moving to JDK 1.5 is it otherwise compatible with previous releases? If this is now the main focus of development - shouldn't a branch be created for whats in the current trunk and this JDK 1.5 branch merged into the trunk - or are there still people actively developing the pre-jdk1.5 version? Just as a note, there are quite a few docs on releases that help avoid some of the pitfalls and are worth using for both a RC and actually cutting the release: http://jakarta.apache.org/commons/releases/index.html http://wiki.apache.org/jakarta-commons/ReleaseChecking http://wiki.apache.org/jakarta-commons/ReleaseShoppingList Niall On 12/20/06, Rory Winston [EMAIL PROTECTED] wrote: Hi guys I know I have gone through the voting process a while back, but there have been many more changed added in to the 2.0 branch of [net] since then. I also remembered that the concept of a JDK 5.0+ only release got a somewhat lukewarm reception at the time, but sparked a lot of constructive dialogue on the topic. Soif I leave this vote thread open for 24 hours or so, I can attempt to release at the end of the week if it passes. The changes are here: http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0 Artefacts are available here: http://people.apache.org/~rwinston/commons-net-2.0/ So please, give it your relevant +1, +0, -0, -1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Luc Maisonobe as Jakarta Commons committer
+1 Oliver Heger wrote: +1 Oliver Phil Steitz wrote: I would like to nominate Luc Maisonobe as a Jakarta Commons committer. Luc has made a major contribution to commons-math in the Mantissa library and has also contributed to discussion and Jira tickets related to other parts of [math]. His openness to feedback and diligence in resolving IP-related issues as we went through the incubator IP clearance process demonstrated his commitment to open development @apache. I think Luc will make a great addition to the apache committer community. Here is my +1. Votes, please. This vote will close end of (GMT) day, 23-Dec-06. Thanks! Phil 8--- [ ] +1 Let him commit! [ ] +0 [ ] -0 [ ] -1 No, because... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
[ http://issues.apache.org/jira/browse/NET-61?page=comments#action_12459470
]
Rory Winston commented on NET-61:
-
Hi Ross (and anyone else interested in this issue)
Can you try the latest RC:
http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHOT.jar
It requires Java 5.0. This hopefully may fix the issues you are seeing.
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
A Java app that uses FTPClient to download a file from a website to Windows
XP
works properly. But, when the same app runs on Linux to download the same
file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-146) wrong handling of timeouts
[ http://issues.apache.org/jira/browse/NET-146?page=comments#action_12459476 ] Rory Winston commented on NET-146: -- Hi Can you post the code where you are setting the timeout? I cant reproduce the problem... Have you tried the latest RC of net-2.0 ? You can find it here: http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHOT.jar wrong handling of timeouts -- Key: NET-146 URL: http://issues.apache.org/jira/browse/NET-146 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Final Environment: linux 2.6, java 1.5.0_08 (but most probably any environment) Reporter: Koloom If you set a timeout on the control connection and then make a data transfer (upload, download) which takes longer than that timeout, the client throws the following exception. It seems like the client tries to read something from the control connection while the data transfer is in progress and then it just throws an exception. It makes the application think that the transfer failed even though it succeeded. aused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at java.io.FilterInputStream.read(FilterInputStream.java:66) at java.io.PushbackInputStream.read(PushbackInputStream.java:120) at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75) at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114) at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
[ http://issues.apache.org/jira/browse/NET-61?page=comments#action_12459495
]
Rory Winston commented on NET-61:
-
Hi Ross
Am uploading a new version with some fixes which should hopefully solve your
problems. There were indeed a couple of issues there. Give it a while (slow SSH
upload) and then download the new jar at the same location:
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
A Java app that uses FTPClient to download a file from a website to Windows
XP
works properly. But, when the same app runs on Linux to download the same
file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
[ http://issues.apache.org/jira/browse/NET-61?page=comments#action_12459496
]
Rory Winston commented on NET-61:
-
Forgot to say the link is the same as the previous one:
http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHOT.jar
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
A Java app that uses FTPClient to download a file from a website to Windows
XP
works properly. But, when the same app runs on Linux to download the same
file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: enhancements needed for the OS/400 parser?
Hi Henrik You can just make the changes locally and send me a patch if you like (or the entire file) Cheers Rory [EMAIL PROTECTED] wrote: On Tuesday 05 December 2006 21:52, Rory Winston wrote: Hi Henrik Actually the parser is under the 2.0 branch here: http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BR ANCH/src/main/java/org/apache/commons/net/ftp/parser/MVSFTPEntryParser.java? revision=439598view=markup And the test is here: http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BR ANCH/src/test/java/org/apache/commons/net/ftp/parser/MVSFTPEntryParserTest.j ava?revision=439615view=markup Cheers Rory thanks for the new links. I just looked at the links and some of the comments have been reformatted in way that makes them had to read, for example: /** * Matches these entries: Volume Unit Referred Ext Used Recfm Lrecl BlkSz * Dsorg Dsname B10142 3390 2006/03/20 2 31 F 80 80 PS MDI.OKL.WORK * */ should really have been: /** * Matches these entries: * Volume Unit Referred Ext Used Recfm Lrecl BlkSz Dsorg Dsname * B10142 3390 2006/03/20 2 31 F 8080PSMDI.OKL.WORK * */ it might seem a bit weird, but the data is really formatted that way. Which javadoc tricks can be used to achieve this ? I don't mind go through all the comments again and fix it. Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enhancements needed for the OS/400 parser?
Hi Daniel No problem. Any submissions welcome. Thanks Rory Daniel Manley wrote: Hi Rory, I don't know much about OS/400, OS/390 or MVS. I would feel more comfortable submitting a patch to the OS/400 parser and let you guys figure out if this is applicable to OS/390 or MVS. Dan Rory Winston wrote: Hi Daniel You're the second person to raise the issue about swallowing exceptions in less than a week, so maybe there is something that we can look at there. Possibly we could have a configurable fail-fast policy for parsing directory entries. On the subject of the OS/400 parser, if there are changes you have made to get this to work, and if you (and/or your employer) are happy to donate them to the project, I would be happy to incorporate them into the existing OS/400 parser implementation in [net], giving you due credit, of course. Best regards Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Hi all, I've been using commons-net for FTP for about two years now. It's been great and we love it (we = the company at which I work). But recently our systems have had to interface with an OS/400-based FTP server. It's been a lot of trouble. First, the default date format didn't match what the server was sending (dd/MM/yy instead of the default yy/MM/dd). Second, the OS/400 parser only understands the *STMF and *DIR types. But the server I'm working with has a *FILE type. Additionally, there's a *MEM type too. Which leads me to the third problem: each file listing seems to be in two lines. One as *FILE and the other as *MEM. But the *MEM lines don't include size or timestamp. This results in a null being returned from parseEntry() (because the REGEX doesn't match). When null is returned, the parsing is aborted. As a result, I would only ever see the first file alphabetically in a listFiles() call. To solve my problem without hacking/customizing the commons-net 1.4.1 jar, I subclassed the OS/400 parser to try parsing with two REGEX values. Could I suggest changing the core of file entry parsing to not give up when it gets a null back, but rather to give up when the listing data stream is done reading? Any null's return by parseEntry() should be skipped. At the least, an exception should be thrown to indicate incompatible FTP listing data. But, I also discovered that if there's an exception in parsing (null pointer, runtime, etc), commons-net catches this exception and quietly returns. IMHO, this should be floated up to the caller to be aware of a problem in parsing the FTP data. Cheers, Dan === here's some debug I put into commons-net to discover what was being read from the server. the line read was [CFT 45056 04/12/06 14:19:31 *FILE AFTFRE1.FILE] the line read was [CFT *MEM AFTFRE1.FILE/AFTFRE1.MBR] the line read was [CFT 36864 28/11/06 15:19:30 *FILE AFTFRE2.FILE] the line read was [CFT *MEM AFTFRE2.FILE/AFTFRE2.MBR] the line read was [CFT 45056 04/12/06 14:19:37 *FILE AFTFRE6.FILE] the line read was [CFT *MEM AFTFRE6.FILE/AFTFRE6.MBR] the line read was [QSYSOPR 28672 01/12/06 20:08:04 *FILE FPKI45POK5.FILE] the line read was [QSYSOPR *MEM FPKI45POK5.FILE/FPKI45POK5.MBR] the line read was [null] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-142) FTPClient.listFiles() returns null for entries with space in group name
[
http://issues.apache.org/jira/browse/NET-142?page=comments#action_12455944 ]
Rory Winston commented on NET-142:
--
Dmitry
Can you provide an example of the listing output from the Windows server, with
spaces in the group names?
FTPClient.listFiles() returns null for entries with space in group name
---
Key: NET-142
URL: http://issues.apache.org/jira/browse/NET-142
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Windows FTP server
Reporter: Dmitry Negoda
FTPClient fails parsing file list if the group name contains spaces, for
example Domain users in Windows. The following patch helps:
---
commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
Sat Dec 3 19:05:48 2005
+++
/u/ndv/sns_commons_io/src/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
Sat Sep 2 16:47:03 2006
@@ -21,6 +21,7 @@
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
+import java.util.Locale;
import java.util.TimeZone;
import org.apache.commons.net.ftp.Configurable;
@@ -98,9 +99,16 @@
if (parsed != null pp.getIndex() ==
timestampStr.length()) {
working.setTime(parsed);
} else {
- throw new ParseException(
- Timestamp could not be parsed with
older or recent DateFormat,
- pp.getIndex());
+ // H4cK3D by mAXm
+ SimpleDateFormat dmy = new
SimpleDateFormat(d MMM );
+ SimpleDateFormat dmh = new
SimpleDateFormat(d MMM HH:ss);
+
+ try {
+
working.setTime(dmh.parse(timestampStr));
+ working.set(Calendar.YEAR,
Calendar.getInstance().get(Calendar.YEAR));
+ } catch (ParseException ex) {
+
working.setTime(dmy.parse(timestampStr));
+ }
}
}
return working;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-99) [net] MVSFTPEntryParser.java only halfway implemented
[ http://issues.apache.org/jira/browse/NET-99?page=all ] Rory Winston closed NET-99. --- Resolution: Fixed Fixed in 2.0 [net] MVSFTPEntryParser.java only halfway implemented - Key: NET-99 URL: http://issues.apache.org/jira/browse/NET-99 Project: Commons Net Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: henrik Attachments: FTPParseTestFramework.java, FTPParseTestFramework.java, MVSFTPEntryParser.java, MVSFTPEntryParser.java, MVSFTPEntryParser.java, MVSFTPEntryParser.java, MVSFTPEntryParser.java, MVSFTPEntryParser.java, MVSFTPEntryParser.java, MVSFTPEntryParserTest.java, MVSFTPEntryParserTest.java, RegexFTPFileEntryParserImpl.java I have been chasing some bugs when using the ant ftp task, and some problems stem from the parsing of the result of the ftp list command. The file structure of MVS is not a hierarchical filesystem, but it has a directory concept known as partition organized datasets. These can be compared to a single level directory. The current parser does not take these into account. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] releases
I'm hoping to push a [net] release out by xmas...too busy at the moment to look at it, but will have some free time in a couple of weeks. R Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: On 12/4/06, Henri Yandell [EMAIL PROTECTED] wrote: Updating this thread; Digester, DbUtils, FileUpload and Discovery are now all released. That leaves us with: * Logging 1.1.1 - I see 3 fixed issues in JIRA and nothing left to do. However there are 7 issues without a version which might mean they've not been looked at. * IO 1.3 - 1 issue to be resolved and then we can release. * FileUpload 1.2 - 1 issue to be resolved - blocked by IO 1.3. 7 unversioned. * Betwixt 0.8 - In the release process. Versions don't seem to be actively used in JIRA. BeanUtils is a fair way away, SCXML sounds like it'll be in a couple of months, Lang needs to decide if it should target 2.3 or 3.0 and start churning. DBCP 1.2.2 sounds like it getting closer and closer, 1 issue in 1.2.2, but 11 still unscheduled. Afaik, Pool is at the revolution stage, unless DBCP requires a minor release. I am cleaning up in prep for DBCP 1.2.2 - the only remaining issue will be closed when the release is cut, since it is just dropping collections dependency. I also need to either get a brilliant idea on the deadlock bugs now pushed to 1.3 (probably using new [pool] impl) or figure out a way to add appropriate warnings to the doc and release notes. Any others getting close? Validator and DbUtils are now back at the beginning of new dev releases. Discovery and Attributes are 6 foot under (I hope :) ). [off on a tangent] The unversioned-and-possibly-not-looked-at bit above is due to how I'm reading the JIRA projects. An issue coming in has 4 possible answers: 1) Put it in the currently working on version. 2) Put it in the next version. This is an acknowledgement that it's a problem, or that it's an enhancement that shows merit; but not a guarantee that it will go in that version. It's both 'next version' and 'someday'. Comments to the effect of unit-test + patch and we can push it up to [current-version] might be suitable. 3) Say No by resolving it wontfix etc. 4) Comment. This is a conversation with the aim of achieving one of 1, 2 or 3. I think this is a very low-energy, high-return way to manage our components. The problem that I keep running into when I try to do this is that it takes a fair amount of work to distinguish between 2) and 3) or to meaningfully do 4). Could be I am just slow. I agree that getting some kind of response is good. I am not sure I agree, however, with trying to jump to assigning fix versions before doing some work to understand what the issue is, or if there is in fact an issue at all. I just bounced a [dbcp] issue to OJB, for example, after spending a little time figuring out that it was in fact the [pool] config doing what OJB set it up to do by default that was causing the user problem. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] releases
I'm hoping to push a [net] release out by xmas...too busy at the moment to look at it, but will have some free time in a couple of weeks. R Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: On 12/4/06, Henri Yandell [EMAIL PROTECTED] wrote: Updating this thread; Digester, DbUtils, FileUpload and Discovery are now all released. That leaves us with: * Logging 1.1.1 - I see 3 fixed issues in JIRA and nothing left to do. However there are 7 issues without a version which might mean they've not been looked at. * IO 1.3 - 1 issue to be resolved and then we can release. * FileUpload 1.2 - 1 issue to be resolved - blocked by IO 1.3. 7 unversioned. * Betwixt 0.8 - In the release process. Versions don't seem to be actively used in JIRA. BeanUtils is a fair way away, SCXML sounds like it'll be in a couple of months, Lang needs to decide if it should target 2.3 or 3.0 and start churning. DBCP 1.2.2 sounds like it getting closer and closer, 1 issue in 1.2.2, but 11 still unscheduled. Afaik, Pool is at the revolution stage, unless DBCP requires a minor release. I am cleaning up in prep for DBCP 1.2.2 - the only remaining issue will be closed when the release is cut, since it is just dropping collections dependency. I also need to either get a brilliant idea on the deadlock bugs now pushed to 1.3 (probably using new [pool] impl) or figure out a way to add appropriate warnings to the doc and release notes. Any others getting close? Validator and DbUtils are now back at the beginning of new dev releases. Discovery and Attributes are 6 foot under (I hope :) ). [off on a tangent] The unversioned-and-possibly-not-looked-at bit above is due to how I'm reading the JIRA projects. An issue coming in has 4 possible answers: 1) Put it in the currently working on version. 2) Put it in the next version. This is an acknowledgement that it's a problem, or that it's an enhancement that shows merit; but not a guarantee that it will go in that version. It's both 'next version' and 'someday'. Comments to the effect of unit-test + patch and we can push it up to [current-version] might be suitable. 3) Say No by resolving it wontfix etc. 4) Comment. This is a conversation with the aim of achieving one of 1, 2 or 3. I think this is a very low-energy, high-return way to manage our components. The problem that I keep running into when I try to do this is that it takes a fair amount of work to distinguish between 2) and 3) or to meaningfully do 4). Could be I am just slow. I agree that getting some kind of response is good. I am not sure I agree, however, with trying to jump to assigning fix versions before doing some work to understand what the issue is, or if there is in fact an issue at all. I just bounced a [dbcp] issue to OJB, for example, after spending a little time figuring out that it was in fact the [pool] config doing what OJB set it up to do by default that was causing the user problem. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enhancements needed for the OS/400 parser?
Hi Daniel You're the second person to raise the issue about swallowing exceptions in less than a week, so maybe there is something that we can look at there. Possibly we could have a configurable fail-fast policy for parsing directory entries. On the subject of the OS/400 parser, if there are changes you have made to get this to work, and if you (and/or your employer) are happy to donate them to the project, I would be happy to incorporate them into the existing OS/400 parser implementation in [net], giving you due credit, of course. Best regards Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Hi all, I've been using commons-net for FTP for about two years now. It's been great and we love it (we = the company at which I work). But recently our systems have had to interface with an OS/400-based FTP server. It's been a lot of trouble. First, the default date format didn't match what the server was sending (dd/MM/yy instead of the default yy/MM/dd). Second, the OS/400 parser only understands the *STMF and *DIR types. But the server I'm working with has a *FILE type. Additionally, there's a *MEM type too. Which leads me to the third problem: each file listing seems to be in two lines. One as *FILE and the other as *MEM. But the *MEM lines don't include size or timestamp. This results in a null being returned from parseEntry() (because the REGEX doesn't match). When null is returned, the parsing is aborted. As a result, I would only ever see the first file alphabetically in a listFiles() call. To solve my problem without hacking/customizing the commons-net 1.4.1 jar, I subclassed the OS/400 parser to try parsing with two REGEX values. Could I suggest changing the core of file entry parsing to not give up when it gets a null back, but rather to give up when the listing data stream is done reading? Any null's return by parseEntry() should be skipped. At the least, an exception should be thrown to indicate incompatible FTP listing data. But, I also discovered that if there's an exception in parsing (null pointer, runtime, etc), commons-net catches this exception and quietly returns. IMHO, this should be floated up to the caller to be aware of a problem in parsing the FTP data. Cheers, Dan === here's some debug I put into commons-net to discover what was being read from the server. the line read was [CFT 45056 04/12/06 14:19:31 *FILE AFTFRE1.FILE] the line read was [CFT *MEM AFTFRE1.FILE/AFTFRE1.MBR] the line read was [CFT 36864 28/11/06 15:19:30 *FILE AFTFRE2.FILE] the line read was [CFT *MEM AFTFRE2.FILE/AFTFRE2.MBR] the line read was [CFT 45056 04/12/06 14:19:37 *FILE AFTFRE6.FILE] the line read was [CFT *MEM AFTFRE6.FILE/AFTFRE6.MBR] the line read was [QSYSOPR 28672 01/12/06 20:08:04 *FILE FPKI45POK5.FILE] the line read was [QSYSOPR *MEM FPKI45POK5.FILE/FPKI45POK5.MBR] the line read was [null] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enhancements needed for the OS/400 parser?
Hi Daniel You're the second person to raise the issue about swallowing exceptions in less than a week, so maybe there is something that we can look at there. Possibly we could have a configurable fail-fast policy for parsing directory entries. On the subject of the OS/400 parser, if there are changes you have made to get this to work, and if you (and/or your employer) are happy to donate them to the project, I would be happy to incorporate them into the existing OS/400 parser implementation in [net], giving you due credit, of course. Best regards Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Hi all, I've been using commons-net for FTP for about two years now. It's been great and we love it (we = the company at which I work). But recently our systems have had to interface with an OS/400-based FTP server. It's been a lot of trouble. First, the default date format didn't match what the server was sending (dd/MM/yy instead of the default yy/MM/dd). Second, the OS/400 parser only understands the *STMF and *DIR types. But the server I'm working with has a *FILE type. Additionally, there's a *MEM type too. Which leads me to the third problem: each file listing seems to be in two lines. One as *FILE and the other as *MEM. But the *MEM lines don't include size or timestamp. This results in a null being returned from parseEntry() (because the REGEX doesn't match). When null is returned, the parsing is aborted. As a result, I would only ever see the first file alphabetically in a listFiles() call. To solve my problem without hacking/customizing the commons-net 1.4.1 jar, I subclassed the OS/400 parser to try parsing with two REGEX values. Could I suggest changing the core of file entry parsing to not give up when it gets a null back, but rather to give up when the listing data stream is done reading? Any null's return by parseEntry() should be skipped. At the least, an exception should be thrown to indicate incompatible FTP listing data. But, I also discovered that if there's an exception in parsing (null pointer, runtime, etc), commons-net catches this exception and quietly returns. IMHO, this should be floated up to the caller to be aware of a problem in parsing the FTP data. Cheers, Dan === here's some debug I put into commons-net to discover what was being read from the server. the line read was [CFT 45056 04/12/06 14:19:31 *FILE AFTFRE1.FILE] the line read was [CFT *MEM AFTFRE1.FILE/AFTFRE1.MBR] the line read was [CFT 36864 28/11/06 15:19:30 *FILE AFTFRE2.FILE] the line read was [CFT *MEM AFTFRE2.FILE/AFTFRE2.MBR] the line read was [CFT 45056 04/12/06 14:19:37 *FILE AFTFRE6.FILE] the line read was [CFT *MEM AFTFRE6.FILE/AFTFRE6.MBR] the line read was [QSYSOPR 28672 01/12/06 20:08:04 *FILE FPKI45POK5.FILE] the line read was [QSYSOPR *MEM FPKI45POK5.FILE/FPKI45POK5.MBR] the line read was [null] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enhancements needed for the OS/400 parser?
Hi Henrik Actually the parser is under the 2.0 branch here: http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/org/apache/commons/net/ftp/parser/MVSFTPEntryParser.java?revision=439598view=markup And the test is here: http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/test/java/org/apache/commons/net/ftp/parser/MVSFTPEntryParserTest.java?revision=439615view=markup Cheers Rory [EMAIL PROTECTED] wrote: On Tuesday 05 December 2006 16:37, Daniel Manley wrote: To solve my problem without hacking/customizing the commons-net 1.4.1 jar, I subclassed the OS/400 parser to try parsing with two REGEX values. you can see how it is done for a OS/390 parser. There I also had to create different REGEXes. The changes are in the CVS for the upcomming commons-net 2.0 Code: http://svn.apache.org/viewvc/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/parser/MVSFTPEntryParser.java Test cases: http://svn.apache.org/viewvc/jakarta/commons/proper/net/trunk/src/test/org/apache/commons/net/ftp/parser/MVSFTPEntryParserTest.java good luck. Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTPSClient error when downloading zip files on windows
Susanne
Do these files d/load OK with another FTP client?
Cheers
Rory
Susanne Lefvert wrote:
An additional note: this happens even if I disable ssl (ie reconfigure
the ftp server and use FTPClient).
Susanne
On Dec 5, 2006, at 2:36 PM, Susanne Lefvert wrote:
Hello!
I'm having problems downloading zip files using the FTPSClient with
the apache ftp server. It works fine on Mac clients but not windows
clients.
Here's the test code (replace *** with your info):
public class testFTP{
private FTPSClient ftps;
public testFTP(){
try{
String host = ***;
int port = ***;
String zipname = CompleteProject.zip;
ftps = new FTPSClient(true);
ftps.connect(host,port);
System.out.println(ftps.getReplyString());
ftps.setFileType(FTP.BINARY_FILE_TYPE);
ftps.login(***, ***);
System.out.println(Remote system is + ftps.getSystemName());
ftps.enterLocalPassiveMode();
FileOutputStream output=new FileOutputStream(new File(zipname));
boolean result = ftps.retrieveFile(zipname,output);
if (!result) {
System.out.println(Error retrieving file);
}
ftps.disconnect();
}
catch(Exception e){
System.out.println(An error occured);
}
}
public static void main(String args[]){
testFTP f= new testFTP();
}
}
Here's the error I'm getting when trying to unzip the result from the
test code above:
$ unzip CompleteProject.zip
Archive: CompleteProject.zip
warning [CompleteProject.zip]: 49109 extra bytes at beginning or
within zipfile
(attempting to process anyway)
file #1: bad zipfile offset (local header sig): 49109
(attempting to re-compensate)
inflating: CompleteProject.eaf
error: invalid compressed data to inflate
file #2: bad zipfile offset (local header sig): 2036
(attempting to re-compensate)
file #2: bad zipfile offset (local header sig): 2036
file #3: bad zipfile offset (local header sig): 7225427
file #4: bad zipfile offset (local header sig): 13119171
file #5: bad zipfile offset (local header sig): 13312603
inflating: CompleteProject_MetaData.xml
Any hints appreciated!
Thanks,
Susanne
On Oct 4, 2006, at 4:50 PM, Rory Winston wrote:
Hi Susanne
TLS support is in the works, but has not made it into an official
release yet. If you are using JDK 5.0, you can try out a snapshot of
the new release here:
http://people.apache.org/~rwinston/commons-net-2.0/
An example of usage is here:
http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/examples/FTPSExample.java?view=markup
Cheers
Rory
Susanne Lefvert wrote:
Hi there,
Do you know if there are any examples out there where the commons
ftp client has been extended to support TLS. I need to connect to
an ftp server that requires SSL and I'm looking for a ftp client
library that I can use in my application. The apache commons ftp
client looks really good, it's just missing the TLS piece. Any
hints greatly appreciated.
Thanks,
Susanne
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTPSClient error when downloading zip files on windows
Weird. Not sure why that would be. I'll take a look.
Rory
Susanne Lefvert wrote:
Never mind, I think I figured it out. I have to set the binary flag
after the enterlocalpassivemode call
On Dec 5, 2006, at 3:37 PM, Susanne Lefvert wrote:
An additional note: this happens even if I disable ssl (ie
reconfigure the ftp server and use FTPClient).
Susanne
On Dec 5, 2006, at 2:36 PM, Susanne Lefvert wrote:
Hello!
I'm having problems downloading zip files using the FTPSClient with
the apache ftp server. It works fine on Mac clients but not windows
clients.
Here's the test code (replace *** with your info):
public class testFTP{
private FTPSClient ftps;
public testFTP(){
try{
String host = ***;
int port = ***;
String zipname = CompleteProject.zip;
ftps = new FTPSClient(true);
ftps.connect(host,port);
System.out.println(ftps.getReplyString());
ftps.setFileType(FTP.BINARY_FILE_TYPE);
ftps.login(***, ***);
System.out.println(Remote system is + ftps.getSystemName());
ftps.enterLocalPassiveMode();
FileOutputStream output=new FileOutputStream(new
File(zipname));
boolean result = ftps.retrieveFile(zipname,output);
if (!result) {
System.out.println(Error retrieving file);
}
ftps.disconnect();
}
catch(Exception e){
System.out.println(An error occured);
}
}
public static void main(String args[]){
testFTP f= new testFTP();
}
}
Here's the error I'm getting when trying to unzip the result from
the test code above:
$ unzip CompleteProject.zip
Archive: CompleteProject.zip
warning [CompleteProject.zip]: 49109 extra bytes at beginning or
within zipfile
(attempting to process anyway)
file #1: bad zipfile offset (local header sig): 49109
(attempting to re-compensate)
inflating: CompleteProject.eaf
error: invalid compressed data to inflate
file #2: bad zipfile offset (local header sig): 2036
(attempting to re-compensate)
file #2: bad zipfile offset (local header sig): 2036
file #3: bad zipfile offset (local header sig): 7225427
file #4: bad zipfile offset (local header sig): 13119171
file #5: bad zipfile offset (local header sig): 13312603
inflating: CompleteProject_MetaData.xml
Any hints appreciated!
Thanks,
Susanne
On Oct 4, 2006, at 4:50 PM, Rory Winston wrote:
Hi Susanne
TLS support is in the works, but has not made it into an official
release yet. If you are using JDK 5.0, you can try out a snapshot
of the new release here:
http://people.apache.org/~rwinston/commons-net-2.0/
An example of usage is here:
http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/examples/FTPSExample.java?view=markup
Cheers
Rory
Susanne Lefvert wrote:
Hi there,
Do you know if there are any examples out there where the commons
ftp client has been extended to support TLS. I need to connect to
an ftp server that requires SSL and I'm looking for a ftp client
library that I can use in my application. The apache commons ftp
client looks really good, it's just missing the TLS piece. Any
hints greatly appreciated.
Thanks,
Susanne
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTPSClient error when downloading zip files on windows
Susanne
I couldn't replicate this - I suspect it might be a peculiarity of the
FTP server you are using. Which server is it?
Cheers
Rory
Susanne Lefvert wrote:
Never mind, I think I figured it out. I have to set the binary flag
after the enterlocalpassivemode call
On Dec 5, 2006, at 3:37 PM, Susanne Lefvert wrote:
An additional note: this happens even if I disable ssl (ie
reconfigure the ftp server and use FTPClient).
Susanne
On Dec 5, 2006, at 2:36 PM, Susanne Lefvert wrote:
Hello!
I'm having problems downloading zip files using the FTPSClient with
the apache ftp server. It works fine on Mac clients but not windows
clients.
Here's the test code (replace *** with your info):
public class testFTP{
private FTPSClient ftps;
public testFTP(){
try{
String host = ***;
int port = ***;
String zipname = CompleteProject.zip;
ftps = new FTPSClient(true);
ftps.connect(host,port);
System.out.println(ftps.getReplyString());
ftps.setFileType(FTP.BINARY_FILE_TYPE);
ftps.login(***, ***);
System.out.println(Remote system is + ftps.getSystemName());
ftps.enterLocalPassiveMode();
FileOutputStream output=new FileOutputStream(new
File(zipname));
boolean result = ftps.retrieveFile(zipname,output);
if (!result) {
System.out.println(Error retrieving file);
}
ftps.disconnect();
}
catch(Exception e){
System.out.println(An error occured);
}
}
public static void main(String args[]){
testFTP f= new testFTP();
}
}
Here's the error I'm getting when trying to unzip the result from
the test code above:
$ unzip CompleteProject.zip
Archive: CompleteProject.zip
warning [CompleteProject.zip]: 49109 extra bytes at beginning or
within zipfile
(attempting to process anyway)
file #1: bad zipfile offset (local header sig): 49109
(attempting to re-compensate)
inflating: CompleteProject.eaf
error: invalid compressed data to inflate
file #2: bad zipfile offset (local header sig): 2036
(attempting to re-compensate)
file #2: bad zipfile offset (local header sig): 2036
file #3: bad zipfile offset (local header sig): 7225427
file #4: bad zipfile offset (local header sig): 13119171
file #5: bad zipfile offset (local header sig): 13312603
inflating: CompleteProject_MetaData.xml
Any hints appreciated!
Thanks,
Susanne
On Oct 4, 2006, at 4:50 PM, Rory Winston wrote:
Hi Susanne
TLS support is in the works, but has not made it into an official
release yet. If you are using JDK 5.0, you can try out a snapshot
of the new release here:
http://people.apache.org/~rwinston/commons-net-2.0/
An example of usage is here:
http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/examples/FTPSExample.java?view=markup
Cheers
Rory
Susanne Lefvert wrote:
Hi there,
Do you know if there are any examples out there where the commons
ftp client has been extended to support TLS. I need to connect to
an ftp server that requires SSL and I'm looking for a ftp client
library that I can use in my application. The apache commons ftp
client looks really good, it's just missing the TLS piece. Any
hints greatly appreciated.
Thanks,
Susanne
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-143) FTPClient.listFiles(String pathname) returns no entry on RH AS 4
[
http://issues.apache.org/jira/browse/NET-143?page=comments#action_12455831 ]
Rory Winston commented on NET-143:
--
Can you provide an output trace of the FTP conversation (using a
PrintCommandListener)?
FTPClient.listFiles(String pathname) returns no entry on RH AS 4
Key: NET-143
URL: http://issues.apache.org/jira/browse/NET-143
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: RedHat AS 4
Reporter: Felix Wong
The following code snippet works fine on RedHat AS 3 ftp server. However, it
only works on the top level of a RedHat AS 4 ftp server (e.g.
ftp://myftpserver) but not on any subdirectory.
ftpClient.listFiles(url.getPath()) return an empty array on any subdirectory
(e.g. ftp://myftpserver/abc).
URL url = new URL(urlString);
FTPClient ftpClient = new FTPClient();
FTPFile[] ftpFiles;
ftpClient.connect(url.getHost());
ftpClient.login(username, password);
int rc = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(rc)) {
throw new Exception(ftpClient.getReplyString());
}
ftpFiles = ftpClient.listFiles(url.getPath());
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (NET-141) Add connection timeout support to SocketClient and/or SocketFactory/DefaultSocketFactory
[ http://issues.apache.org/jira/browse/NET-141?page=all ] Rory Winston resolved NET-141. -- Resolution: Fixed Added in 2.0. Add connection timeout support to SocketClient and/or SocketFactory/DefaultSocketFactory Key: NET-141 URL: http://issues.apache.org/jira/browse/NET-141 Project: Commons Net Issue Type: Improvement Affects Versions: 1.4 Final Reporter: Christian Hufgard Assigned To: Daniel Savarese Fix For: 2.0 Attachments: CustomSocketFactory.java Hi, If executing the following code String hostname = localhost; FTPClient client = new FTPClient(); client.setDefaultTimeout(1000); client.connect(hostname); against a ftp server that ignores the connection attempt (e.g. is firewalled/malfunctoned), there will be no exception after 1000 ms. The exception will be thrown after a default timeout of three minutes. (Three minutes on a debian/ and a suse machines. Might be different on other platforms). JavaDoc says: public void setDefaultTimeout(int timeout) Set the default timeout in milliseconds to use when opening a socket. Digging through the code I found, that DefaultSocketFactory which is used be SocketClient does not care about any value set with this method. It creates a new Socket with Socket(hostname, port) and relies on the VMs behaviour. To get this fixed I set a custom SocketFactory with client.setSocketFactory(socketFactory); that uses a timeout for socket connection. This bug is also in 1.4.1, but this value is not listed... Christian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Validator 1.3.1 Release
+! Henri Yandell wrote: +1. pgp good, md5 good, jar in the binary same as the jar for maven, jar created from src has no jardiff with the jar for maven [not sure what else I can really check to compare], and manifest looks good. Hen On 11/28/06, Niall Pemberton [EMAIL PROTECTED] wrote: I have uploaded a new version of validator - which are the proposed final artifacts for the 1.3.1 release if the vote passes - available here: http://people.apache.org/~niallp/validator-1.3.1/ http://people.apache.org/~niallp/validator-1.3.1/site/ Following comments from Rahul and Oliver it has been built with JDK 1.3. Niall On 11/28/06, Niall Pemberton [EMAIL PROTECTED] wrote: This is a vote for the release of Validator 1.3.1 RC1 is here: http://people.apache.org/~niallp/validator-1.3.1-rc1/ Site here: http://people.apache.org/~niallp/validator-1.3.1-rc1/site/ Release notes here: http://people.apache.org/~niallp/validator-1.3.1-rc1/site/changes-report.html [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Validator 1.3.1 Release
I meant to say, of course, +1 :-) Henri Yandell wrote: +1. pgp good, md5 good, jar in the binary same as the jar for maven, jar created from src has no jardiff with the jar for maven [not sure what else I can really check to compare], and manifest looks good. Hen On 11/28/06, Niall Pemberton [EMAIL PROTECTED] wrote: I have uploaded a new version of validator - which are the proposed final artifacts for the 1.3.1 release if the vote passes - available here: http://people.apache.org/~niallp/validator-1.3.1/ http://people.apache.org/~niallp/validator-1.3.1/site/ Following comments from Rahul and Oliver it has been built with JDK 1.3. Niall On 11/28/06, Niall Pemberton [EMAIL PROTECTED] wrote: This is a vote for the release of Validator 1.3.1 RC1 is here: http://people.apache.org/~niallp/validator-1.3.1-rc1/ Site here: http://people.apache.org/~niallp/validator-1.3.1-rc1/site/ Release notes here: http://people.apache.org/~niallp/validator-1.3.1-rc1/site/changes-report.html [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [net] FTPS client auth required
Oops! Looks like you are correct, indeed. It didnt get removed from my local working copy, which explains why my builds still work. I suspect I may have made an errant click in the SVN commit dialog. Thanks for the spot - I'll put it back in. Rory - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [net] FTPS client auth required
Oops! Looks like you are correct, indeed. It didnt get removed from my local working copy, which explains why my builds still work. I suspect I may have made an errant click in the SVN commit dialog. Thanks for the spot - I'll put it back in. Rory - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] ASL 1.1 files
None. Thanks for changing. Cheers Rory Henri Yandell wrote: Any reason the following are still licensed under ASL 1.1? ./src/java/org/apache/commons/net/nntp/Article.java ./src/test/org/apache/commons/net/ftp/parser/FTPConfigEntryParserTest.java ./src/test/org/apache/commons/net/ftp/parser/NetwareFTPEntryParserTest.java ./src/test/org/apache/commons/net/ntp/TimeStampTest.java ./src/test/org/apache/commons/net/time/TimeTCPClientTest.java ./src/test/org/apache/commons/net/time/TimeTestSimpleServer.java Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (NET-70) [net] FTPClient.listFiles() returns incorrect directory names if the directory begins numerically
[ http://issues.apache.org/jira/browse/NET-70?page=all ] Rory Winston resolved NET-70. - Resolution: Cannot Reproduce I have tried to reproduce this issue and cannot (on a Windows platform). If you can send in a test case, that would be very helpful. Otherwise, I'll close for now. [net] FTPClient.listFiles() returns incorrect directory names if the directory begins numerically - Key: NET-70 URL: http://issues.apache.org/jira/browse/NET-70 Project: Commons Net Issue Type: Bug Environment: Operating System: Solaris Platform: Sun Reporter: Rob Sang I have an FTP server with the following directories in it: 10 years and under 11-14 years 15-17 years FTPClient.listFiles() reports these as: years and under 11-14 years 15-17 years It's losing the 10 in 10 years and under! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-70) [net] FTPClient.listFiles() returns incorrect directory names if the directory begins numerically
[ http://issues.apache.org/jira/browse/NET-70?page=all ] Rory Winston closed NET-70. --- [net] FTPClient.listFiles() returns incorrect directory names if the directory begins numerically - Key: NET-70 URL: http://issues.apache.org/jira/browse/NET-70 Project: Commons Net Issue Type: Bug Environment: Operating System: Solaris Platform: Sun Reporter: Rob Sang I have an FTP server with the following directories in it: 10 years and under 11-14 years 15-17 years FTPClient.listFiles() reports these as: years and under 11-14 years 15-17 years It's losing the 10 in 10 years and under! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-144) FTP: Filenames containing leading and trailing spaces
[ http://issues.apache.org/jira/browse/NET-144?page=all ]
Rory Winston closed NET-144.
Resolution: Won't Fix
We've discussed this issue before, and the consensus at the time was that we
wouldnt add a fix specifically for this issue, as it seems to be an extreme
edge case. If you disagree and you would like to have a go, feel free to submit
a patch.
FTP: Filenames containing leading and trailing spaces
-
Key: NET-144
URL: http://issues.apache.org/jira/browse/NET-144
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Reporter: Norbert Seekircher
The FTPClient's listFiles() method seems to trim filenames removing leading
and trailing spaces.
E. g.:
Create a directory /parent containing a file test (one leading and one
trailing space) on an ftp server.
Then call this code:
FTPClient ftp = new FTPClient();
ftp.connect(SERVER_NAME);
ftp.login(LOGIN, PASS);
FTPFile[] files = ftp.listFiles(/parent);
for (FTPFile file : files) {
System.out.println(\ + file.getName() + \);
}
It will print out test instead of test .
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-145) Deadlock in TelnetInputStream
[
http://issues.apache.org/jira/browse/NET-145?page=comments#action_12453993 ]
Rory Winston commented on NET-145:
--
Norbert
This should be fixed in the snapshot of commons-net-2.0, although this requires
JDK 1.5+. If you are in a position to test this, it would be great if you can
verify if it works or not:
http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHOT.jar
Deadlock in TelnetInputStream
-
Key: NET-145
URL: http://issues.apache.org/jira/browse/NET-145
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Heavy mutlithreaded environment using Jakarta VFS (which
uses Commons Net) for ftp file transfers
Reporter: Norbert Seekircher
Sometimes single threads of our application (each thread transfering data
from ftp servers) get locked forever. When monitoring our tool with JConsole,
I can see that such a thread usually hangs at
org.apache.commons.net.telnet.TelnetInputStream, line 339.
This line contains the statement
__queue.wait();
Unfortunately I haven't found a way to reproduce this issue, it just happens
about once a day (while running 24 hours and transfering about 5 files).
As a quick and dirty workaround: What do you think about replacing this line
with something like
long startTime = System.currentTimeMillis();
__queue.wait(6);
if ((System.currentTimeMillis() - startTime) 55000) {
throw new InterruptedException(Unknown strange and nasty blocker
detected);
}
So at least it would not just block the thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (POOL-93) Reduce contention by making borrow return more independent from each other
Holger Regarding The real fix here would be to make this and other boolean ivars volatile and the get/set methods unsynchronized - performance wise, would this not amount to the same thing - doesnt a volatile var (at least in JDK 5+) force a memory barrier (sync) on a read or write? Rory Holger Hoffstätte (JIRA) wrote: [ http://issues.apache.org/jira/browse/POOL-93?page=comments#action_12452547 ] Holger Hoffstätte commented on POOL-93: --- Thought about that too; AFAIK volatile is not really broken any more, at least not for volatile reads synchronized writes as done in the backport (see e.g. Atomic*). Also found this: http://www.cs.umd.edu/~pugh/java/memoryModel/archive/1888.html Got to draw the line somewhere :-) Maybe use the getter for 1.3.x and then assume a working volatile for 2.0? That way we can also start relaxing other areas where possible, step by step. Reduce contention by making borrow return more independent from each other Key: POOL-93 URL: http://issues.apache.org/jira/browse/POOL-93 Project: Commons Pool Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Holger Hoffstätte Attachments: GKOP-relaxedSyncOnReturn.patch, relaxedReturnObjectBenchmark.txt Currently borrow return are completely blocked from each other, while at least the factory-based validation destruction can be handled independently. A few simple changes narrow the synchronization blocks yet retain overall correctness. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS client auth required
Hi Niklas
Done. Thanks
Rory
Niklas Gustavsson wrote:
Thanks, making that settable makes a lot of sense. Would you mind
doing the same thing for the KeyManager as that would make client auth
possible? At least I'm not able to get it working without one :-)
I'm attaching the patch I use for the client auth tests in FtpServer.
/niklas
Rory Winston wrote:
Niklas
The current FTPSTrustManager implementation is a little bit sketchy -
maybe we could default to a more comprehensive validity check. I have
added the facility to plug in a custom trust manager to the
FTPSClient, as follows:
FTPSClient client = new FTPSClient();
client.setTrustManager(new X509TrustManager() {
public void checkClientTrusted(X509Certificate[]
chain, String authType) throws CertificateException {
...
}
public void checkServerTrusted(X509Certificate[]
chain, String authType) throws CertificateException {
...
}
public X509Certificate[] getAcceptedIssuers() {
...
}
});
Thanks for the patch, by the way.
Cheers
Rory
Niklas Gustavsson wrote:
Hi
I'm trying to create tests for client authentication for Apache
FtpServer. For this I'm using commons-net as the client but is
running into problems with the client auth support in FTPSClient.
I'm setting setNeedClientAuth(true) but still get problems due to
FTPSClient sending a null certificate chain. How should I set up my
keystore so that FTPSClient finds it and can use it to send the
correct certificate to the server for authentication? I've tried
with the javax.net.ssl.keyStore system property but to no avail.
Also, if I understand the current implementation of FTPSClient and
FTPSTrustManager. From what I can understand, the implementation
only checks if the service certificate is valid, not if it's
trusted. Is this correct? If so, this would probably be a security
issue in that a fake server serving up any valid certificate would
be trusted by the client. Is this the intended behavior?
/niklas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: src/main/java/org/apache/commons/net/ftp/FTPSClient.java
===
--- src/main/java/org/apache/commons/net/ftp/FTPSClient.java(revision
479111)
+++ src/main/java/org/apache/commons/net/ftp/FTPSClient.java(working copy)
@@ -23,6 +23,7 @@
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
+import javax.net.ssl.KeyManager;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLException;
import javax.net.ssl.SSLServerSocketFactory;
@@ -80,6 +81,9 @@
/** The FTPS [EMAIL PROTECTED] TrustManager} implementation. */
private TrustManager trustManager = new FTPSTrustManager();
+/** The [EMAIL PROTECTED] KeyManager} */
+private KeyManager keyManager;
+
/**
* Constructor for FTPSClient.
* @throws NoSuchAlgorithmException A requested cryptographic algorithm
@@ -194,10 +198,10 @@
planeSocket = _socket_;
try {
- context.init(null, new TrustManager[] {
getTrustManager() } , null);
- } catch (KeyManagementException e) {
- e.printStackTrace();
- }
+context.init(new KeyManager[] {keyManager}, new TrustManager[] {
getTrustManager() } , null);
+} catch (KeyManagementException e) {
+e.printStackTrace();
+}
SSLSocketFactory ssf = context.getSocketFactory();
String ip = _socket_.getInetAddress().getHostAddress();
@@ -479,6 +483,22 @@
this.trustManager = trustManager;
}
+/**
+ * Get the currently configured [EMAIL PROTECTED] KeyManager}.
+ *
+ * @return the keyManager
+ */
+public KeyManager getKeyManager() {
+return keyManager;
+}
+
+/**
+ * Set a [EMAIL PROTECTED] KeyManager} to use
+ *
+ * @param keyManager The KeyManager implementation to set.
+ */
+public void setKeyManager(KeyManager keyManager) {
+this.keyManager = keyManager;
+}
-
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS client auth required
Niklas
The current FTPSTrustManager implementation is a little bit sketchy -
maybe we could default to a more comprehensive validity check. I have
added the facility to plug in a custom trust manager to the FTPSClient,
as follows:
FTPSClient client = new FTPSClient();
client.setTrustManager(new X509TrustManager() {
public void checkClientTrusted(X509Certificate[] chain,
String authType) throws CertificateException {
...
}
public void checkServerTrusted(X509Certificate[] chain,
String authType) throws CertificateException {
...
}
public X509Certificate[] getAcceptedIssuers() {
...
}
});
Thanks for the patch, by the way.
Cheers
Rory
Niklas Gustavsson wrote:
Hi
I'm trying to create tests for client authentication for Apache
FtpServer. For this I'm using commons-net as the client but is running
into problems with the client auth support in FTPSClient. I'm setting
setNeedClientAuth(true) but still get problems due to FTPSClient
sending a null certificate chain. How should I set up my keystore so
that FTPSClient finds it and can use it to send the correct
certificate to the server for authentication? I've tried with the
javax.net.ssl.keyStore system property but to no avail.
Also, if I understand the current implementation of FTPSClient and
FTPSTrustManager. From what I can understand, the implementation only
checks if the service certificate is valid, not if it's trusted. Is
this correct? If so, this would probably be a security issue in that a
fake server serving up any valid certificate would be trusted by the
client. Is this the intended behavior?
/niklas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-68) [net] TFTPClient's send file discards last ack
[ http://issues.apache.org/jira/browse/NET-68?page=comments#action_12448992
]
Rory Winston commented on NET-68:
-
I've applied your patch to TFTPClient on the 2.0 branch. Thanks Jennifer.
[net] TFTPClient's send file discards last ack
--
Key: NET-68
URL: http://issues.apache.org/jira/browse/NET-68
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.3 Final
Environment: Operating System: Linux
Platform: PC
Reporter: Perttu Auramo
Fix For: 2.0, 1.5
Attachments: lastack.patch, patch, TFTPstuff.zip
TFTPClient reads all acks just fine except the last-one when sending a file. I
figured this out when I tried to use the same TFTPClient-instance for
something
else (reading a file) after sending a file. This ack was next in the buffer
and
some exception was thrown (don't remember which anymore).
I fixed this for myself using a flag (lastAckWait). Here is a the result of
diff-command:
diff -u TFTPClient.java.original TFTPClient.java.patched
--- TFTPClient.java.original2004-12-28 15:02:37.235997984 +0200
+++ TFTPClient.java.patched 2004-12-28 15:09:14.516602152 +0200
@@ -372,6 +372,7 @@
dataLength = lastBlock = hostPort = bytesRead = 0;
block = 0;
+boolean lastAckWait = false;
if (mode == TFTP.ASCII_MODE)
input = new ToNetASCIIInputStream(input);
@@ -455,7 +456,10 @@
if (lastBlock == block)
{
++block;
-break _receivePacket;
+if (lastAckWait)
+ break _sendPacket;
+else
+ break _receivePacket;
}
else
{
@@ -501,9 +505,8 @@
data.setData(_sendBuffer, 4, offset - 4);
sent = data;
}
-while (dataLength == 0);
+while (dataLength == 0 || lastAckWait);
-bufferedSend(sent);
endBufferedOps();
}
By the way we have implemented a TFTP server also (heavily unit-tested). I
could
try to contribute it back if it fits in commons net. There was some talk in
the
web-pages of doing only client-side stuff for commons-net.
-Perttu
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (NET-31) [net] Freeze during FTP connect
[ http://issues.apache.org/jira/browse/NET-31?page=all ] Rory Winston updated NET-31: Bugzilla Id: (was: 38160) Fix Version/s: 2.0 [net] Freeze during FTP connect --- Key: NET-31 URL: http://issues.apache.org/jira/browse/NET-31 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Final Environment: Operating System: Linux Platform: Other Reporter: ThomasGt Fix For: 2.0 Several times a day a Java process open FTP connections (using Commons Net) and some times (approximately twice a week) the process hang until I kill it. By looking at the dump it seems the lock appears during the connection opening but I have no clue why it happens. Here are the information I have : --- FTP client : - OS Red Hat Enterprise Linux ES release 3 (Taroon Update 2) - Java j2sdk1.4.2_05 FTP server on windows --- Thread dump get through kill -3 on java process : Full thread dump Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode): Thread-1 daemon prio=1 tid=0x081e2cc0 nid=0x72c5 runnable [a926e000..a926e87c] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read(BufferedInputStream.java:201) - locked 0xaadc0d80 (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:66) at java.io.PushbackInputStream.read(PushbackInputStream.java:120) at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75) at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read(BufferedInputStream.java:201) - locked 0xaadc0028 (a org.apache.commons.net.telnet.TelnetInputStream) at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114) at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535) at java.lang.Thread.run(Thread.java:534) Signal Dispatcher daemon prio=1 tid=0x0809c440 nid=0x72c5 waiting on condition [0..0] Finalizer daemon prio=1 tid=0x08097aa0 nid=0x72c5 in Object.wait() [aabbd000..aabbd87c] at java.lang.Object.wait(Native Method) - waiting on 0xab22b7a8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked 0xab22b7a8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=1 tid=0x08096ef8 nid=0x72c5 in Object.wait() [aac3e000..aac3e87c] at java.lang.Object.wait(Native Method) - waiting on 0xab22b810 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:429) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115) - locked 0xab22b810 (a java.lang.ref.Reference$Lock) main prio=1 tid=0x0805ba20 nid=0x72c5 in Object.wait() [bfff9000..bfff9eec] at java.lang.Object.wait(Native Method) - waiting on 0xaad4 (a [I) at java.lang.Object.wait(Object.java:429) at org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:339) - locked 0xaad4 (a [I) at org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:466) at java.io.BufferedInputStream.read1(BufferedInputStream.java:220) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) - locked 0xaad42108 (a java.io.BufferedInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182) - locked 0xaad42988 (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked 0xaad42988 (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:264) at org.apache.commons.net.ftp.FTP._connectAction_(FTP.java:335) at org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:550) at org.apache.commons.net.SocketClient.connect(SocketClient.java:163
[jira] Resolved: (NET-31) [net] Freeze during FTP connect
[ http://issues.apache.org/jira/browse/NET-31?page=all ] Rory Winston resolved NET-31. - Resolution: Fixed This should now be fixed in 2.0, now that FTPClient extends SocketClient directly. [net] Freeze during FTP connect --- Key: NET-31 URL: http://issues.apache.org/jira/browse/NET-31 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Final Environment: Operating System: Linux Platform: Other Reporter: ThomasGt Fix For: 2.0 Several times a day a Java process open FTP connections (using Commons Net) and some times (approximately twice a week) the process hang until I kill it. By looking at the dump it seems the lock appears during the connection opening but I have no clue why it happens. Here are the information I have : --- FTP client : - OS Red Hat Enterprise Linux ES release 3 (Taroon Update 2) - Java j2sdk1.4.2_05 FTP server on windows --- Thread dump get through kill -3 on java process : Full thread dump Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode): Thread-1 daemon prio=1 tid=0x081e2cc0 nid=0x72c5 runnable [a926e000..a926e87c] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read(BufferedInputStream.java:201) - locked 0xaadc0d80 (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:66) at java.io.PushbackInputStream.read(PushbackInputStream.java:120) at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75) at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read(BufferedInputStream.java:201) - locked 0xaadc0028 (a org.apache.commons.net.telnet.TelnetInputStream) at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114) at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535) at java.lang.Thread.run(Thread.java:534) Signal Dispatcher daemon prio=1 tid=0x0809c440 nid=0x72c5 waiting on condition [0..0] Finalizer daemon prio=1 tid=0x08097aa0 nid=0x72c5 in Object.wait() [aabbd000..aabbd87c] at java.lang.Object.wait(Native Method) - waiting on 0xab22b7a8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked 0xab22b7a8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=1 tid=0x08096ef8 nid=0x72c5 in Object.wait() [aac3e000..aac3e87c] at java.lang.Object.wait(Native Method) - waiting on 0xab22b810 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:429) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115) - locked 0xab22b810 (a java.lang.ref.Reference$Lock) main prio=1 tid=0x0805ba20 nid=0x72c5 in Object.wait() [bfff9000..bfff9eec] at java.lang.Object.wait(Native Method) - waiting on 0xaad4 (a [I) at java.lang.Object.wait(Object.java:429) at org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:339) - locked 0xaad4 (a [I) at org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:466) at java.io.BufferedInputStream.read1(BufferedInputStream.java:220) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) - locked 0xaad42108 (a java.io.BufferedInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182) - locked 0xaad42988 (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked 0xaad42988 (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:264) at org.apache.commons.net.ftp.FTP._connectAction_(FTP.java:335) at org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:550
[jira] Closed: (NET-31) [net] Freeze during FTP connect
[ http://issues.apache.org/jira/browse/NET-31?page=all ] Rory Winston closed NET-31. --- [net] Freeze during FTP connect --- Key: NET-31 URL: http://issues.apache.org/jira/browse/NET-31 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Final Environment: Operating System: Linux Platform: Other Reporter: ThomasGt Fix For: 2.0 Several times a day a Java process open FTP connections (using Commons Net) and some times (approximately twice a week) the process hang until I kill it. By looking at the dump it seems the lock appears during the connection opening but I have no clue why it happens. Here are the information I have : --- FTP client : - OS Red Hat Enterprise Linux ES release 3 (Taroon Update 2) - Java j2sdk1.4.2_05 FTP server on windows --- Thread dump get through kill -3 on java process : Full thread dump Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode): Thread-1 daemon prio=1 tid=0x081e2cc0 nid=0x72c5 runnable [a926e000..a926e87c] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read(BufferedInputStream.java:201) - locked 0xaadc0d80 (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:66) at java.io.PushbackInputStream.read(PushbackInputStream.java:120) at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75) at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read(BufferedInputStream.java:201) - locked 0xaadc0028 (a org.apache.commons.net.telnet.TelnetInputStream) at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114) at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535) at java.lang.Thread.run(Thread.java:534) Signal Dispatcher daemon prio=1 tid=0x0809c440 nid=0x72c5 waiting on condition [0..0] Finalizer daemon prio=1 tid=0x08097aa0 nid=0x72c5 in Object.wait() [aabbd000..aabbd87c] at java.lang.Object.wait(Native Method) - waiting on 0xab22b7a8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked 0xab22b7a8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=1 tid=0x08096ef8 nid=0x72c5 in Object.wait() [aac3e000..aac3e87c] at java.lang.Object.wait(Native Method) - waiting on 0xab22b810 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:429) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115) - locked 0xab22b810 (a java.lang.ref.Reference$Lock) main prio=1 tid=0x0805ba20 nid=0x72c5 in Object.wait() [bfff9000..bfff9eec] at java.lang.Object.wait(Native Method) - waiting on 0xaad4 (a [I) at java.lang.Object.wait(Object.java:429) at org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:339) - locked 0xaad4 (a [I) at org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:466) at java.io.BufferedInputStream.read1(BufferedInputStream.java:220) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) - locked 0xaad42108 (a java.io.BufferedInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182) - locked 0xaad42988 (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked 0xaad42988 (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:264) at org.apache.commons.net.ftp.FTP._connectAction_(FTP.java:335) at org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:550) at org.apache.commons.net.SocketClient.connect(SocketClient.java:163) at org.apache.commons.net.SocketClient.connect
Re: [commons ftp] help! FTPClient.isConnected() does not work.
Hey Daniel I knwo you said that you were going to have a look at adding connect timeout functionality to FTPClient. I had some spare time today, and I decided to see if I could give it a go on the 2.0 branch. However, I would be grateful if you could give it an eyeball and see if you think it is an acceptable solution. I have made changes to SocketClient and added a simple test case. http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/org/apache/commons/net/SocketClient.java?r1=470520r2=473763diff_format=h and http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/test/java/org/apache/commons/net/ftp/TestConnectTimeout.java?revision=473763view=markup Cheers Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Major versions require package name change
Torsten I dont get the analogy either - I didnt see how it helped prove your point. I understand your arguments though, and I can see your point, but I still can't see any convincing arguments for mandating this type of approach. Best left to the individual project maintainers, IMHO. Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: On 10/30/06, Torsten Curdt [EMAIL PROTECTED] wrote: There are clearly good reasons / circumstances to take the approach you suggest, but it is a user unfriendly approach. As a user I like to try out new versions by dropping in a new jar - before taking the decision to upgrade. This approach rules that out and it wouldn't surprise me if users started to see commons as irrelevant because of upgrade hell if we take this route too often. Guys, you cannot always just drop in a new jar. Come on! A similar conversation that could have happened a couple of years ago... you: No, I don't like this 3.5 floppy drives. They don't fit my 5 1/4 disks! me: Well, it's new, it's different ...it has more capacity! you: Well, I don't care ...I used to be able to use them. I don't want the new disks ...but the capacity would be great. I just want to have that. me: Just keep using you old drive then ...but you would have to stick with the old capacity you: No, now I want the bigger capacity!! me: Then you will have to copy over the data from the old disks to some new ones you: Are you kidding? That's too much work! I used to just stick them in there and they just worked fine! If it's that much work to use this new fancy drives - no one will use this crap me: *sigh* *silence* (you = multiple people arguing in this thread not to change the package name) (me = the other people arguing in this thread who think it would probably make sense) (silence = the rest of the gang ;-) ) I didn't argue in this thread against changing package names - just against mandating it as a policy. I agree that if, as in the example of Generified Collections, the developers choose to refactor then changing the package name is a necessary approach. However the Collections developers have/had a choice - they could have adopted the approach Sun took to generics and preserved backwards compatibility. Both options are valid - but it should be down to individual components to choose the route they take. If Collections had chosen this route then mandating a package name change would be stupid. Niall P.S. Your analogy is irrelevant as it doesn't represent any POV I put forward. Keep in mind you can still use the drop in upgrade for minor releases. If there is a major release - there is a good reason for it! If this drop in would have been possible it would have been a minor release. So how often would you thinks this will happen? And... Upgrading a package name change is easily manageable by the average user ...dependency hell is not. So I think using this scheme would make things quite transparent and HELP the users. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
