Hi all,
I'll bring the discussion on my proposed changed to how we configure our
FtpServer components to the mailing list instead of the JIRA issue
(http://issues.apache.org/jira/browse/FTPSERVER-31) as I think this is
probably a more appropriate place for discussions.
As you have understood from the issue and the patch I do not particulary
like the way we currently do configuration. Right now, all our
components are tighly bound to a FtpServer specific lifecycle and
configuration. That is, that implementations (e.g. UserManager,
IConnectionManager, FtpStatistics) must implement Component to be used
by FtpServer. Component adds a life cycle and a configuration method
that is specific to how FtpServer internally works. This makes the
implementations harder than necessary to reuse in other contexts.
Rana, on the issue comments you note that you think getter/setters are
more complex than the configure(Configuration) design. I strongly
disagree as I think more Java developers are used to getters/setters
than the FtpServer specific configuration. Using getters/setters also
makes it possible to use these classes with Pico/Spring-like frameworks.
Also, the way its currently works its hard for an external developer to
create, for example, an UserManager implementation on his own and use
within FtpServer. For that to work he would need to also need to create
his own configuration and a subclass of FtpConfigImpl. Instead I would
propose a design where, for example, UserManagers are injected on
FtpServer. This is more similar (as pointed out by Niclas Hedman I
think) to how Jetty works.
As a last note, I do not see why writing FtpServer specific classes
implementing Component for each type of dependency (for example
DataSource which is mentioned in the issues comments) should be needed.
Again, this forces developers to write/use even more FtpServer specifics
to reuse or extending classes from FtpServer. A developer should be able
to inject a DataSource retrived from JNDI or a Pico/Spring configuration
without additional wrapping.
I'm not a commiter so feel free to ignore this discussion and patch if
you don't feel its in line with the vision for FtpServer. However, I
would recommend a much more open design for FtpServer and I think that
the IoC pattern (of which this patch is the first very tiny step) is the
appropriate way to go :-)
/niklas
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]
