incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject First Analisys on FTPServer
Date Thu, 20 Oct 2005 17:29:42 GMT

        I saw the latest source files currently included in the 
apache-incubator CVS repository, and  i was able to identify some 
conflicting points with the solution that we are developing (regarding 
jftp4i). First, i saw that the FTPServer Ftplets are features running 
under a single instance of the server, that means, when the server starts, 
all the Ftplets are defined inside one single instance inside the 
container, so these classes are actually running in a single macro 
application (please correct me if i'm wrong):
                        +--- Container
                        +--- Ftplets
        In our solution, we are implementing a set of applications that 
can be deployed (inside a *.far file) inside a directory called ftpapps on 
the root directory of the jftp4i server. The engine then maintain these 
*.far resorces as different application instances on the server (very 
similiar to an application server using war files). On each application 
instance, we will have basically a set of files (FTPActions (similiar to 
your Ftplets), FilterEvents, etc.) that are linked to a number of users 
(that are current logged) and to a number of context-roots. When the user 
logs into the server, he automatically see the ctx-roots that he (or she) 
can access, and inside of each ctx-roots, the container have different 
applications responding to all the resources deployed inside the *.far 
file (each far file is an application to the container - not a far pointer 
(kkkk :-)) ).

        The server structure looks something like this:
          +-- lib/ (necessary library to run the server)
          +-- logs/ (log and trace directory - the transaction container 
uses the trace to control all the steps inside an FTPAction)
          +-- META-INF/ (jftp4i specific configurations - here is where 
you define the applications running on the server)
          +-- ftpapps/ (where the *.far files are deployed - by default, 
the server will have a default.far file to attend all unconfigured client 

        The structure inside the far file look like this:
        /(any resource and(or)  directory to be supported by the FTP 
              +-- classes/ (FTPActions, Filters, etc..., binary files)
              +-- lib/ (application specific libs)
             ... (application specific descriptors like jftp4i-app.xml)

        An analysis the two solutions, shows that we gonna have a huge 
amount of change and time to merge these projects, and i don´t want to 
start anything without your authorization (evaluation). Of course we also 
don´t want to change anything that you may already spended so much time 
on. So, if you permit me, i want to suggest one thing. Maybe we could 
start the adaptation of the jftp4i (to the JFTPServer) as a FTPServer 
plugin (a subproject of JFTPServer) - some changes may still be necessary 
to adapt the current JFTPServer for supporting the application-server 

        This is one possibility, please tell me what you think about it.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message