Package org.jivesoftware.openfire.container
package org.jivesoftware.openfire.container
The microkernel core of the server is a simple, flexible, nested container framework defined in this package.
The container model consists of three primary participants:
- Service - A well-known Java object defined by a
Java interface. Code running in the server should be organized into
services that perform logical (and limited) blocks of work. These
services can then be exposed as a Java interface and obtained using the
ServiceLookup service. Although most services will be local to the
container, some may use RMI, web services, XMPP, or other remote
procedure call technologies to provide services across the network.
- Module - The smallest server deployment unit. A
module has a well-defined life cycle that is managed by its hosting
container. A module may contain zero or more services and client code
that accesses these services. Modules can be deployed and configured
individually, allowing the easy implementation of server plugins and
on the fly reconfiguration of the server.
- Container - A special module that hosts server modules including other containers. Hosting involves life cycle management of child modules, configuration of child modules, and providing access to shared resources. Containers also provide their own configurable security managers and custom classloaders that extend the classpath to automatically include module classes and jar files located in well defined locations (e.g. similar to WEB-INF/lib and WEB-INF/classes in a J2EE web-app/WAR).
The nesting nature of containers allows a tree-like server
architecture with a root 'bootstrap container' with core modules, and
child containers with their own modules. Child containers by default
inherit and extend the bootstrap container's classpath and services
while being protected from implementation details of any modules,
containers, or services in layers above them. In some cases, child
containers may have restricted views or access to upper levels of the
tree (e.g. a user plug-in container that allows users to add arbitrary
server extensions).
-
ClassDescriptionThe admin console plugin.A default Module implementation that basically avoids subclasses having to implement the whole Module interface.Configuration to use when creating caches.Task that will return the bind interface and ports being used by the admin console of the node where the task will be executed.Task that will be run in each cluster node to learn if the specified plugin is installed or not.Logical, server-managed entities must implement this interface.Plugin interface.A helper class to read cache configuration data for a plugin and register the defined caches with the cache factory.A simple registry of cache configuration data for plugins.ClassLoader for plugins.Servlet is used for retrieval of plugin icons.Allows for notifications that a plugin has been either created or destroyed.Manages plugins.Interface to listen for plugin manager events.A bean-like representation of the metadata of a plugin.Various helper methods to retrieve plugin metadat from plugin.xml files.A service that monitors the plugin directory for plugins.The plugin servlet acts as a proxy for web requests (in the admin console) to plugins.A Servlet Context to be used by Openfire plugins.