Presentation
OpenLSD is based on 3 eclipse packages. For each of them, you have to open them in eclipse as separate projects (OpenLSD, OpenLSDWebAdmin, OpenLSDC).
OpenLSD main project
OpenLSDWebImpl sub project for web support (using servlet in Tomcat)
-
OpenLSDC which proposes some optimization written in C but is not mandatory (getFileFromPath and openlsddu available for Windows, AIX)
A fourth project OpenLSDImpl is included and is about an example of extension-rewrite of the Business part so as to explain how to use the OpenLSD Framework.
Optionally there is the module fast_md5 which enable optimization to compute MD5 using a C library (".dll" under windows, ".so" under Linux or AIX as tested now).
The project depends on external jars. Most of them are the standard up to date version. Some of them are using one specific version or adapted version. All of them are in ALLJARS.zip.
Standard external jar versions
Commons apache libraries:
- commons-fileupload-1.2.jar
commons-io-1.3.2.jar
commons-codec-1.3.jar
-
commons-lang-2.3.jar
XML support:
dom4j-1.6.1.jar
-
jaxen-1.1.1.jar
MINA and relevant libraries:
jzlib-1.0.7.jar (compression support)
slf4j-api-1.5.0.jar (log support associated with logback)
logback-access-0.9.8.jar
logback-classic-0.9.8.jar
-
logback-core-0.9.8.jar
Factory resource for JDBC from Tomcat:
commons-el.jar
naming-factory.jar
naming-factory-dbcp.jar
-
naming-resources.jar
Oracle support:
PostGreSQL support:
-
MySQL support:
Specific external jar versions
Versions of JAR are constructed with JDK6. If you want to use JDK5, it works but you have to download source files of dependant project to get JAR in JDK5 format.
The global logic
No database is needed for OpenLSD Server since it does not assign index, those are given by the client through the message. The OpenLSD Client is responsible to take care about the business logic and also the database support (whatever the database is) and to assign one new index when necessary. The main reason of this organization is to enable a stable development of the Server part, whatever the Client does.
For one application, one team will have therefore to only focus on the client part and to start by extending classes from OpenLSD to meet their wishes. One example in the source code is the ATLAS application which stands for a generic and simple document archiving process.
OpenLSD project is organized in different directories
Server: this part is the kernel part for OpenLSD Server
ServerApp: this part is some applications that should be started from the same server that runs the OpenLSD Server itself.
ClientSupport: this part is the kernel part for OpenLSD Client
ClientApp: this part are for applications that run as Clients (Admin part, Check part, Session check part) and for the kernel part for the Business support (database access, import logic, delete logic, …)
BusinessImpl: this part is the implementation specific part for the Business
WebSupport: this part is the kernel part for the OpenLSD Servlet support
Common: this part is about some global classes need by every package
-
Multiple: this part is the implementation of some functions in Multiple Legacies mode support and of the specific Op Handler to maintain the LSD mirroring
OpenLSD is then subdivided in multiple jars
OpenLSD-Server.jar: Server and ServerApp parts
OpenLSD-Common.jar: Common part
OpenLSD-Web.jar: WebSupport part
OpenLSD-Client.jar: ClientSupport, ClientApp
OpenLSD-Impl.jar: BusinessImpl part
-
OpenLSD-Multiple.jar: Multiple Legacies support part (same use than Client.jar but in Multiple Legacy Mode plus the OpHandler)
Here is a presentation of the jars needed according to the functions:
|
Function |
Server.jar |
Client.jar |
Multiple.jar |
Web.jar |
Impl.jar |
Common.jar |
|
OpenLSD Server |
X |
|
|
|
|
X |
|
OpenLSD Client (get, put, admin) |
|
X |
X |
|
X |
X |
|
OpenLSD Heavy Client (check consistency, init storage, check binary similarity, import based on check similarity) |
X |
X |
X |
|
X |
X |
|
OpenLSD Web in servlet (with the war from OpenLSDWebImpl) |
|
X |
X |
X |
X |
X |
Jars can be constructed from “jardesc” on the top of the OpenLSD Eclipse project. They should be modified to reflect the localization of the directory that will contain the jar files. To do that, just edit each file by modifying the following part:
<jar path="D:/ALLJARS/OpenLSD-Server.jar"/>
Some other directories are present in OpenLSD
Config: files as example for the configuration of OpenLSD or the database (both Windows or Unix versions)
Doc: API documentation
-
Scripts: file as example to run some specific function as start OpenLSD Server, shutdown, import files, Check consistency, Check sessions, Delete files (both Windows or Unix versions and Windows example for PostGreSQL almost identical to Oracle version)
OpenLSDWebImpl contains the following examples
Admin functions (local and distant)
-
Client simple functions (get with or without MINA pool of connection, get and put with or without compression, delete support)
OpenLSD contains the following example scripts
All of them exist in bat or sh versions. All of them are to be considered as example and not as production ready. You have to adapt them to your needs.
-
Admin functions:
LSDInitOraFromConfigFiles to initialize values in the database according to the configuration files in XML,
LSDServerOra to start LSDServer,
LSDAdminOraShutdown to stop LSDServer,
-
LSDAdminOraInitStorage to create some new Storages in each Legacy.
The main class openlsd.appli.admin.LSDAdmin has more options. You can create new scripts as needed. Take a look at the code to know what options are available.
Other versions exist like xForStorage (for one storage only) or xPL (using a PL/SQL procedure to go faster). Also an option concurrent enables to run it while OpenLSD Server is also running on both import and delete but at the price of slower run due to synchronization issue.
-
LSDCheckInDBThreadedOraML and its DualLimit version to check the consistency between one LSDServer from Multiple Legacies and the associated LSD database. The main idea here is to first load simple definition of each file (technical index and MD5 value), then to compare them with they internal database representations, and finally to check the Storage consistency (size and internal values). There are several options that are supported, such as check without any correction applied, or check with corrections applied on LSDServer storage only, on database only or both.
LSDImportNetOraML to import files from a directory through the network interface using a limited number of database connection from a source definition file. The importer is not on the same server than the LSDServer. This version implies the use of the Op Handler.
LSDImportOraML to import files one by one from a source definition file using a limited number of database connection from a source definition file. The importer must be physically on the same server than LSDServer. This version implies the use of the Op Handler.
LSDImportOra-BLOCKML to import files by group of files from a source definition file using a limited number of database connection from a source definition file. The importer must be physically on the same server than LSDServer. This version implies the use of the Op Handler.
LSDServerImportXXXCheckSimilarOraML (where XXX can be empty or BLOCK) to import files as LSDImportOra or LSDImportOra-BLOCK but using the CheckSimilar function before the import, so as to check if the document already exists on a binary comparison check. This function only runs on the OpenLSD Server that hosts the Legacy and with non crypted Legacy. This version implies the use of the Op Handler.
LSDDeleteML to delete files from database and LSDServer storage. This function is obviously sensible. This version implies the use of the Op Handler. This function is for now immediate (delete immediately after asked), it could be later on with a delay to handle errors of users.
LSDAutoImportOra-fromDirML or LSDAutoImportOra-fromDir-BlockML to import files one by one from a directory or by a group of files from a directory and as a permanent importer (so the name auto import). These auto importers have to be physically on the same server than LSDServer. To stop them, you have to create a specific file as a shutdown order. This version implies the use of the Op Handler.
-
LSDOpHandlerML to launch the Op Handler which is responsible to maintain the consistency between all Legacies that are in relation (replication). It uploads or deletes documents in other Legacies according to the action taken and registered using ML versions.
