GlassFish Administration: The real driver ...
By bloggerkedar on Jun 23, 2006
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 [http://blogs.sun.com/roller/page/bloggerkedar?entry=concept_of_a_glassfish_domain].
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 ProfilesIt 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.
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!
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.
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" />
<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" ...">
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 ..."