Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Application Management with WebLogic Server for Developers part 6

Custom application management using JMX

  • For the previous five parts of this series please see links at foot of article

    This article is the last in a series on BEA WebLogic Server administration and management for developers.

    The first installment focused on the WebLogic Server administration concepts and terminology, and the graphical tools for packaging an application and setting up and configuring a WebLogic Server domain. The second article looked at the available application deployment, run time management, and the monitoring facilities that did not require knowledge of JMX. The third article discussed the basic concepts and terminology of JMX and the WebLogic Server 8.1 JMX infrastructure, and showed you how to use JMX-specific tools that come with WebLogic Server 8.1. The fourth article focused on the basics of how to write custom Java applications that use JMX to configure, administer, and manage WebLogic Server 8.1-based applications. Last month, we continued our discussion of JMX programming by showing you how to use the notification facilities to create notification listeners, monitors, and timers (see WLDJ, Vol. 2, issues 10–12; Vol. 3, issues 2 and 4).

    This month we'll describe how to expose your own management functionality through JMX and ultimately through the Weblogic Admin Console. We start off by discussing why you might choose to instrument your application with JMX. Then, we discuss the basics of instrumenting your application using standard, dynamic, and model MBeans. Finally, we show you how to expose your MBeans via the WebLogic Console.

    Choosing to Instrument with JMX
    Why would you want to consider instrumenting your application using JMX? If you read the previous articles in this series, you shouldalready know the answer to this question. If not, the answer is simple: application code that is instrumented using JMX allows the application's configuration and runtime information to be monitored and managed just like any other resource in WebLogic Server.

    Last month, we showed you how JMX notification and monitors allow your application to dynamically monitor and track the values of any number of MBeans. Exposing the application information through an MBean makes it easy to correlate your application state with that of other MBeans, such as the WebLogic MBeans that surface statistics about the various servers and application components that make up your production environment.

    Finally, instrumenting your code with JMX allows you to expose the monitoring and management functionality of your application through the WebLogic Admin Console.

    What sort of functionality might you expose through JMX? The answer is any attribute or functionality of your application that you want to be able to manage. For example, an application might use a logging framework that allows logging levels to be changed dynamically at runtime. By instrumenting the logging framework to expose the logging level through JMX, it is now relatively easy to:

    • Change the logging level dynamically through the normal JMX mechanisms.
    • Use JMX notification and monitors to change the logging level whenever certain other conditions on other MBeans are observed.
    • Expose the logging framework configuration and/or runtime information through the WebLogic Console.
    Now that you know what functionality you want to expose, the next decision that you need to make is what type of MBean you want to implement. JMX provides a number of alternatives for implementing MBeans:
    • Standard MBeans
    • Dynamic MBeans
    • Model MBeans
    We will use the same simple example to illustrate these three approaches side by side (the examples are online at www.sys-con.com/weblogic/sourcec.cfm). Our examples use a simple Java class that simulates a logging framework and exposes the current logging level and the number of log records written through an MBean. We include a simple Web application that allows you to write messages to the log (which, in our example, is stdout). These examples demonstrate a simple case where the developer wants to present state and usage information about some portion of their application in a way that the system administrator or operations staff can easily monitor it. Later, we will show you how to expose this functionality through the WebLogic Admin Console.

    JMX Instrumentation Using Standard MBeans
    Implementing a standard MBean is about as simple as it gets. Before you start, the MBean interface class and MBean implementation class names must follow the specified pattern for all standard MBeans: the MBean interface class name must be the same as the MBean implementation class name with the suffix MBean appended. In our example, the MBean implementation class name is wldj.standard.Logger. Therefore, the MBean interface class name is wldj.standard.LoggerMBean. Now you're ready to create your standard MBean.

    First, create an interface class that exposes the JMX attributes and operations through its method definitions. As we discussed in part 3, the attributes are exposed through getter and/or setter methods that conform to the standard JavaBean formats:

    public Bar getFoo();
    public void setFoo(Bar newValue);

    All other methods exposed in the interface that do not follow these conventions are considered JMX operations. Our LoggerMBean interface exposes the following JMX attributes and operations:

    Read-Write Attributes:

    Read-Only Attributes:

    void resetLogWriteStatistics()

    Next, create your MBean implementation class to implement the MBean interface you defined. Remember, your interface only needs to expose the methods that you want JMX applications to be able to manage.

    Finally, you need to include initialization code in your application to create and register your MBean with the MBeanServer. In our example, we used a WebLogic Startup class to create and register the MBean with the MBean server, as shown in the code snippet from the LoggerStartup class (see Listing 1).

    The primary limitation of this approach is that it does not allow you to expose additional descriptive information about the attributes. JMX 1.2 addresses this limitation by providing a standardMBean base class, which you can extend and use to provide that additional information. You will, however, have to wait until the next release of BEA WebLogic Server to take advantage of this feature.

    JMX Instrumentation Using Dynamic MBeans
    Implementing a Dynamic MBean is a little more complex but gives you much more flexibility in that you can actually expose JMX attributes and operations that are defined at runtime rather than at compile time. To implement a Dynamic MBean, your MBean implementation class must implement the DynamicMBean interface, which includes:

    • Providing an MBeanInfo object that details information about the JMX attributes, operations and notifications that are providde by the MBean
    • Implementing the getAttribute() and setAttribute() methods that provide read and write capabilities for the MBean's JMX attributes
    • Implementing the invoke() method that interprets the method and attribute types and performs the desired JMX operation
    • Implementing the NotificationBroadcaster interface if the MBean emits JMX notifications
    • Implementing the MBeanRegistration interface if the MBean needs lifecycle callbacks to create and/or cleanup MBean state.
    In our example, we implement the DynamicMBean interface methods. The implementations are fairly straightforward so we will not go through the details here (see the example code).

    Dynamic MBeans provide the greatest flexibility and allow the use of the entire JMX functionality. As the example demonstrates, it is also a great deal more effort than implementing a standard MBean. How do you retain the flexibility of dynamic MBeans while reducing the complexity? Model MBeans significantly reduce the level of effort needed to implement dynamic MBeans.

    JMX Instrumentation Using Model MBeans
    Model MBeans provide similar capabilities to dynamic MBeans but are significantly easier to implement. The majority of the effort in using model MBeans is in constructing the metadata to describe the attributes, constructors, operations, and notifications that the MBean will expose and how those relate to the application class being instrumented. Many of the benefits of model MBeans come from their ability to adapt preexisting implementation code without modification.

    We chose to put the logic for creating the ModelMBeanInfo object that contains the metadata inside the Logger class itself. We could have just as easily put this in the LoggerStartup class so that the Logger class would have no JMX code whatsoever. In our example, we used the version of the ModelMBeanAttributeInfo class constructor that assumes the JMX attribute being exposed has the standard getter and setter method names on the instrumented class.

    Model MBeans also support changing the names of the attributes and operations by using the Descriptor class to specify different method names on the instrumented class. The descriptor contains a list of name-value pairs. The JMX 1.0 specification defines a set of required and optional descriptor fields. For example, setting the currencyTimeLimit field in the descriptor causes the model MBean implementation class to cache the value of the attribute for the specified period of time. This flexibility is important when acquiring the value involves making a remote invocation or querying a back end system. Since our class was developed from a standard MBean, there was no need to use the descriptor functionality.

    Once the ModelMBeanInfo object is populated, we simply need to create an instance of a ModelMBean using the RequiredModelMBean class, configure it to instrument our Logger class, and register it with the MbeanServer (see Listing 2).

    While the code for creating and populating the ModelMBeanInfo object is more work than creating a standard MBean, it is equivalent to implementing the DynamicMBean.getMBeanInfo() method. For this effort, you get the flexibility of a dynamic MBean without the need to implement the other dispatch methods in the DymanicMBean interface.

    Surfacing the MBean in the WebLogic Admin Console
    The WebLogic Admin Console provides an extensibility mechanism that allows you to add pages to the Console to expose your application's MBeans. The basic steps are:

    1. Implement a Java class that extends the weblogic.management.console.extensibility.Extension class and implements the weblogic.management.console.extensibility.NavTreeExtension interface.
    2. Write a JSP that describes the nodes that you want to add to the Console's navigation tree.
    3. Write a set of JSP pages that implement the pages that appear on the right hand side of the console whenever the user selects the nodes from the navigation tree.
    4. Create a set of Web application deployment descriptors that tell the server that this web application is a console extension.
    5. Package the Web application to the necessary files and deploy the Web application as you would any other Web application.
    When writing the Java class, the most important method to implement is the getNavExtensionFor() method. The argument passed in is an MBean reference that indicates the different nodes in the navigation tree. Your application's response to these calls determines about where the new node will appear in the navigation tree. For example, we want our extension to show up at the domain level so our implementation only returns a URL if the argument is an instance of the DomainMBean:

        public String getNavExtensionFor(Object key) 
            if (key instanceof DomainMBean)
                return "logging_navlink.jsp";
            return null;

    To describe the nodes you want to add, you must write the JSP file whose name matches the value returned from the getNavExtensionFor() method. BEA WebLogic Server 8.1 provides a custom JSP tag library, console_extensions_taglib.tld, that contains the JSP custom tag wl:node that you will need to use to define your Console extension nodes. To create a nested set of nodes, you simply nest the wl:node tags in the JSP. The url parameter to the wl:node tags defines which JSPs are called when the user selects one of your custom nodes in the console. For example, selecting the standard MBean Loggers folder in our example causes the standard_summary.jsp to be invoked to fill in the right hand side of the Console window (see Listing 3).

    When writing the set of Console pages for your application, use the wl:tag JSP custom tag to create a set of tabs similar to the tabbed pages in the other portions of the WebLogic Console. This tag allows you to create up to two levels of tabs. Look at our example to see how to use this functionality. For more information about the custom JSP tags provided to support extending the WebLogic Console, see the online documentation at http://edocs.bea.com/wls/docs81/console_ext/taglib.html.

    Next, you need to write the Web application deployment descriptors. There are three things that you must do in addition to the normal information to describe the web application's contents. First, you need to tell the Console how to find your NavTreeExtension class by defining a context-param in the web.xml deployment descriptor:


    Second, you need to add the taglib definition to the web.xml deployment descriptor:


    Finally, you need to set the CookieName that your Web application uses to be the same as the one used by the WebLogic Admin Console so that your extension will be authenticated when the user logs into the Console. You do this by defining a session-param in the weblogic.xml deployment descriptor (see Listing 4). In the final step, you need to package the Web application and deploy it to your WebLogic Admin server. You will need to copy the console extensions tag library descriptor file $WL_HOME/server/lib/console_extensions_taglib.tld to the WEB-INF directory of your web application.

    While the space available here prohibits us from going into more detail about all of the nuances of creating Console extensions, we hope that the downloadable example will provide a realistic enough example to get you started. For more information on creating console extensions, please refer to the BEA WebLogic Server 8.1 documentation at http://edocs.bea.com/wls/docs81/console_ext/.

    We've reached the end of our series on application management with BEA WebLogic Server 8.1. We hope that we were able to show you the power and flexibility of the WebLogic Server 8.1 management tools and services. The JMX infrastructure built into WebLogic Server not only allows you to create custom management applications to manage WebLogic Server, but also allow you to instrument your applications with JMX and expose this instrumentation through extensions to the WebLogic Console.

  • More Stories By Vadim Rosenberg

    Vadim Rosenberg is the product marketing manager for BEA WebLogic Server. Before joining BEA two years ago, Vadim had spent 13 years in business software engineering, most recently at Compaq Computers (Tandem Division) developing a fault-tolerant and highly scalable J2EE framework.

    More Stories By Robert Patrick

    Robert Patrick is a director of technology in BEA's CTO Office and coauthor of the book Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications.  Robert has spent his career helping customers design, build, and deploy high performance, fault-tolerant, mission-critical distributed systems using BEA Tuxedo and BEA WebLogic Server.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    IoT & Smart Cities Stories
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
    The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
    CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
    DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
    Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
    The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...