Spring JMX Configuration with XML Schema-Based Configuration

In a previous blog entry, I demonstrated basic Spring XML configuration to use Spring's JMX support. The configuration style I used in that blog entry is the traditional DTD-based Spring beans configuration. In this blog entry, I'll show the same configuration file, but this time I am using the newer XML Schema-based Spring JMX configuration. Specifically, I will demonstrate use of the "p namespace" and the "util" schema.

The code listing shown next shows the how the Spring XML configuration appears when making use of the XML Schema-supported configuration:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:util="http://www.springframework.org/schema/util"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
                           http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd">

   <bean id="jmxService"
         class="marx.SimpleBean"
         p:action="Spring Action"
         p:behavior="Spring Behavior" />

   <util:map id="exposedMBeans">
     <entry key="dustin:type=marx" value-ref="jmxService" />
   </util:map>

   <bean class="org.springframework.jmx.export.MBeanExporter"
         p:beans-ref="exposedMBeans"
         p:assembler-ref="assembler" />

   <util:list id="manageableInterfaces">
      <value>marx.SimpleBeanIf</value>
   </util:list>

   <bean id="assembler"
         class="org.springframework.jmx.export.assembler.InterfaceBasedMBeanInfoAssembler"
         p:managedInterfaces-ref="manageableInterfaces" />

   <bean id="registry"
         class="org.springframework.remoting.rmi.RmiRegistryFactoryBean"
         p:port="1099" />

   <bean id="serverConnector"
         class="org.springframework.jmx.support.ConnectorServerFactoryBean"
         depends-on="registry"
         p:objectName="connector:name=rmi"
         p:serviceUrl="service:jmx:rmi://localhost/jndi/rmi://localhost:1099/jmxrmi" />

</beans>

I highlighted the significant changes to use Spring's XML Schema-based configuration. The util namespace and p namespace are defined at the top and a schemaLocation is defined for the util namespace.

Note that no schemaLocation is provided for the p namespace because it is handled in the core Spring framework code. This prevents the restriction of the names in the p-namespace so that they can match your given property names. Several of the highlighted examples demonstrate the p-namespace in action (note the p: syntax). Additional details on the p-namespace can be found in the Spring Framework 2.5 Reference under Shortcuts and Other Convenience Options for XML-based Configuration Metadata.

The example above of using Spring's JMX configuration with the XML Schema-based format also demonstrates two uses of the util namespace. In this case, the util:map used for articulating the beans to be exposed as MBeans and the util:list used for specifying the interfaces exposed through JMX for the Spring beans-turned-MBeans are both used instead of special map and list elements within a property.

In short, the Spring XML Schema-based configuration can be more concise and readable than the older DTD-based configuration. While there are things I like about this new format, I have not yet convinced myself that I necessarily like this new format better than the tried and true format. However, as this blog entry shows, it is pretty easy to convert the old format to this new format when desired. Other perspectives regarding the "p namespace" include Matt Raible's and Sergio Bossa's blog entries.

The Spring reference points out that this newer XML Schema-based approach can be less flexible than the older DTD-based approach and that it is advisable not to mix the approaches on a given project due to trouble understanding and maintaining the inconsistent configuration approaches.