semper.util.install
package
which provides a framework for intsalling and uninstalling
third-party modules into SEMPER. This description is about a first-cut
design and prototype.
semper.util.install
package
which provides a framework for intsalling and uninstalling
third-party modules into SEMPER. This description is about a first-cut
design and prototype. Eventually, this design/implementation should be
merged with the overall SEMPER framework for downloading and
installing applications and module updates (see SEMPER activity paper
321IN010).
Check the source for the semper.util.install
for more
recent versions of this document.
The basic services for
installation/uninstallation are provided by the
Installer
class. It also provides a menu-launchable Installer application that
makes use of these services.
The "distribution" of the module must be available in a separate directory. The directory should contain:
name
- name of the module (e.g. SET
)
block
- SEMPER block to which the module
belongs (e.g. payment
)
author
- identification tag for the author of
the module (e.g. ZRL; there is no standard name space for
this yet)
purseClassName
). In
addition, a number of optional properties are supported by the
standard Installer:
dlls
- primary names of dynamically linkable
libraries installed by the module; e.g. CRM
is
the primary name for the Cryptomathic crypto library.
packages
top-level package names for package
sub-trees installed by the module;
e.g. semper.payment.SET
. A module is allowed to
claim package names either within its own space in the
SEMPER package hierarchy (e.g. SET
adapter for
the payment
block can install any package
prefixed with semper.payment.SET
or any name
outside the SEMPER hierarchy.
packages
property was set, then there
must be one
directory for each package sub-tree specified, containing the classes
for the package subtree (there can be sub-packages in the package).
E.g. if packages
was set to <Digicash
semper.payment.ecash
> then there must be two
sub-directories by the same names in the
distribution. The Digicash
directory will be moved to
lib/java/classes/Digicash
directory and the
semper.payment.ecash
directory will be moved to
lib/java/classes/semper/payment/ecash
. Missing
directories is considered a critical failure.
dlls
property was set, then there
can be
various versions of the each dll specified (one for each
platform). The files are named:
lib<BASENAME>.so.<OS> in the case of Unix
(e.g. libCRMlib.so.aix) and <BASENAME>.windows.dll in
the case of Windows (e.g. CRMlib.windows.dll). The correct
file will be moved to lib/java/dll/<OS>
directory. Missing dlls is not considered a critical failure
(since some dlls seem to be available/necessary only for some
platforms) .
For interactive installation, the properties file must be named
props.txt
.
The installation process consists of the following steps:
Install
class in the module (if available)
Install
class in the module (if available)
Installer
when a module is being
installed/uninstalled.
As noted above, there are two types of installation hooks available.
A block can implement the BlockInstallHook
interface in a class and register the class with the
Installer
. The Installer
will invoke the
appropriate interface methods from an object of this class whenever a
module is installed into the block. See payment block installation
hook for an example.
The module itself can avail itself of an installation hook by having a
class named Install
which implements the ModuleInstallHook
interface. The class must be available in the main package for that
module (i.e. the package named
semper.<BLOCK>.<MODULE-NAME>
For example, the
installation hook for the SET
module of the
payment
block must be named
semper.payment.SET.Install
).
ecash
. It belongs to the payment
block. It
comes with a shared library with the base name ecash
. It
also has two java packages: semper.payment.ecash
and
Digicash
. Since it belongs to the payment
blocks, it has a sub class of the Purse
class called
semper.payment.ecash.ecashPurse
. Finally, the native
ecash shared library uses the environment variable
ECASH_TMPDIR
to figure out the name of the directory for
temporary files. To package the ecash module for distribution, you
will do the following:
semper.payment.ecash.Install
implementing the Install
which implements the ModuleInstallHook
interface.
The implementation of the preInstall
method can
query the user for a temporary directory and submit that to the
environment interaction
front-end for registration.
Digicash
and
semper.payment.ecash
packages and move them under
the distribution directory with the same names
ecash
library
(say libecash.so.aix
,
libecash.so.solaris
, and
ecash.windows.dll
and copy them under the distribution
directory
props.txt
containing:
name=ecash block=payment creator=DIC packages=Digicash semper.payment.ecash dlls=ecash purseClassName=semper.payment.ecash.ecashPurse
semper.util.install
.
The documentation includes an index
and a
tree depicting the class structure.