Sorry, I did not realize that the Spring wiring implicitly uses a LinkedHashMap which preserves the entry order in the configuration.
I also think that this is just fine because this way one may achieve any order wanted. --cg > -----Original Message----- > From: David Latorre [mailto:[email protected]] > Sent: Monday, March 21, 2011 1:36 PM > To: [email protected] > Subject: Re: FTPlet entrySet: Sort order for multiple active FTPlets? > > If you read the case that sai himself opened, you'll see that the > Spring config generates a subclass of LinkedHashMap which is enough to > preserve order of execution. > > So, for theI users wiring the server via Spring there's no need to > specify a Map version. For embedders invoking the API methos > directly, I agree with Niklas that we shouldn't force them to use > LinkedHashMap (what if they want to use a SortedMap?) or any other map > implementation, execution order here is the responsability of the > user, not ours. > > This said, Sai has a valid point when he speaks about predictability > and I could be led to agree with him if he still insisted on that > option. But, if javadoc is OK I don't think this change is really > needed, and would mean breaking our API so it would be available just > for the 'trunk' version. > > > 2011/3/18 Christian Gosch <[email protected]>: > > Hmm... > > > > To refer to the closed issue, it would be helpful if the example Spring > > configuration named "config-full.xml" would contain a ftplets element > > which *does* define a Map type to use -- but I cannot see anything like > > this inside this file (see the attached files, as of v1.0.5, > > 2010-SEP-26, 6:24PM). > > > > > > --cg > > > >> -----Original Message----- > >> From: Sai Pullabhotla [mailto:[email protected]] > >> Sent: Friday, March 18, 2011 2:09 PM > >> To: [email protected] > >> Subject: Re: FTPlet entrySet: Sort order for multiple active FTPlets? > >> > >> Well... there was a open case about this, which is now closed... > >> > >> https://issues.apache.org/jira/browse/FTPSERVER-223 > >> > >> Are you sure this is still an issue? > >> > >> On Fri, Mar 18, 2011 at 7:46 AM, Christian Gosch > >> <[email protected]> wrote: > >> > Hi, > >> > > >> > I just looked at the implementation of > >> > DefaultFtpletContainer.onConnect() and saw that it processes all > >> > contained (registered) Ftplets by traversing the (concurrent hash) > > map > >> > of declared Ftplets, just as onDisconnect(). > >> > > >> > But it does so based on the ftplets.entrySet() and the sort order > > which > >> > it imposes on the entry set, which in turn is "undefined" in that it > >> > does not guarantee any special sort order. > >> > > >> > Why is the concurrent map ftplets not implemented as a map with a > >> > reliable sort order depending on the key values? > >> > > >> > It may be good practice to have every registered Ftplet act > >> > independently of any other in the same container, but there may be > > good > >> > reasons to have an ordered sequence, may be by order of declaration, > > or > >> > by order of key or whatever may be appropriate. > >> > > >> > Is there a special rationale behind this? > >> > > >> > > >> > btw: I did not yet find any time to play around with this really :-( > >> > > >> > > >> > Regards, > >> > -- > >> > Dipl.-Inform. Christian Gosch, PMI PMP > >> > Systems Architecture, Project Management > >> > > >> > inovex GmbH > >> > Büro Pforzheim > >> > Karlsruher Strasse 71 > >> > D-75179 Pforzheim > >> > Tel: +49 (0)7231 3191-85 > >> > Fax: +49 (0)7231 3191-91 > >> > [email protected] > >> > www.inovex.de > >> > > >> > Sitz der Gesellschaft: Pforzheim > >> > AG Mannheim, HRB 502126 > >> > Geschäftsführer: Stephan Müller > >> > > >> > > >> > > >> > > >> > >> > >> > >> > > > > > > > > !DSPAM:4d87464117597606014571! > >
