Hi, Let me express my point of view and why suddenly I have raised the issue.
If we want to embed the FTP server in an application which already has different components like UserManager, FileSystemManager etc, we have to set those components in the FTP server. Currently there is no way to set those components. The developer has to model the components according to our configuration structure. In our current implementation both the UserManager and SecurityManager are merged into one - UserManager. In many cases, UserManager, FileSystemManager and SecurityManager are clubbed into one. So implementations are same even though it implements many interfaces. There is no way we can address this issue. The current structure does not support common dependency very well. For example UserManager, FileSystemManager and SecurityManager depend on one component like DataSource. At this moment I am not very confident of using any existing IOC framework. I have already struggled once to move out from Avalon mess. I do not want to be in the same situation again. But we can model our component structure such that it can be used in existing application very easily without changing much of our configuration, interfaces. Now I am working on refactoring our FileSystemManager. I have gone through many FileSystem APIs. We shall model our FileSystem according to Apache VFS. I shall add another FileSystemManager to use Apache VFS. It will not take more than a month. After that we can address the IOC issue in more detail. Thanks, Rana Bhattacharyya --- Niklas Gustavsson <[EMAIL PROTECTED]> wrote: > Martin Fowler wrote an excellent writeup on the IoC > pattern some time > ago. In that paper, he describes three types of IoC > injection methods: > Type 1. Interface injection, like Avalon. > Type 2. Setter injection, like > setUserManager(UserManager um) > Type 3. Constructor injection, like > FileSystemView(UserManager um) > > Over time, most (if not all) IoC frameworks has > moved into supporting > type 2 and 3. This includes EJB3, even though EJB3 > in it self has some > limitations. However, I find that most IoC > frameworks work much the same > way. But, like Paul (and someone else) wrote some > time back, maybe > FtpServer should not pick a framework but instead > just enable the use of > one. For the default implementation we can string > together components in > code but leave it up to others to reuse FtpServer or > parts of it within > any framework. Even so, I think picking one of the > minimal frameworks > might suite FtpServer best as we might be able to > use some of the > features they offer (like autowiring or XML > configuration). > > Also, what I really like about type 2/3 injection is > that you can > clearly visualize your dependencies, may they be > configured using code, > XML or some other way. > > /niklas > > Sergey Vladimirov wrote: > > Niklas, > > > > I'm sure that IoC is good pattern, but i'm not > sure that is right > > subject to > > discuss it :) > > Anyway, adding some light-weight implementation of > Avalon Framework, or, > > may > > be EJB3-like (Merlin?) framework is good idea, > from my point of view. > > > > However, could you please describe "2/3 IoC" > pattern? I know what is IoC > > (we > > using it for 5 years already), but even Google > didn't hear about 2/3 > > modification :) > > > > Sergey > > > > 2006/5/6, Niklas Gustavsson > <[EMAIL PROTECTED]>: > >> > >> Still around :-) > >> > >> Using a more direct IoC (or DI) makes > dependencies very clear and easy > >> to change. Also, it will remove the need for some > (but not all) > >> factories. So, if you are up to it, I propose > moving into a type 2/3 > >> IoC, rather than the current model. > >> > >> /niklas > >> > >> Rana Bhattacharyya wrote: > >> > Hi, > >> > > >> > These are the things I understand. > >> > > >> > 1. SecurityManager and UserManager are two > different > >> > activities. So there should be two different > >> > components where UserManager is an optional > component. > >> > > >> > 2. SecurityManager will use Credentials and > >> > UserManager will use User. As the UserManager > is an > >> > optional component, the User is also an > optional > >> > object. > >> > > >> > 3. FileSystemView depends on what .... > Credentials or > >> > User? It is not very clear. > >> > > >> > 4. We will be able to create User when we have > an > >> > UserManager (which is an optional component). > >> > > >> > Please write your comments about my > understanding. Let > >> > us first clarify our doubts then we shall think > about > >> > implementations. We do not want to modify the > codebase > >> > in a hurry when there is a major change. > >> > > >> > Now I understand what Niklas Gustavsson meant > by > >> > "Inversion of Control" :). > >> > > >> > Niklas, where are you? > >> > > >> > Thanks, > >> > Rana Bhattacharyya > >> > > >> > > >> > --- Sergey Vladimirov <[EMAIL PROTECTED]> > wrote: > >> > > >> >> Hi, Rana, > >> >> > >> >> 1. User Manager can use any User > implemetation, this > >> >> is true. But what > >> >> should, for example, FileSystemManager use if > it > >> >> need user implementation > >> >> from UserManager, not BaseUser? > >> >> For current moment it need to take user name > from > >> >> request and lookup for > >> >> actual User from UserManager. > >> >> I don't think it is good. I don't think that > >> >> isolation User from UserManager > >> >> and User in request is good idea. In fact, my > own > >> >> implementations of > >> >> FileSystemManager and SecurityManager would be > much > >> >> simple with just storing > >> >> User from UserManager in Request. > >> >> More over, it is much better from perfomance > point > >> >> of view. > >> >> > >> >> 2. Creating Users should be optional > possibility of > >> >> UserManager, not > >> >> FTPServer. One more time about mine > implementatios - > >> >> they don't allow to > >> >> create new users at all. > >> >> If "setters" needs only to create users, just > leave > >> >> them in > >> >> AbstractUserManager which would use BaseUser. > >> >> > >> >> 5. Using BaseUser as Credentials is confusing. > I > >> >> prefer to set user to null > >> >> until it is logged-in. > >> >> > >> >> Sergey > >> >> > >> >> 2006/5/5, Rana Bhattacharyya > <[EMAIL PROTECTED]>: > >> >>> Hi, > >> >>> > >> >>> Please find my comments below. > >> >>> > >> >>> 1. User manager can use any User > implementation. > >> >> It is > >> >>> not necessary to use BaseUser. It just > happens > >> >> that > >> >>> the user managers provided with the server > use > >> >>> BaseUser. > >> >>> > >> >>> 2. From API point of view, we only need the > >> >> getters > >> >>> method from the User interface. But for > setting we > >> >>> need setters. So BaseUser has both getters > and > >> >>> setters. We need these setters for creating > users. > >> >>> > >> >>> 3. The FTP server populates BaseUser to > isolate > >> >>> UserManager provided User implementation and > the > >> >>> BaseUser used internally. We do not assume > that > >> >> the > >> >>> UserManager provided User is BaseUser. > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
