Using the Jakarta Management APIs

1 Using the Jakarta Management APIs

Use the Jakarta Management APIs to create a single Java program that can discover, browse, create, and delete resources on any Jakarta EE application server. Examples of Java program resources are JDBC connection pools and deployed applications.

The Jakarta Management APIs are part of the Jakarta Management Specification, which requires all Jakarta EE application servers to describe their resources in a standard data model. The Jakarta Management Specification describes a standard data model for monitoring and managing the runtime state of any Jakarta EE application server and its resources. It includes standard mappings of the model through a Jakarta Management Enterprise Bean component (MEJB).

The chapter includes the following sections that describe how to use the Jakarta Management APIs on WebLogic Server:

Understanding the Jakarta EE Management Model and APIs

The Jakarta EE Management data model defines a set of managed objects that must be provided by the Jakarta EE platform using defined Management EJB interfaces. In the Jakarta EE Management data model, each instance of a web application server resource type is represented by a Jakarta Managed Object (JMO).

The Jakarta Management Specification describes exactly which types of resources must be represented by a JMO. JMOs themselves contain only a limited set of attributes, which are used to describe the location of the object in the data model.

Download the Jakarta Management Specification from https://jakarta.ee/specifications/management/.

JMO Hierarchy
The data model organizes JMOs hierarchically in a tree structure.
JMO Object Names
Each JMO instance is identified by a unique object name of type javax.management.ObjectName.
Optional Features of JMOs
The Jakarta Management Specification requires only that Web application servers implement JMOs and provide API access to the JMOs. Optionally, you can implement the JMOs to provide performance statistics, management operations, and to emit notifications when specified events occur.
Accessing JMOs
A Java application accesses the JMOs through javax.management.j2ee.Management, which is the remote interface for the Jakarta Management Enterprise Bean (MEJB).

Parent topic: Using the Jakarta Management APIs

JMO Hierarchy

The data model organizes JMOs hierarchically in a tree structure.

The root JMO is J2EEDomain, which represents a collection of Web application server instances that are logically related. J2EEDomain contains the object names for all instances of the J2EEServer JMO, each of which represents a server instance in the collection.

Java applications can browse the hierarchy of JMOs, recursively querying for object names and looking up the JMOs that are named by the query results.

Parent topic: Understanding the Jakarta EE Management Model and APIs

JMO Object Names

Each JMO instance is identified by a unique object name of type javax.management.ObjectName.

The names follow this pattern:

domain:name=j2eeType=value,name=value,parent-j2eeType[,property=value]*

For example, mydomain:J2EEtype=J2EEDomain,name=mydomain

The Jakarta Management Specification describes exactly which name/value pairs must be in the object names for each JMO type.

The object name for each child JMO contains name/value pairs from its parent JMO's object name. For example, if the JMO for a server instance is named

mydomain:j2eeType=J2EEServer,name=myserver

then the JMO for a servlet that is part of an application deployed on that server instance would be named:

mydomain:J2EEApplication=myapplication,J2EEServer=myserver,WebModule=myapp_mywebmodule,j2eeType=Servlet,name=myservlet_name

The name/value pairs can appear in any order.

Parent topic: Understanding the Jakarta EE Management Model and APIs

Optional Features of JMOs

The Jakarta Management Specification requires only that Web application servers implement JMOs and provide API access to the JMOs. Optionally, you can implement the JMOs to provide performance statistics, management operations, and to emit notifications when specified events occur.

Parent topic: Understanding the Jakarta EE Management Model and APIs

Accessing JMOs

A Java application accesses the JMOs through javax.management.j2ee.Management, which is the remote interface for the Jakarta Management Enterprise Bean (MEJB).

The Jakarta Management Specification requires that the MEJB's home interface be registered in a server's JNIDI tree as ejb.mgmt.MEJB.

See the API Reference for the javax.management.j2ee package: https://jakarta.ee/specifications/management/1.1/apidocs/javax/management/j2ee/package-summary.

Parent topic: Understanding the Jakarta EE Management Model and APIs

The Jakarta Management Model on WebLogic Server

WebLogic Server implements only the required features of the Jakarta Management Specification, version 1.1. Therefore, the following limitations are in place:

None of the JMOs provide performance statistics, management operations, or emit notifications.
There are no mappings to the Common Information Model (CIM).
There are no mappings to an SNMP Management Information Base (MIB).

The MEJB and JMOs are available only on the Administration Server. This is consistent with the Jakarta Management Model, which assumes that most Jakarta EE application servers exist within some logically connected collection and that there is a central point within the collection for accessing or managing the server instances. From the Administration Server, a Java application can browse to the JMO that represents any resource on any server instance in the WebLogic Server domain.

Because WebLogic Server implements its JMOs as a wrapper for its MBeans, any changes in a WebLogic Server MBean that corresponds to a JMO is immediately available through the Jakarta Management APIs.

For all JMO object names on WebLogic Server, the domain: portion of the object name corresponds to the name of the WebLogic Server domain.

Parent topic: Using the Jakarta Management APIs

Accessing the MEJB on WebLogic Server

You can access the MEJB interfaces on Oracle WebLogic Server. Use the MEJB component to query and retrieve the WebLogic monitoring data.

To retrieve monitoring data through the MEJB:

Look up the javax.management.j2ee.ManagementHome interface through the Administration Server JNDI tree under the name ejb.mgmt.MEJB.
Use ManagementHome to construct an instance of javax.management.j2ee.Management, which is the MEJB's remote interface.

Example: Querying Names of JMOs

Parent topic: Using the Jakarta Management APIs

Example: Querying Names of JMOs

Use the javax.management.j2ee.Management.queryNames method to query the names of JMOs in a WebLogic domain.

The example class in Example 1-1 accesses the MEJB for a WebLogic Server domain and invokes javax.management.j2ee.Management.queryNames method. This method returns the object name for all JMOs in the domain.

Example 1-1 Querying Names of JMOs

import java.io.IOException;
import java.net.MalformedURLException;
import java.util.Iterator;
import java.util.Set;
import java.util.Properties;
import javax.management.j2ee.Management;
import javax.management.j2ee.ManagementHome;
import javax.management.AttributeNotFoundException;
import javax.management.InstanceNotFoundException;
import javax.management.ObjectName;
import javax.management.QueryExp;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.ejb.CreateException;
public class GetJMONames { 
   static String url = "t3://localhost:7001";
   static String user = "weblogic";
   static String password = "weblogic";
   public static void main(String[] args) {
      try {
         getAllJMONames();
      }catch(Exception e){
      System.out.println(e);
      }
   }
   public static Management getMEJBRemote()
       throws IOException, MalformedURLException,
       NamingException,CreateException
   {
      Context context = getInitialContext();
      ManagementHome home = (ManagementHome)
          context.lookup("ejb.mgmt.MEJB");
      Management bean = home.create();
      return bean;
   }
   public static Context getInitialContext()
          throws NamingException
   {
      Properties p = new Properties();
      p.put(Context.INITIAL_CONTEXT_FACTORY,
          "weblogic.jndi.WLInitialContextFactory");
      p.put(Context.PROVIDER_URL, url);
      if (user != null) {
         p.put(Context.SECURITY_PRINCIPAL, user);
         if (password == null)
            password = "";
            p.put(Context.SECURITY_CREDENTIALS, password);
         }
      return new InitialContext(p);
   }
   public static void getAllJMONames()
   {
      try {
         Management rhome = getMEJBRemote();
         String string = "";
         ObjectName name = new ObjectName(string);
         QueryExp query = null;
         Set allNames = rhome.queryNames(name, query);
         Iterator nameIterator = allNames.iterator();
         while(nameIterator.hasNext()) {
            ObjectName on = (ObjectName)nameIterator.next();
            System.out.println(on.getCanonicalName() + "\n");
         }
      } catch (Exception ex) {
            ex.printStackTrace();
      }
   }
}

Parent topic: Accessing the MEJB on WebLogic Server

WebLogic Server Extensions

WebLogic Server implements an extension to Jakarta Management Specification that gives you access to WebLogic-specific deployment descriptors using the MEJB, just like the standard Jakarta EE deployment descriptors. The productSpecificDeploymentDescriptor attribute returns the XML contents of the WebLogic-specific descriptor file. Example 1-2 illustrates calling the method.

Example 1-2 productSpecificDeploymentDescriptor

// Get the WLS specific deployment descriptor. 
// This is similar to the call for the standard descriptor 
// (i.e., the "deploymentDescriptor" attribute)
// 
dd = (String) managementBean.getAttribute(objName, "productSpecificDeploymentDescriptor");

// It returns a string containing the contents of the WLS specific deployment 
// descriptor. This is the XML file contents as a string.

Parent topic: Using the Jakarta Management APIs