Re: [Ftpserver] Comments on the new code
You should aim to ship with neither Spring nor PicoContainer. It is perfectly possible to construct a set of DI components that comprise FtpServer and in a main method do : Foo foo = new Foo(); Bar bar = new Bar(foo); Apple apple = new Apple(); apple.setFoo(foo); apple.setBar(bar); This way, open doors for others to take your components and ship standalone, or using Spring as part of a later app, using Pico as part of a larger app, using Geronimo or using EJB 3.0 (etc). Choosing a DI framework early is nuts. - Paul On Oct 1, 2005, at 5:52 PM, Niklas Gustavsson wrote: Paul Hammant wrote: OK, if we're keen about Dependency Injection, we'd need to change a lot. The basic FtpConfig component should have little knowledge of UserManager (and others), and no coupling to it... If we do aim for a DI/IoC approach (and I think we should), should we choose a DI implementation (Pico, Spring...) that we ship as the default implementation? Or, should we try to implement a specialized runtime ourselves? I would certainly go for the former option and would favour Spring but I'm guessing that Paul won't agree on this choice :-). /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Ftpserver] Comments on the new code
IMHO, the basic design and implementation should be XML free and provide a straight forward API for assembly, configuration (preferably atomic) and the other stuff. Any runtime platform support can be added on top of that. Look at Jetty for an example of this approach. Now, Noel's suggestion for OSGi as the runtime platform is interesting, if for no other reason than it allows for hot deploy and reloads. But I think it would be possible to provide a BundleActivator and register the service(s) even if FtpServer does not require OSGi by definition, if the above approach is done well (again Jetty is an example of OSGi bundle on top of its API). You're assuming that frameworks other that OSGi cannot do hot deploy, but yes the general idea is to have something akin to POJOs with no extends/implements/throws from any framework and optional enablers to other frameworks in separate classes or module etc. It has to be said though that OSGi is on a different branch of the IoC family tree to DI favoring frameworks. - Paul
Re: [Ftpserver] Comments on the new code
On 10/2/05, Niclas Hedhman <[EMAIL PROTECTED]> wrote: ... > Now, Noel's suggestion for OSGi as the runtime platform is interesting, if for > no other reason than it allows for hot deploy and reloads. But I think it > would be possible to provide a BundleActivator and register the service(s) > even if FtpServer does not require OSGi by definition, if the above approach > is done well (again Jetty is an example of OSGi bundle on top of its API). I believe I've now seen both OSGi and MINA (NIO framework) recommended for the FtpServer. Just to make you aware, there is a MINA OSGi bundle in Apache SVN at: http://svn.apache.org/repos/asf/directory/standalone/trunk/osgi/network/ As Niclas et al have recommended, MINA doesn't require a container; this is an OSGi wrapper to register the MINA SimpleServiceRegistry impl into an OSGi container as the ServiceRegistry interface, for use by protocol providers. HTH, Enrique - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
