Hi,I enthusiastically endorse Paul's comment that you should be agnostic as to which DI framework is used with FtpServer.What might be more practical is for you to ship sample code that shows users of Pico, Spring, etc. how to configure your FtpServer component using their metadata specifications.
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
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 suggest
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);
On Sunday 02 October 2005 06:52, 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
Actually, I think that perhaps we might want to look at OSGi, and supporting
FTPserver as an OSGi bundle.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 im
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
The package ftplet is the basic API required to add
custom user specified ftplets. The server needs
slightly modified version of these APIs. Ftplet API is
somewhat fixed but server API may get changed in
future. This is the reason behind this difference. The
following two hierarchy will clarify
The package ftplet is the basic API required to add
custom user specified ftplets. The server needs
slightly modified version of these APIs. Ftplet API is
somewhat fixed but server API may get changed in
future. This is the reason behind this difference. The
following two hierarchy will clarify th
Hi
why is this difference necessary? Or maybe rather, why the need for the
I-prefix on the "internal" interfaces?
/niklas
/niklas
Rana Bhattacharyya wrote:
> Hi,
>
> This is the logic behind the interface name.
>
> 1. ftplet is basic interface package which will be
> exposed to add custom
Hi,
This is the logic behind the interface name.
1. ftplet is basic interface package which will be
exposed to add custom ftplet.
2. The package interfaces has all the other interfaces
used in the server. Here all the observers will not
have I in front. Everything else will have I in front.
Hi
I've taken a quick look through the new code for Ftpserver commited by
Rana. For the most of it I'm impressed and think it looks very good. I
do have some minor comments though:
1. Interfaces are inconsitently named, some starting with "I", some not.
They are also somewhat randomly placed in
13 matches
Mail list logo
