mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gentian Hila <genti.t...@gmail.com>
Subject Re: onDownloadEnd, onUploadEnd firing when aborting the transfer
Date Tue, 22 Oct 2013 16:17:03 GMT
We're not using OSGI container so that should be ok. However, I would like
to not use a patched version if possible. First I would like to try to
submit a ticket for a new feature and hopefully extend and submit a new
feature to the project if possible.

My concern is that won't be able to easily get bug fixes or new versions
easily to a patched version.

Otherwise we have to live with it.


There is a JIRA ticket already for the first approach but no official
version yet.

https://issues.apache.org/jira/i#browse/FTPSERVER-401



ServerFtpStatistic (rather than FtpStatistics) and FileObserver seems to be
set on the FtpServerContext by hard coding them with the default
implementation rather than feeding them through an extension or
configuration. So it seems that we need a patched version for all these
three options.

Genti




On Mon, Oct 21, 2013 at 6:27 AM, Dave Roberts <
dave.roberts@saaconsultants.com> wrote:

> On 18/10/2013 15:34, Gentian Hila wrote:
> > Documentation says that these events are fired on successful download or
> > upload.
>
> That would appear to be incorrect.
>
> > Is there a way to guarantee that they fire only on success or a some way
> > that I can check within the methods if the download or upload was
> complete?
>
> Currently these callbacks will get called irrespective of whether
> the command was successful.
>
> One way to detect success/failure would be to write your own Ftplet
> implementation without sub-classing DefaultFtplet.  You will then
> need to provide your own implementation of:-
>
> FtpletResult afterCommand(FtpSession session, FtpRequest request,
> FtpReply reply)
>
> Which as you can see, is passed the FtpReply that the STOR/RETR
> commands returned.  You can use that to determine if the transfter
> was successful by looking for a code of
> 'FtpReply.REPLY_226_CLOSING_DATA_CONNECTION', or simply calling the
> isPositive() method.  You would obviously have to check that the
> request is one of the file transfer commands.
>
>
> Another option is via the FtpStatistics methods of setUpload and
> setDownload or the FileObserver notifyUpload/notifyDownload. These
> are only called upon a successful transfer.  The advantage of these
> is that you will be passed information about the file, that the
> Ftplet isn't given.
>
> Unfortunately setting your own implementation currently requires the
> use of internal classes and methods, and this won't be possible if
> you're using an OSGi container.  There is an outstanding ticket and
> fix to remedy this though, if you're not using OSGi or don't mind
> running a patched version of the code (with no guarantee that the
> patch will ever make an official release).
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message