JXplorer (JX) is built in a traditional, layered manner. A data access layer, comprised of various DataBrokers is used to access the data (either LDAP, LDIF or DSML) and provide it to the program as internal JX objects. Various internal helper functions handle security, i18n and other 'housekeeping'. A graphical layer then serves the data up to the user.
JX defines a DataSource interface that describes the functionality expected of a data source (read and write, operations, and potentially some schema handling).
The DataSource interface is implemented by a number of Broker classes; a JNDIBroker class, an OfflineBroker (for LDIF files), and a SchemaBroker for parsing ldap schema.
These Data Brokers read the data (see the thread section for more details) and supply it as objects of the naming package. This provides entry, name and attributes classes, usually extending similar jndi classes.
Currently this is only used for ldap connections, and JX provides functionality for SSL and LDAP SASL (using client certificates). There are two parts to security in JX, firstly the keystores containing the certificates needed for SSL, and secondly the SSL provider itself.
There are two certificate keystores. The first lists the certificates of trusted servers and certificate authorities, the second the user's own certificates and private keys.
There is a reasonably comprehensive keystore management GUI and certificate viewer built in to JX, however from an architectural point of view the GUI is independant - it modifies the keystores completely separately from JX, and the keystores are stored in separate files (usually under /security, unless the user has modified this).
The communications side simply assumes the keystores have been set up correctly. When an SSL or SASL bind is attempted, the JndiSocketFactory SSL Socket Factory class uses the keystores to establish the connection, by simply reading their details and passing them off to an internal SSLSocketFactory.
By default we simply use Sun's JKS (java keystore) which ships with the
standard security provider. However arbitrary security providers may be added
to JXplorer by listing them in the dxconfig.txt file; e.g.:
securityProvider=your.security.provider.here.Provider
which may make other keystore types available.
Users can also substitute their own keystores (of any allowed type), simply by specifying their location in the security options menu.
JX uses a CBIntText.get() translation method wherever a GUI string appears (or at least it should :-) ). This simply runs a test string from the program through a translation module to determine if a translation exists.
The CBIntText class is intialised at program start, when JX looks for a translation file based on the current machine locale. The file is similar to a Java properties file, but accepts UTF8 and Unicode. (Normal java properties files use a bizarre 'java escaped unicode form' that is just plain wierd, and not supported, as far as I know by any word processor on the planet...)
Translation lists are produced through the use of a couple of perl scripts (see cvs) which search the code base producing a unique list of words and phrases that require translation to be generated (they can also do diffs using previous tranlation files).
Users can write their own translation files, which are usually placed in the /language folder, and must have the format "JX_[language code].properties" (e.g. JX_de.properties for german).
After a directory query is completed, the results are displayed in two main places; the browsing tree and the entry display pane.
The three browsing trees display the structure of the directory, the search response (if any) and the schema).
The tree icons can be replaced or extended; they are keyed on the object class of the displayed entries.
The entry display shows a single entry in a number of tabbed viewers. Normally there are two viewers; and HTML viewer and a table editor. The HTML viewer uses stored html templates, while the table editor shows string attributes and values in a two column list.
In addition, custom java editors can be written to be activated when certain object classes are read. These can replace the other two editors, or can appear as further tabs.
The HTML templates can be extended simply by adding new templates to the stored examples. They are arranged in sub directories by object class.
The Table Editor has a number of custom attribute editors (for passwords, certificates and so on) by default, others can be written in java as editors extending the Attribute Editor interfaces.
Finally pluggable entry editors can be written by extending the PluggableEditor interface, allowing a java gui plugin to be displayed when an entry with a particular object class is accessed.