1.2. Basic Components of Plug-ins in JBoss ON
There are some common elements that comprise plug-ins in JBoss ON. Each of these elements is described in more detail in the server-side and agent plug-in sections, but this sections provides some more general context on these elements and compares some differences in the way that server-side and agent plug-ins use these elements.
1.2.1. Plug-in Containers
All JBoss ON plug-ins run inside a plug-in container. This container is responsible for loading, starting, and stopping all plug-ins. Neither the agent nor the server interacts directly with plug-ins; rather, the agent and server both host plug-in containers. The agent or server talks to the plug-in container, and the plug-in container talks to the plug-ins.
For an agent plug-in, there is nothing relevant about the plug-in container; all agent plug-ins use the same one. The container is essentially invisible to plug-in writers.
Server-side plug-ins, however ,have a very different relationship with the plug-in containers. The server runs multiple plug-in containers, each one designated for a specific subsystem or purpose. The plug-in container, itself, provides some configuration for server-side plug-ins by providing additional schema definitions and certain kinds of functionality. The plug-in container is the first identifying category for a server-side plug-in by distinguishing the type of server-side plug-in.
The plug-in container, along with controlling the relationship between the agent or server and the plug-in, also moderates the relationship between plug-ins and their classes. The plug-in container manages plug-in dependencies (for agent plug-ins), shared classes, and external libraries required by the plug-in.
1.2.2. Plug-in Descriptor
The plug-in descriptor is the file which defines what a specific plug-in does. This file loads the required API classes that allow the plug-in to interact with its plug-in container and, by extension, the server or agent. It defines the specific configuration for the plug-in instance, sets schedules or operations, and explicitly defines the intended functionality for the plug-in.
The plug-in descriptor is always an XML file. Both agent and server-side plug-ins require that the plug-in descriptor be placed in a
META-INF/ directory in the JAR file of the plug-in. For server-side plug-ins, this file must be named rhq-serverplugin.xml, and for agent plug-ins, rhq-plugin.xml.
1.2.3. Plug-in Schema Definitions
Since the plug-in descriptor is an XML file, there must be a schema definition to use to configure elements and attributes within the file. All of the plug-ins in JBoss ON use a core schema defined with the agent plug-ins,
rhq-configuration.xsd. Server-side plug-ins extend that schema with an additional schema definition file, rhq-serverplugin.xsd, and then custom schema definitions for each server-side plug-in type.
1.2.4. Java Files
The actual code for the plug-in is contained in Java files within the plug-in JAR package.
Agent plug-ins usually have at least two and sometimes several Java files for each plug-in. There are several reasons for this:
- Agent plug-ins can define both parent and children elements (platforms, servers, and services) in the same plug-in, and each resource type uses its own plug-in code.
- Agent plug-ins have two and sometimes three discrete functions. Almost every agent plug-in must have a discovery component (discovery Java file) that dictates how to identify and inventory whatever resource type is defined by the plug-in. Additionally, agent plug-ins may enable event collection for resources, which requires a separate component (event poller Java file) to track the resource logs. Last, there has to be a component (Java file) which actually implements the plug-in functionality.
- Agent plug-ins allow dependencies. Parent plug-ins can share classes with their children. An agent plug-in can set a dependency on any other agent plug-in that allows it to load that plug-ins classes. To make plug-ins perform better and to make it easier to access the relevant plug-in code, agent plug-ins are frequently broken into smaller Java files to allow the plug-in code to be reused.
Server-side plug-ins usually have only a single Java file to define the plug-in behavior. Since server-side plug-ins do not have dependencies with each other and do not interact with other subsystems (like discovery and event monitoring) everything related to the plug-in can be defined in a single file.
1.2.5. External Libraries
Any library or class that a plug-in requires that is not contained within its own Java files is an external library.
Agent plug-ins can interact through dependencies and shared classes. External libraries or classes for an agent plug-in refer to libraries or classes defined in another agent plug-in. This is one reason that it is so common for agent plug-ins to require JMX plug-in dependency, because it makes all of the JMX and EMS libraries in that plug-in available to the other agent plug-in. Agent plug-ins can also share their classes with a child plug-in, which both simplifies library management (by making the same library available to multiple plug-ins at once) and simplifies plug-in writing.
Server plug-ins do not interact with one another, so it is not possible to establish dependencies or share classes between server-side plug-ins, even in the same plug-in container. However, server-side plug-ins do allow external libraries to be packaged in the plug-in JAR file and can access any library in the
lib/ directory within the JAR file.
