You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Niklas Gustavsson <ni...@protocol7.com> on 2005/09/18 22:06:26 UTC
[Ftpserver] Comments on the new code
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 different packages with some
in a special "interfaces" package and some not.
2. Logging, I'm not so sure that it's a good idea to invent our own
logging solution. There are plenty out there that works great and are
highly configurable. I think the cost of introducing a dependency is
lower then that of writing our own logger.
3. There is a great need for unit tests. I'll try to work on this.
4. In general, the code could be brokern down into more replacable parts
(think IoC). I'll try to work on this as well.
Anyways, great work!
/niklas
------------------
Niklas Gustavsson
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[FTPSERVER] How to set up virual directories?
Posted by Scott Szretter <sc...@eesco.com>.
I have set up the ftp server and I see how to set up user home
directories, but how do I set up a read only directory that certain
users all have access to in addition to their normal read/write home
directory?
--
powerful software and services: www.eesco.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Ftpserver] Comments on the new code
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Ftpserver] Comments on the new code
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
>
> 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
Posted by Enrique Rodriguez <en...@gmail.com>.
On 10/2/05, Niclas Hedhman <ni...@apache.org> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Ftpserver] Comments on the new code
Posted by Niclas Hedhman <ni...@apache.org>.
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 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 :-).
DI/IoC isn't dependent on a runtime platform, and I think Paul agrees that one
can make good DI/IoC without relying on Spring, Pico or whatever. Also, these
things tends to take religious proportions fairly quickly, so staying away
from any such commitment is a GoodThing.
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).
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Ftpserver] Comments on the new code
Posted by Craig Russell <Cr...@Sun.COM>.
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. But your Main code can
be trimmed down to just the DI needed to run the FtpServer.
Craig
On Oct 1, 2005, at 8:30 PM, Paul Hammant wrote:
> 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: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [Ftpserver] Comments on the new code
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [Ftpserver] Comments on the new code
Posted by "Noel J. Bergman" <no...@devtech.com>.
Actually, I think that perhaps we might want to look at OSGi, and supporting
FTPserver as an OSGi bundle.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Ftpserver] Comments on the new code
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Ftpserver] Comments on the new code
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
> 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 this.
>
> FtpConfig <- IFtpConfig <- FtpConfigImpl
> FtpStatistics <- IFtpStatistics <- FtpStatisticsImpl
>
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...
class XStreamFtpConfig implements FtpConfig { }
class FooUserManager implements UserManager {
FooUserManager( FtpConfig c ) {
// whatever
}
}
class SomethingComponentThatRequiresUserManager {
SomethingComponentThatRequiresUserManager( UserManager um ) {
// whatever
}
}
Also, for the record, a reusable component should not make a logging
framework choice :-)
Better would be a Monitor and an adapter to one of a number of
Logging Framework implementations.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Ftpserver] Comments on the new code
Posted by Rana Bhattacharyya <ra...@yahoo.com>.
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 this.
FtpConfig <- IFtpConfig <- FtpConfigImpl
FtpStatistics <- IFtpStatistics <- FtpStatisticsImpl
Thanks,
Rana Bhattacharyya
--- Niklas Gustavsson <ni...@protocol7.com> wrote:
> 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 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.
> >
> > So it bolis down to
> >
> > 1. No observer interface will have I prefix.
> > 2. No ftplet will have I prefix.
> > 3. Everything else will have I prefix.
> >
> > Thanks,
> > Rana Bhattacharyya
> >
> >
> > --- Niklas Gustavsson <ni...@protocol7.com>
> wrote:
> >
> >
> >>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
> different
> >>packages with some
> >>in a special "interfaces" package and some not.
> >>2. Logging, I'm not so sure that it's a good idea
> to
> >>invent our own
> >>logging solution. There are plenty out there that
> >>works great and are
> >>highly configurable. I think the cost of
> introducing
> >>a dependency is
> >>lower then that of writing our own logger.
> >>3. There is a great need for unit tests. I'll try
> to
> >>work on this.
> >>4. In general, the code could be brokern down into
> >>more replacable parts
> >>(think IoC). I'll try to work on this as well.
> >>
> >>Anyways, great work!
> >>
> >>/niklas
> >>
> >>
> >>------------------
> >>Niklas Gustavsson
> >>niklas@protocol7.com
> >>http://www.protocol7.com
> >>
> >>
> >>
> >
> >
>
---------------------------------------------------------------------
> >
> >>To unsubscribe, e-mail:
> >>general-unsubscribe@incubator.apache.org
> >>For additional commands, e-mail:
> >>general-help@incubator.apache.org
> >>
> >>
> >
> >
> >
> >
> >
> > __________________________________
> > Yahoo! Mail - PC Magazine Editors' Choice 2005
> > http://mail.yahoo.com
>
>
> --
> ------------------
> Niklas Gustavsson
> niklas@protocol7.com
> http://www.protocol7.com
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> general-unsubscribe@incubator.apache.org
> For additional commands, e-mail:
> general-help@incubator.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Ftpserver] Comments on the new code
Posted by Niklas Gustavsson <ni...@protocol7.com>.
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 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.
>
> So it bolis down to
>
> 1. No observer interface will have I prefix.
> 2. No ftplet will have I prefix.
> 3. Everything else will have I prefix.
>
> Thanks,
> Rana Bhattacharyya
>
>
> --- Niklas Gustavsson <ni...@protocol7.com> wrote:
>
>
>>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 different
>>packages with some
>>in a special "interfaces" package and some not.
>>2. Logging, I'm not so sure that it's a good idea to
>>invent our own
>>logging solution. There are plenty out there that
>>works great and are
>>highly configurable. I think the cost of introducing
>>a dependency is
>>lower then that of writing our own logger.
>>3. There is a great need for unit tests. I'll try to
>>work on this.
>>4. In general, the code could be brokern down into
>>more replacable parts
>>(think IoC). I'll try to work on this as well.
>>
>>Anyways, great work!
>>
>>/niklas
>>
>>
>>------------------
>>Niklas Gustavsson
>>niklas@protocol7.com
>>http://www.protocol7.com
>>
>>
>>
>
> ---------------------------------------------------------------------
>
>>To unsubscribe, e-mail:
>>general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail:
>>general-help@incubator.apache.org
>>
>>
>
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
--
------------------
Niklas Gustavsson
niklas@protocol7.com
http://www.protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Ftpserver] Comments on the new code
Posted by Rana Bhattacharyya <ra...@yahoo.com>.
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.
So it bolis down to
1. No observer interface will have I prefix.
2. No ftplet will have I prefix.
3. Everything else will have I prefix.
Thanks,
Rana Bhattacharyya
--- Niklas Gustavsson <ni...@protocol7.com> wrote:
> 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 different
> packages with some
> in a special "interfaces" package and some not.
> 2. Logging, I'm not so sure that it's a good idea to
> invent our own
> logging solution. There are plenty out there that
> works great and are
> highly configurable. I think the cost of introducing
> a dependency is
> lower then that of writing our own logger.
> 3. There is a great need for unit tests. I'll try to
> work on this.
> 4. In general, the code could be brokern down into
> more replacable parts
> (think IoC). I'll try to work on this as well.
>
> Anyways, great work!
>
> /niklas
>
>
> ------------------
> Niklas Gustavsson
> niklas@protocol7.com
> http://www.protocol7.com
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> general-unsubscribe@incubator.apache.org
> For additional commands, e-mail:
> general-help@incubator.apache.org
>
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org