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:4d83598117594243614118! >> >> > > >
