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.

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.CacheImpl">

      

      <constructor factoryMethod="createCache">

          <factory bean="DefaultCacheFactory"/>

          <parameter><inject bean="ExampleCacheConfig"/></parameter>

          <parameter>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.