openfire

Supporting classes and tags for the admin console.

Database connection code.

Service that records XMPP traffic.

Authentication and Authorization service interfaces and classes. There are three compoents:

• Authentication. Authentication is the process of verifying a user. Custom authentication implementations can be created by extending the {@link org.jivesoftware.openfire.auth.AuthProvider} interface.
• Authorization. Authorization is the process of allowing an authenticated identity to choose a username. Default authorization will authorize an authenticated username to the same username only. Custom authorization implementations can be created by extending the {@link org.jivesoftware.openfire.auth.AuthorizationPolicy} interface.
• Authorization Mapping. Mapping occurs when the client did not request any specific username. This provides a method of giving a default username in these situations. Custom authorization mappings can be created by extending the {@link org.jivesoftware.openfire.auth.AuthorizationMapping} interface.

Ad-Hoc Commands implementation (JEP-0050).

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).

Service discovery implementation (JEP-0030).

Implementation of Entity Capabilities (XEP-0115).

Event system.

Implementation of SOCKS5 Bytestreams (JEP-0065).

Data forms implementation (JEP-0004).

Groups, which are used to organize users together.

IQ class implementations.

Laucher classes for Openfire.

LDAP code for authentication and user profile information.

Implementation of Multi-User Chat (JEP-0045).

Implementation of Multi-User Chat (JEP-0045).

Connection Manager implementation. Connection Managers architecture is composed of two parties.

• Connection Managers that accept client connections. Not implemented here.
• The Main server that handles Connection Manager connections. Implemented here.

Implementation of Personal Eventing via Pubsub (XEP-0163).

Implementation of Blocking Communication.

Implementation of Publish-Subscribe (JEP-0060).

Defines policies that define who is allowed to subscribe and retrieve items or policies that define who is allowed to publish items to nodes. (JEP-0060).

Classes used for server-to-server communication.

Classes that provide the "check for update" service or the "get available plugins" service.

Provides the interfaces and classes necessary to create custom user account data providers for Openfire.

User accounts are handled separately from authentication. The three primary interfaces to implement are the UserIDProvider, UserAccountProvider, and UserInfoProvider. An overview of how these providers should be implemented and how they interact is described in the User Account Provider Guide included in the Openfire distribution.

There are several Roster (a.k.a. Buddy List) related classes in the user package. Developers are strongly discouraged from implementing custom RosterProvider classes. Roster provider implementation is complicated and should be left to the Jive JDBC implementation if at all possible. There are no disadvantages in implementing user account data with custom providers to integrate Openfire with a CRM or ERP user system, while leaving roster storage in Jive's standard JDBC database tables. (Note: Openfire comes with JDBC and LDAP user account providers 'out of the box'. It is expected that LDAP will accomodate many enterprise integration needs).

Utility classes.