GlassFish Administration: The real driver ...

GlassFish Administration


This post pertains to the administrative capabilities of GlassFish

Elements of GlassFish Administration

 Following are the various administrative services provided by the administrative infrastructure. It basically defines the topology of your GlassFish installation.

Domain Management and Startup

The first thing you would do with your GlassFish installation is to create the domain. A domain is the administrative boundary that is defined by a set of credentials and your entry point into the Java EE Runtime. The only way to create a domain is to install the GlassFish server or create the domain using the asadmin command: create-domain.

There are bunch of things that happen when you create the domain. All you wanted to know about domains is here [].

The startup of domain is an invocation of asadmin command called start-domain. The administrative infrastructure provides the launching services for the app server process. At the moment, it is rather convoluted to launch the app server VM and we have received feedback to improve the launching such that the entire server should be able to be launched just by invoking a main class in an existing VM. Nevertheless, the launcher provides services to read the configuration for the server VM and launches it. The sequence is: asadmin script -> asadmin VM -> Launcher VM -> GlassFish VM. The only VM that runs indefinitely is the GlassFish VM.

We have to do some improvements in this regard though. An example is to make a given VM an application server VM. Wait till V3 shows up.

Server Usage Profiles

It is widely known that we have three usage profiles of the server. In simple terms, a profile is a predefined configuration suited to a typical use of server. Since we have worked with application server's configuration for some time now, we know what settings make the best sense for a particular use. I agree that the names that we have chosen for available profiles could be better, but for the time being, these are the names:
  • Developer: Does not support clusters, geared towards single instance deployment.
  • Cluster: Supports clusters and in-memory replication of state.
  • Enterprise: Uses 5 9's of availability out of the box and is secure out-of-the-box.
But it does not stop there. Take a look at: GlassFish Issue Tracker, #2300 . It gives you a way to configure your domain the way you want, out-of-the-box and name its profile the way you want. For example, I am going to work on a profile that gives you the best settings for optimum performance as suggested by our performance team. I can call it something like: specjappserver profile. Then all you do is:

asadmin create-domain --profile specjappserver .... perf-domain

As a user, what do I have to do to enable this to create a domain of profile of my choice? Here is the recipe:

  • Learn XSLT, a great technology indeed.
  • Learn domain.xml's DTD
  • .
  • See the specification for a custom profile and your style sheets are picked up!
I am going to work on update center integration of some of the exciting profiles that make sense.

Configuration Management and Validation

According to many developers, the entire configuration is stored in a file called domain.xml. Well, that's not entirely true. But yes, most significant contribution comes from domain.xml. The management of this and other files in your domain's config folder is undertaken by the infrastructure. At the startup, the domain.xml is read into memory and a DOM graph is created with Schema2Beans being used to generate Classes that look much like Java Beans. These are the configuration beans that maintain the domain.xml. Following are the salient features of this component:

  • The configuration is guaranteed to be kept valid all the time.
  • Every GlassFish component (e.g. ejb-container, web-container etc.) derives its configuration from these objects.
  • The configuration can be changed dynamically and it can also be applied in many cases, at runtime.
  • The code is autogenerated from the DTD. We are using schema2beans library for this purpose.
More on this topic here [].

Use of JMX in CLI and GUI

The entire admin GUI and CLI is based on the JMX MBeans that exist in the backend. As we alluded to earlier, the configuration beans come into picture, they create the Config MBeans that are contacted by all the management tools. These are both the static and dynamic MBeans that define the configuration and monitoring hierarchy that the domain's configuration and runtime is comprised of. Here is an example. Suppose, as a developer/administrator you want to edit a JDBC resource.  The preconfigured JDBC resource is the one that's used by the timer: jdbc/__Timer. Here is how it looks in the GUI:

Well, this is how these screen behaves once the user wants to edit the entries:

  • There is a file called jdbc.xml that GUI loads.
  • A snippet of this file is

    <displayItem name = "jdbcResourceTargets" extends = "ResourceTargets">
        <parameter name = "propertySheet" value = "jdbcResourcesEdit" />
        <parameter name = "target" value = "jdbcResourceTargets" />
    <parameter name="rowObjectName"
        <include item="jdbcResourceEditTabs" />

  • As you can see, there is this MBean named "com.sun.appserv:type=resources,category=config" that this screen will call into.
  • There are also some "MethodNames" that are defined in this xml that actually specify the names of the methods defined in the management interface of the MBean.

A similar thing is done by the admin CLI in a file called CLIDescriptor.xml. Here is what CLI does:

  • Reads a file called CLIDescriptor.xml.
  • Here is a snippet of the JDBC resource related create command in this file:

        <Command name="create-jdbc-resource" classname="com.sun.enterprise.cli.commands.GenericCommand" ...">
            <ValidOption name="target"/>

                <property name="objectname">
                <property name="operation">
                <property name="params">
                <property name="paramtypes">
                <property name="returntype">
                <property name="manpage">
                <property name="command-type">

Thus, you can see that this command is using the same MBean that does the entire work. So, apart from the many niceties that you see in GUI and CLI, the worker bees are the MBeans as shown in the JConsole view below:

More to come in follow-up posts ..."

Administrative Security 


Communications Infrastructure

Dotted Names

Dynamic Reconfiguration

Cool Features 

Source Code Organization 

Administrative Best Practices 


Post a Comment:
Comments are closed for this entry.

Welcome to my blog where mostly my work related thoughts are expressed.


« July 2016