On 26/10/2016 10:58, Emmanuel Lécharny wrote:
> I would consider that this version (1.1.0) is a stabilized base on which
> we will be able to move forward.
>
> There is nothing bad in having a 1.1.1 out in one week, containing the
> pending PR. Differing the release will just make things a bit
FWIW, here's my vote:-
-1 | Do **NOT** release FTPServer 1.1.0
There are pending pull requests that have been around for over 3
years which I'd really like to see make the cut...
For FTPSERVER-344:
https://github.com/saaconsltd/mina-ftpserver/pull/1
For FTPSERVER-446:
On 04/08/2016 00:10, James Percent wrote:
> Working with FtpServer. The logging is seriously out of date and crashes
> and causes crashes and dependency issues:
Can you provide some specific examples. I've been using 1.0.6 for
quite some time now and don't recall any issues in the logging.
Dave Roberts created SSHD-668:
-
Summary: AccessControlException running under OSGi container
Key: SSHD-668
URL: https://issues.apache.org/jira/browse/SSHD-668
Project: MINA SSHD
Issue Type: Bug
On 20/04/2015 15:59, Dave Carlson wrote:
Thanks for the response, Dave. I saw the Oct 2013 conversation. In it,
you stated that there was an outstanding ticket and a patch for this.
Where can I find that? Both the issue and the patch? I found
FTPSERVER-401, but I don't think that is what
On 10/04/2015 16:50, Dave Carlson wrote:
releases scheduled. Are these being actively developed, and is there a
target date for any of them?
There hasn't been any active development for quite some time. For
many years now, this mostly hinged on one guy, Niklas, doing all the
work and for
On 22/10/2013 17:17, Gentian Hila wrote:
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.
On 21/10/2013 21:15, Gentian Hila wrote:
Is there any way to make sure that when one file is downloaded from the
user, a second connection from the same user won't be able to download it
again?
An Ftplet implementation should be able to handle this.
You could physically move/remove the file
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
[
https://issues.apache.org/jira/browse/FTPSERVER-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792490#comment-13792490
]
Dave Roberts commented on FTPSERVER-438:
I have fixed this locally by checking
[
https://issues.apache.org/jira/browse/FTPSERVER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13764151#comment-13764151
]
Dave Roberts commented on FTPSERVER-344:
Sorted out Github repo, here's
[
https://issues.apache.org/jira/browse/FTPSERVER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13764169#comment-13764169
]
Dave Roberts commented on FTPSERVER-446:
Pull request for initial changes
On 11/09/2013 09:19, 30553859 wrote:
How can i distinguish whether a file is transfer complete or
transfer has been interrupt . I use reply code 226,but ftpserver
also reply 226 when transfer been interrupt.
Which version of FtpServer are you using? In the latest release,
1.0.6, any Socket or
[
https://issues.apache.org/jira/browse/FTPSERVER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761993#comment-13761993
]
Dave Roberts commented on FTPSERVER-344:
Based upon the current Git master
[
https://issues.apache.org/jira/browse/FTPSERVER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13762008#comment-13762008
]
Dave Roberts commented on FTPSERVER-446:
Ignore the previous patches, they only
Dave Roberts created FTPSERVER-446:
--
Summary: Implementing User Manager not possible in OSGi environment
Key: FTPSERVER-446
URL: https://issues.apache.org/jira/browse/FTPSERVER-446
Project: FtpServer
[
https://issues.apache.org/jira/browse/FTPSERVER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Roberts updated FTPSERVER-446:
---
Attachment: concurrentlogin.patch
Created interface for Concurrent Login check so User
[
https://issues.apache.org/jira/browse/FTPSERVER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Roberts updated FTPSERVER-446:
---
Attachment: writerequest.patch
Created interface for Write Request to follow pattern
[
https://issues.apache.org/jira/browse/FTPSERVER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Roberts updated FTPSERVER-446:
---
Attachment: transferrate.patch
Created interface for Transfer Rate request to follow
[
https://issues.apache.org/jira/browse/FTPSERVER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736820#comment-13736820
]
Dave Roberts commented on FTPSERVER-446:
Added patches to create interfaces
On 01/08/2013 21:34, Julien Vermillard wrote:
I poked around with bootstrap 3 :
http://people.apache.org/~jvermillard/test/
Clean and simple. I like it.
On 31/07/2013 22:07, Niklas Gustavsson wrote:
It's possible to deploy FTP Server post 1.0.8 in an OSGi
container.
Sorry, I meant post 1.0.6. There is no 1.0.8 (yet).
Anyhow, the idea is that the UserManager/User shouldn't need to
care about Authority/AuthorizationRequest implementations.
It's possible to deploy FTP Server post 1.0.8 in an OSGi container.
However creating a different User Manager implementation is not
without problems.
Consider that the USER class checks to see if the user logging in is
permitted to do so concurrently. This is done by creating an
instance of
Environment: Firefox 7, Internet Explorer 8
Reporter: Dave Roberts
Priority: Trivial
When viewing the MINA website in a browser that isn't maximised, or at least
beyond the width of the content, the page is clipped on both sides. This is
worse than the usual instance where
[
https://issues.apache.org/jira/browse/DIRMINA-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Roberts updated DIRMINA-868:
-
Attachment: screenshot-1.jpg
Web site assumes wide browser width
On 15/02/2011 10:37, Niklas Gustavsson (JIRA) wrote:
+LOG.debug(About to execute command {} for request,
command, request);
+LOG.debug(Executing command {} for request,
command, request);
+LOG.debug(Executed command {} for
On 14/09/2010 18:50, Sai Pullabhotla wrote:
While this should work with most clients, there is still a need to
just secure authentication process (especially the user name and
password). Once the authentication is finished, a client might want to
switch back to plain old FTP if there is no
On 29/03/2010 22:35, Sai Pullabhotla wrote:
Of course, a Source Code Formatter posted to the MINA web site would
definitely be a plus as I do want to format and still keep the
unchanged stuff as is.
http://mina.apache.org/developer-guide.data/ImprovedJavaConventions.xml
Or, go to the MINA
On 12/03/2010 14:24, Emmanuel Lecharny wrote:
I always wanted to build some tooling on top of MINA, and we already
found a name for it :
MinaReal
It would be some kind of Ethereal, with plugged protocol decoder, and
using http://jpcap.sourceforge.net/ to capture packets.
Does it
On 08/03/2010 10:17, Niklas Gustavsson wrote:
On Mon, Mar 8, 2010 at 10:35 AM, Dave Roberts
dave.robe...@saaconsultants.com wrote:
Obviously I'm a little biased, but I would have liked to have seen
issue FTPSERVER-344 resolved before the release.
I think this patch is a bit to complex
On 23/02/2010 21:09, Julien Vermillard wrote:
I think the problem is due to cron not running the .profile before
running the rsync
Correct, cron is different from the user environment. It may call
the system profile (/etc/profile) depending on OS, but the best
option is to set the umask within
Allow SITE command to be extended
-
Key: FTPSERVER-343
URL: https://issues.apache.org/jira/browse/FTPSERVER-343
Project: FtpServer
Issue Type: Improvement
Components: Core
Reporter: Dave
Reporter: Dave Roberts
Setting this Observers currently involves a lot of casting and use of
internal classes and interfaces.
These need to be exposed to the public interfaces.
The simplest idea would seem to be to push the methods up to the FtpStatistics
interface. However
[
https://issues.apache.org/jira/browse/FTPSERVER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Roberts updated FTPSERVER-344:
---
Attachment: ftpStatistics.patch
How about: setObserver(), setFileObserver
Back in the day, I would get a copy of the FtpServerContext and from
that get the ServerFtpStatistics which I would use to call the
setFileObserver() method. However, this involves a lot of casting
and use of internal classes and interfaces.
Given that setting Observers would seem to be
[X]: +1, Release FtpServer 1.0.2
David Latorre wrote:
So unless someone has a strong reason to need uniform EOLs
corresponding to the target system, then we might assume that the
issue with different clients resulting in different files can be
ignored, and transform only the canonical line ending.
My understanding of
Andrea Francia wrote:
Niklas Gustavsson wrote:
On Wed, Oct 8, 2008 at 11:44 PM, Andrea Francia [EMAIL PROTECTED] wrote:
Why should I do this?
Because it's the order that will be returned to the client, and if
it's a long listing it's better to let the implementation do the
ordering
Emmanuel Lecharny wrote:
Andrea Francia wrote:
Emmanuel Lecharny wrote:
Does it sounds a good idea ?
I think that before designing a new method we will ask ourself if
there is a Use Case where it is used.
Good point. So is it important that the files are sorted or not sorted ?
Do we have
Andrea Francia wrote:
Dave Roberts wrote:
A standard command line FTP Client doesn't do any ordering of the list
information. So as a user, I want to see the files come back sorted
by name. As I recall, every server I've connected to does this.
Then I think that this should be a suggestion
[
https://issues.apache.org/jira/browse/FTPSERVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595261#action_12595261
]
Dave Roberts commented on FTPSERVER-133:
TIME_WAIT is the final state
Niklas Gustavsson wrote:
Dave Roberts wrote:
Just wondering: where do we go from here?
My plan is to enable MDC by default (using the MDC filter that MINA
provides). This will give you the possibility of logging for example to
client IP or user name. I've played around some
Niklas Gustavsson wrote:
On Tue, Feb 26, 2008 at 3:50 PM, Dave Roberts
[EMAIL PROTECTED] wrote:
So, will all LOG writes (e.g. PASS.java:215) be replaced with this
new logging functionality?
There should be no need for that. The MINA MdcInjectionFilter sets
some things for us
We have a number of places where we can configure the idle time,
after which a session is dropped. However, at the moment, the
configured MINA time overrides everything.
In MinaListener.java:78 we have:-
acceptor.getSessionConfig().setIdleTime( IdleStatus.BOTH_IDLE, 10 );
So irrespective of the
With the standard IOListener, it was easy to trace each connection
within the log output, because each connection was handled by a
different thread. Filtering by thread ID, gave the full picture.
With the MinaListener, multiple connections are handled by a single
thread, and it's not possible to
45 matches
Mail list logo
