mina-ftpserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sai Pullabhotla <sai.pullabho...@jmethods.com>
Subject Re: Is there a way to access the FtpSession.lastReply in the handleOnClose() call?
Date Tue, 01 Mar 2011 20:11:03 GMT
I think I see what you are saying now, after looking at the Ftplet
interface and DefaultFtplet. The Ftplet interface has afterCommand and
beforeCommand methods which are called back with FtpRequest, FtpReply
and FtpSession parameters. The DefaultFtplet captures the afterCommand
and calls the onUploadEnd (for example), but swallows the FtpReply.
So, if you change your Ftplet to directly implement the Ftplet
interface, you would have access to the reply as well. I guess we need
to look into why DefaultFtplet is not propagating the FtpReply to
onXXXStart and onXXXEnd methods.

On Tue, Mar 1, 2011 at 2:02 PM, Sai Pullabhotla
<sai.pullabhotla@jmethods.com> wrote:
> Assuming you are playing with the code in the trunk, all you have to
> do is check if the FtpReply is a positive reply by calling
> FtpReply.isPositive. If this method returns true, it is a successful
> upload, otherwise, it is not. You can then type cast the FtpReply to
> DataTransferFtpReply to access additional information such as the
> file, the size etc.
> Hope this helps.
> On Tue, Mar 1, 2011 at 1:31 PM, Toli Kuznets <tkuznets@marinsoftware.com> wrote:
>> Sai,
>> I believe it's still the same problem - the FtpIoSession is not easily
>> exposed to me inside the onUploadEnd() method.
>> I can cast the incoming FtpSession to DefaultFtpSession, but i can't
>> easily get to the FtpIoSession inside of it without using a "can
>> opener"...
>> so i still don't have access to the getLastReply() method inside the
>> onXXX() function in an Ftplet
>> I may, of course, be missing something very obvious, apologies if
>> that's the case.
>> On Tue, Mar 1, 2011 at 11:04 AM, Sai Pullabhotla
>> <sai.pullabhotla@jmethods.com> wrote:
>>> I do see that there is a getLastReply method in the FtpIoSession
>>> class. Not sure if it exists only on trunk or 1.0.x branch. Also, the
>>> code in trunk has a lot of enhancements - such as more specific reply
>>> implementations which provide access to additional data based on the
>>> command/reply. For example, you can get the file name, the bytes that
>>> were transferred etc. when you intercept the onUpload. Some thing you
>>> might want to try.
>>> On Tue, Mar 1, 2011 at 12:32 PM, Toli Kuznets
>>> <tkuznets@marinsoftware.com> wrote:
>>>> David,
>>>> I ended up filing an RFE for this at
>>>> https://issues.apache.org/jira/browse/FTPSERVER-401 so that it can be
>>>> tracked easier.
>>>>>>> 2011/2/12 Toli Kuznets <tkuznets@marinsoftware.com>:
>>>>>>>> Hi,
>>>>>>>> I have a custom FtpLet and I wan to kick off a job on file
upload, so
>>>>>>>> i override the handleOnClose() call.
>>>>>>>> I'm running into a situation where when my users use SSIS
>>>>>>>> Microsoft product) to send files over FTP, they are not able
>>>>>>>> establish a data connection to my server (separate problem),
>>>>>>>> an internal exception in STOR.execute() but I still get a
callback in
>>>>>>>> onHandleClose()
>>>>>>>> However, when I get the callback, it's impossible for me
to tell the
>>>>>>>> difference between a "successful" upload or a callback after
>>>>>>>> exception when there was no physical file placed on disk.
>>>>>>>> Looking in the debugger, I notice that the incoming FtpSession
>>>>>>>> actually a DefaultFtpSession that has an FtpIoSession that
has a
>>>>>>>> getLatReply() method that can return me something useful
>>>>>>>> (REPLY_425_CANT_OPEN_DATA_CONNECTION in my case).
>>>>>>>> However, getting to lastReply is not exposed.
>>>>>>>> is there a better way to tell if handleOnClose() is being
called on
>>>>>>>> success or failure? How can i tell those 2 situations apart?
>>>>>>>> My server is setup with all defaults for connections - in
this case,
>>>>>>>> the connection is coming in as ACTIVE and for some reason
i get an
>>>>>>>> exception when opening data connection, so i want to catch
that case
>>>>>>>> and not kick of an event in handleOnClose()
>>>>>>>> This is on FtpServer-1.0.5, and the relevant stacktrace from
the call
>>>>>>>> to handleOnClose() after the failed open of data connection
>>>>>>>>        at com.marin.plugin.ftpserver.FileUploadNotifierFtplet.onUploadEnd(FileUploadNotifierFtplet.java:70)
>>>>>>>>        at org.apache.ftpserver.ftplet.DefaultFtplet.afterCommand(DefaultFtplet.java:89)
>>>>>>>>        at org.apache.ftpserver.ftpletcontainer.impl.DefaultFtpletContainer.afterCommand(DefaultFtpletContainer.java:144)
>>>>>>>>        at org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(DefaultFtpHandler.java:220)
>>>>>>>> The "unable to open data connection" is below if it helps:
>>>>>>>> 11 Feb 2011 16:15:30,977 DEBUG [pool-5-thread-1]
>>>>>>>> nativefs.impl.NativeFtpFile (NativeFtpFile.java:212) - Checking
>>>>>>>> file exists
>>>>>>>> 11 Feb 2011 16:15:30,977 DEBUG [pool-5-thread-1]
>>>>>>>> nativefs.impl.NativeFtpFile (NativeFtpFile.java:218) - Authorized
>>>>>>>> 11 Feb 2011 16:16:45,931 DEBUG [pool-5-thread-1] command.impl.STOR
>>>>>>>> (STOR.java:134) - Exception getting the input data stream
>>>>>>>> java.net.ConnectException: Operation timed out
>>>>>>>>        at java.net.PlainSocketImpl.socketConnect(Native
>>>>>>>>        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
>>>>>>>>        at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
>>>>>>>>        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
>>>>>>>>        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432)
>>>>>>>>        at java.net.Socket.connect(Socket.java:529)
>>>>>>>>        at java.net.Socket.connect(Socket.java:478)
>>>>>>>>        at org.apache.ftpserver.impl.IODataConnectionFactory.createDataSocket(IODataConnectionFactory.java:314)
>>>>>>>>        at org.apache.ftpserver.impl.IODataConnectionFactory.openConnection(IODataConnectionFactory.java:259)
>>>>>>>>        at org.apache.ftpserver.command.impl.STOR.execute(STOR.java:132)
>>>>>>>>        at org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(DefaultFtpHandler.java:210)
>>>>>>>> This is very reproducible, so i can provide any other information
>>>>>>>> may be helpful.
>>>>>>>> I'm seeing similar behaviour directly from Windows FTP command-line
>>>>>>>> all other use cases (from Mac, from Windows FileZilla, etc
work just fine)
>>>>>>>> thanks!

View raw message