An interface for a module that provides database services.
A class that holds information about a stored database statement that can be executed later, possibly multiple times.
The interface all modules must implement.
A listener class that can be attached to a ModuleManager to get notifications about changes in module states.
The interface for the replacements system.
An interface indicating that your module will process the contents of the module element instead of relying on the automatic processing of ModuleManager.
A basic implementation of the Module interface.
An empty implementation of the ModuleListener interface.
A simple helper class for a single returned row, essentially just a HashMap.
A simple helper class for returned rows, essentially an ArrayList of Row objects.
This does some stress testing of DatabaseInterface, mainly intended for debugging memory leaks.
A basic implementation of the replacements system.
A module that provides email sending services for other modules.
A general purpose implementation of the DatabaseInterface using JDBC and thus being able to operate with many different relational databases.
A module that provides logging facilities for other modules.
A container class for other modules.
Main manager for the modules framework.
A class that contains all the different module settings.
A module manager that can be placed inside other module managers in a hierarchical fashion.
A base module implementation that adds some scripting functionality into the module.
This package contains a modular framework for applications and services. Most of the core logic of the framework is in the ModuleManager class which loads the modules, handles dependencies between them and starts and stops them. See its documentation for details on how to start using the framework.
The application or service built on the framework consists of any number of separate modules, which may have dependencies between them. Some of the modules typically implement certain interfaces and act as services providers for other modules. Then you typically have the modules that interface with the outside world and use the services provided by the other modules.
A typical use case is a web server where one module hooks into an http web server, or even acts as one. The incoming requests can then be forwarded to other modules that handle and reply to them. These modules then use other service modules, for example a relational database module, to do their work. The replies will often be created using a templating language so as to separate the logic from the presentation. The templating engine and the templates will be modules of their own too.
There are several pre-made modules designed with this type of server in mind, but it is by no means the only way to construct an application or a service with the framework. The org.wandora.modules.servlet package contains several modules which reply to http requests. These are called actions and derive from AbstractAction. The same package also contains the modules related to templates, currently the only implementation uses Apache Velocity but other templating languages could easily be added.
Additional documentation is available at http://www.wandora.org/wiki/Wandora_modules_framework
Copyright 2004-2015 Wandora Team