JBoss.org Community Documentation

4.3. Via JBoss Microcontainer (JBoss AS 5.x)

Beginning with AS 5, JBoss AS also supports deployment of POJO services via deployment of a file whose name ends with -beans.xml . A POJO service is one whose implementation is via a "Plain Old Java Object", meaning a simple java bean that isn't required to implement any special interfaces or extend any particular superclass. A Cache is a POJO service, and all the components in a Configuration are also POJOS, so deploying a cache in this way is a natural step.

Deployment of the cache is done using the JBoss Microcontainer that forms the core of JBoss AS. JBoss Microcontainer is a sophisticated IOC framework (similar to Spring). A -beans.xml file is basically a descriptor that tells the IOC framework how to assemble the various beans that make up a POJO service.

For each configurable option exposed by the Configuration components, a getter/setter must be defined in the configuration class. This is required so that JBoss Microcontainer can, in typical IOC way, call these methods when the corresponding properties have been configured.

The rules for how to deploy the file, how to package it, how to ensure the required jars are on the classpath, etc. are the same as for a JMX-based deployment .

Following is an example -beans.xml file. If you look in the server/all/deploy directory of an AS 5 installation, you can find several more examples.

<?xml version="1.0" encoding="UTF-8"?>
	      
	      <deployment xmlns="urn:jboss:bean-deployer:2.0">
	      
	      <!-- First we create a Configuration object for the cache -->
	      <bean name="ExampleCacheConfig"
	      class="org.jboss.cache.config.Configuration">
	      
	      <!-- Externally injected services -->  
	      <property name="runtimeConfig">
	      <bean name="ExampleCacheRuntimeConfig" class="org.jboss.cache.config.RuntimeConfig">
	      <property name="transactionManager">
	      <inject bean="jboss:service=TransactionManager" 
	      property="TransactionManager"/>
	      </property>
	      <property name="muxChannelFactory"><inject bean="JChannelFactory"/></property>
	      </bean>
	      </property>
	      
	      <property name="multiplexerStack">udp</property>
	      
	      <property name="clusterName">Example-EntityCache</property>
	      
	      <!--
	      Node locking level : SERIALIZABLE
	      REPEATABLE_READ (default)
	      READ_COMMITTED
	      READ_UNCOMMITTED
	      NONE
	      -->
	      <property name="isolationLevel">REPEATABLE_READ</property>
	      
	      <!--     Valid modes are LOCAL
	      REPL_ASYNC
	      REPL_SYNC
	      -->
	      <property name="cacheMode">REPL_SYNC</property>
	      
	      <!--  The max amount of time (in milliseconds) we wait until the
	      initial state (ie. the contents of the cache) are retrieved from
	      existing members in a clustered environment
	      -->
	      <property name="initialStateRetrievalTimeout">15000</property>
	      
	      <!--    Number of milliseconds to wait until all responses for a
	      synchronous call have been received.
	      -->
	      <property name="syncReplTimeout">20000</property>
	      
	      <!--  Max number of milliseconds to wait for a lock acquisition -->
	      <property name="lockAcquisitionTimeout">15000</property>
	      
	      <property name="exposeManagementStatistics">true</property>
	      
	      <!-- Must be true if any entity deployment uses a scoped classloader -->
	      <property name="useRegionBasedMarshalling">true</property>
	      <!-- Must match the value of "useRegionBasedMarshalling" -->
	      <property name="inactiveOnStartup">true</property>
	      
	      <!--  Specific eviction policy configurations. This is LRU -->
	      <property name="evictionConfig">
	      <bean name="ExampleEvictionConfig" 
	      class="org.jboss.cache.config.EvictionConfig">
	      <property name="defaultEvictionPolicyClass">
	      org.jboss.cache.eviction.LRUPolicy
	      </property>
	      <property name="wakeupIntervalSeconds">5</property>
	      <property name="evictionRegionConfigs">
	      <list>
	      <bean name="ExampleDefaultEvictionRegionConfig" 
	      class="org.jboss.cache.config.EvictionRegionConfig">
	      <property name="regionName">/_default_</property>
	      <property name="evictionPolicyConfig">
	      <bean name="ExampleDefaultLRUConfig" 
	      class="org.jboss.cache.eviction.LRUConfiguration">
	      <property name="maxNodes">5000</property>
	      <property name="timeToLiveSeconds">1000</property>
	      </bean>
	      </property>
	      </bean>
	      </list>
	      </property>
	      </bean>
	      </property>
	      
	      </bean>
	      
	      <!-- Factory to build the Cache. -->
	      <bean name="DefaultCacheFactory" class="org.jboss.cache.DefaultCacheFactory">      
	      <constructor factoryClass="org.jboss.cache.DefaultCacheFactory" 
	      factoryMethod="getInstance"/>
	      </bean>
	      
	      <!-- The cache itself -->
	      <bean name="ExampleCache" class="org.jboss.cache.Cache">
	      
	      <constructor factoryMethod="createCache">
	      <factory bean="DefaultCacheFactory"/>
	      <parameter class="org.jboss.cache.config.Configuration"><inject bean="ExampleCacheConfig"/></parameter>
	      <parameter class="boolean">false</false>
	      </constructor>
	      
	      </bean>
	      
</deployment>

See the JBoss Microcontainer documentation [2] for details on the above syntax. Basically, each bean element represents an object; most going to create a Configuration and its constituent parts .

An interesting thing to note in the above example is the use of the RuntimeConfig object. External resources like a TransactionManager and a JGroups ChannelFactory that are visible to the microcontainer are dependency injected into the RuntimeConfig . The assumption here is that in some other deployment descriptor in the AS, the referenced beans have been described.



[2] http://labs.jboss.com/jbossmc/docs