commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jigsaw (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (NET-546) NPE because of returning wrong reply-code for openDataConnection while performing MPUT
Date Wed, 16 Jul 2014 14:59:08 GMT

    [ https://issues.apache.org/jira/browse/NET-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14063575#comment-14063575
] 

jigsaw edited comment on NET-546 at 7/16/14 2:57 PM:
-----------------------------------------------------

I have written a unit test that fails but sholdn't:

<code>	@Test
	public void testApacheFTP2Stores() throws IOException {
		apacheFTP.connect(ATTR_SERVER);
		
		apacheFTP.login(ATTR_USER, ATTR_PASS);
		apacheFTP.setFileType(FTP.BINARY_FILE_TYPE);
		
		apacheFTP.changeWorkingDirectory(ATTR_CHDIR);
		OutputStream out = apacheFTP.storeFileStream(ATTR_PUTFILE);
		out = apacheFTP.storeFileStream(ATTR_PUTFILE);
		
		apacheFTP.disconnect();
		
		assertNotNull(out);
	}</code>

The variable apacheFTP means org.apache.commons.net.ftp.FTPClient.

Even an out.close() between those two storeFileStream doesn't help.
If the 2nd storeFileStream gets deleted the unit test will finish successfully.


was (Author: jigsaw):
I have written a unit test that fails but sholdn't:

	@Test
	public void testApacheFTP2Stores() throws IOException {
		apacheFTP.connect(ATTR_SERVER);
		
		apacheFTP.login(ATTR_USER, ATTR_PASS);
		apacheFTP.setFileType(FTP.BINARY_FILE_TYPE);
		
		apacheFTP.changeWorkingDirectory(ATTR_CHDIR);
		OutputStream out = apacheFTP.storeFileStream(ATTR_PUTFILE);
		out = apacheFTP.storeFileStream(ATTR_PUTFILE);
		
		apacheFTP.disconnect();
		
		assertNotNull(out);
	}

The variable apacheFTP means org.apache.commons.net.ftp.FTPClient.

Even an out.close() between those two storeFileStream doesn't help.
If the 2nd storeFileStream gets deleted the unit test will finish successfully.

> NPE because of returning wrong reply-code for openDataConnection while performing MPUT
> --------------------------------------------------------------------------------------
>
>                 Key: NET-546
>                 URL: https://issues.apache.org/jira/browse/NET-546
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 3.3
>         Environment: Win7, System i (IBM)
>            Reporter: jigsaw
>
> Hi there,
> I'm trying to transfer some data from a Windows 7 system to a System i (IBM server, former
AS/400) by using MPUT.
> So what I am doing in detail:
> I have got a Java client on my Windows 7 machine. There apache commons net is in use.
By using the class FTPClient I connect to an IBM machine (there is installed V7R1).
> These are the commands I fire:
> ftp.login(username, password);
> ftp.setFileType(FTP.BINARY_FILE_TYPE);
> ftp.changeWorkingDirectory(pathname);
> ftp.storeFileStream(remoteFile);
> ftp.disconnect();
> When performing the storeFileStream NULL is returned instead of the output stream. Connection
can be established and everything is working well.
> The problem is that a wrong reply-code is checked during openDataConnection.
> Let me sum up the relevant steps:
> 1. storeFileStream is called
> 2. _storeFileStream(String, String) of FTPClient gets entered
> 3. Then _openDataConnection_ is entered
> 4. Inside this method the active connection mode part is executed
> 5. Using IP4 the port method is called there
> 6. Due to calling the PORT command for FTP a new return message is generated: “200
PORT subcommand request successful.”
> 7. isPositiveCompletion returns true everything is fine up to here
> 8. Going on with the active connection mode part this leads to the sendCommand method
where – after executing the FTP command – the __getReply(boolean) method inside of __getReply()
is called.
> 9. And now the issue: _controlInput_.readLine() returns the PORT message mentioned before
instead of “150 Sending file to [myFile]”. When calling readLine again, the correct message
is returned.
> Why is the message important?
> Getting back to _openDataConnection_ after execution of sendCommand the method FTPReply.isPositivePreliminary
checks the reply-code, which is 200 instead of 150. This will cause a fail and a returning
of NULL as output stream.
> That’s my guess:
> There is missing a call of _controlInput_.readLine() to clear some information messages
before calling a new FTP command.
> Thank you.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message