Hi Niklas,
One of the reasons I left the original SITE command Map in place is
because I did not want to replace all of those commands, I only wanted
to add one or two new ones. In addition I did not want to pull back the
SITE command list, build a new Map with the old and new commands,then
replace the SITE command map. It was easier to just add the
setCommand() to the CommandFactory interface, and then implement the
method in the SITE class.
I think the user SITE commands should be in-addition to the existing
SITE commands. Think of the existing commands like an embedded ROM chip,
they will always be there, the user-ones may not, and if the user messes
up their side [think of flash], the embedded ones will still be there
and will still work. So I would just treat the existing SITE commands
as the default command map, and then add a user command map only if
there is at least one user SITE command defined. The SITE.getCommand()
method can look for the requested command in the default map first, if
it's not there, it can then search the user map (if one is defined).
A method such as isUseDefaultSiteCommands() is a good idea. Maybe just
add it to the CommandFactory interface? All commands have to use that
interface in any case.
Not sure what impact the above will have on Spring-based configuration
format, have to investigate it. On the surface it appears there will not
be any issues [hopefully not famous last words].
Andy Thomson
Niklas Gustavsson wrote:
Hi
Thanks for the proposal, this is an area we need to define a good
design to. Currently, as you note, the SITE command is not that very
flexible and would require subclassing/replacement to add in new
commands. No good :-)
As we are moving to the Spring based configuration format, the syntax
you describe below would be different and utilize the Spring beans
syntax. Or, whatever IoC framework you like to use. Or, if embedding,
standard Java code. But, we need to define the interface into which
the user can add his own SITE commands. My suggestion would be to
extend CommandFactory to include methods for registering these. For
example:
/**
* Get the registered SITE commands
* @return Active site commands, the key is
* the site command name, used in FTP
* sessions as SITE <command name>
*/
Map<String, Command> getSiteCommands();
/**
* Register SITE commands. The map can replace or
* append to the default SITE commands provided
* by FtpServer depending on the value of
* [EMAIL PROTECTED] CommandFactory#isUseDefaultSiteCommands()}
* @param siteCommands Active site commands, the key is
* the site command name, used in FTP
* sessions as SITE <command name>. The value is the
* command
*/
void setSiteCommands(Map<String, Command> siteCommands);
/**
* Should custom site commands append to or replace
* the default commands provided by FtpServer?.
* The default is to append
* @return true if custom commands should append to the default,
* false if they should replace
*/
boolean isUseDefaultSiteCommands();
/**
* Should custom site commands append to or replace
* the default commands provided by FtpServer?.
* @param useDefaultSiteCommands true if custom commands should
append to the default,
* false if they should replace
*/
void setUseDefaultSiteCommands(boolean useDefaultSiteCommands);
What do you think?
/niklas
On Sun, Jun 1, 2008 at 11:15 PM, Andy Thomson <[EMAIL PROTECTED]> wrote:
Proposal to add more flexibility to the SITE command. Attached is the
proposal details, patches, and user code example.
The change would allow a programmer [user] to add site-specific [SITE]
commands as mentioned in RFC 959.
The attached example provides a CHMOD command, ie., SITE CHMOD. The code is
very generic and can be used or adapted to support almost any local OS
command. A user can for example, add exotic commands such as DUAL for dual
hashing a file with both MD5 and SHA1 [or whatever algorithms they chose].
Note: If any one is interested in the DUAL command I will post the code.
The user-SITE "structure" follows the existing ftplet as far as
configuration.
Here is a snippet from a properties configuration:
##------------------------------------------------------------------------------
## All SITE commands
##------------------------------------------------------------------------------
#config.sitecmds=s1,s2
config.sitecmds=s1
##------------------------------------------------------------------------------
## Site command s1 configuration, CHMOD a file
##------------------------------------------------------------------------------
config.site.s1.class=org.apache.ftptest.command.SITE_CHMOD
config.site.s1.cmdname=CHMOD
##------------------------------------------------------------------------------
## Site command s2 configuration, DUAL Hash a file, MD5 and SHA-1
##------------------------------------------------------------------------------
#config.site.s2.class=org.apache.ftptest.command.SITE_DUAL
#config.site.s2.cmdname=DUAL
Users can call the command using what-ever name or naming style they like.
The 'cmdname=' just maps the user-supplied name to the command class. The
example SITE CHMOD could be SITE CHM or any other user-name.
The user must define a command class, this class uses the same structure as
all of the existing command classes. The class name must start with the key
characters 'SITE_' followed by some user-descriptive name. In the example
above, the chmod command class was called SITE_CHMOD. In addition the user
must extent or modify their FileOject code to allow the FileManager to
implement the command. The details are provided in the pdf and the example
code, very easy to do.
The implementation of the SITE change is also easy, only three core classes
are altered. All of them have additional methods added, and one implements
the CommandFactory.
Keep in mind there are many ways to achieve this, the code supplied here is
just one approach.
Comments? Suggestions?
Thank you,
Andy Thomson
---
Attached is a compressed tar file that contains the proposal details in pdf
format, patches for the core code, the actual files to the core code, and a
user example.
