JBoss.org Community Documentation

11.3.1.3. Container configuration information

JBoss externalizes most if not all of the setup of the EJB containers using an XML file that conforms to the jboss_4_0.dtd. The section DTD that relates to container configuration information is shown in Figure 11.4, “The jboss_4_0 DTD elements related to container configuration.”.

The jboss_4_0 DTD elements related to container configuration.

Figure 11.4. The jboss_4_0 DTD elements related to container configuration.


The container-configuration element and its subelements specify container configuration settings for a type of container as given by the container-name element. Each configuration specifies information such as the default invoker type, the container interceptor makeup, instance caches/pools and their sizes, persistence manager, security, and so on. Because this is a large amount of information that requires a detailed understanding of the JBoss container architecture, JBoss ships with a standard configuration for the four types of EJBs. This configuration file is called standardjboss.xml and it is located in the conf directory of any configuration file set that uses EJBs. The following is a sample of container-configuration from standardjboss.xml.

<container-configuration>
					<container-name>Standard CMP 2.x EntityBean</container-name>
					<call-logging>false</call-logging>
					<invoker-proxy-binding-name>entity-rmi-invoker</invoker-proxy-binding-name>
					<sync-on-commit-only>false</sync-on-commit-only>
					<insert-after-ejb-post-create>false</insert-after-ejb-post-create>
					<call-ejb-store-on-clean>true</call-ejb-store-on-clean>
					<container-interceptors>
					<interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor>
					<interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
					<interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
					<interceptor>org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
					<interceptor>org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
					<interceptor metricsEnabled="true">
					org.jboss.ejb.plugins.MetricsInterceptor
					</interceptor>
					<interceptor>org.jboss.ejb.plugins.EntityCreationInterceptor</interceptor>
					<interceptor>org.jboss.ejb.plugins.EntityLockInterceptor</interceptor>
					<interceptor>org.jboss.ejb.plugins.EntityInstanceInterceptor</interceptor>
					<interceptor>org.jboss.ejb.plugins.EntityReentranceInterceptor</interceptor>
					<interceptor>
					org.jboss.resource.connectionmanager.CachedConnectionInterceptor
					</interceptor>
					<interceptor>org.jboss.ejb.plugins.EntitySynchronizationInterceptor</interceptor>
					<interceptor>org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor</interceptor>
					</container-interceptors>
					<instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
					<instance-cache>org.jboss.ejb.plugins.InvalidableEntityInstanceCache</instance-cache>
					<persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
					<locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
					<container-cache-conf>
					<cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
					<cache-policy-conf>
					<min-capacity>50</min-capacity>
					<max-capacity>1000000</max-capacity>
					<overager-period>300</overager-period>
					<max-bean-age>600</max-bean-age>
					<resizer-period>400</resizer-period>
					<max-cache-miss-period>60</max-cache-miss-period>
					<min-cache-miss-period>1</min-cache-miss-period>
					<cache-load-factor>0.75</cache-load-factor>
					</cache-policy-conf>
					</container-cache-conf>
					<container-pool-conf>
					<MaximumSize>100</MaximumSize>
					</container-pool-conf>
					<commit-option>B</commit-option>
					</container-configuration>
				

These two examples demonstrate how extensive the container configuration options are. The container configuration information can be specified at two levels. The first is in the standardjboss.xml file contained in the configuration file set directory. The second is at the EJB JAR level. By placing a jboss.xml file in the EJB JAR META-INF directory, you can specify either overrides for container configurations in the standardjboss.xml file, or entirely new named container configurations. This provides great flexibility in the configuration of containers. As you have seen, all container configuration attributes have been externalized and as such are easily modifiable. Knowledgeable developers can even implement specialized container components, such as instance pools or caches, and easily integrate them with the standard container configurations to optimize behavior for a particular application or environment.

How an EJB deployment chooses its container configuration is based on the explicit or implicit jboss/enterprise-beans/<type>/configuration-name element. The configuration-name element is a link to a container-configurations/container-configuration element in Figure 11.4, “The jboss_4_0 DTD elements related to container configuration.”. It specifies which container configuration to use for the referring EJB. The link is from a configuration-name element to a container-name element.

You are able to specify container configurations per class of EJB by including a container-configuration element in the EJB definition. Typically one does not define completely new container configurations, although this is supported. The typical usage of a jboss.xml level container-configuration is to override one or more aspects of a container-configuration coming from the standardjboss.xml descriptor. This is done by specifying container-configuration that references the name of an existing standardjboss.xml container-configuration/container-name as the value for the container-configuration/extends attribute. The following example shows an example of defining a new Secured Stateless SessionBean configuration that is an extension of the Standard Stateless SessionBean configuration.

<?xml version="1.0"?>
					<jboss>
					<enterprise-beans>
					<session>
					<ejb-name>EchoBean</ejb-name>
					<configuration-name>Secured Stateless SessionBean</configuration-name>
					<!-- ... -->
					</session>
					</enterprise-beans>
					<container-configurations>
					<container-configuration extends="Standard Stateless SessionBean">
					<container-name>Secured Stateless SessionBean</container-name>
					<!-- Override the container security domain -->
					<security-domain>java:/jaas/my-security-domain</security-domain>
					</container-configuration>
					</container-configurations>
					</jboss>
				

If an EJB does not provide a container configuration specification in the deployment unit EJB JAR, the container factory chooses a container configuration from the standardjboss.xml descriptor based on the type of the EJB. So, in reality there is an implicit configuration-name element for every type of EJB, and the mappings from the EJB type to default container configuration name are as follows:

It is not necessary to indicate which container configuration an EJB is using if you want to use the default based on the bean type. It probably provides for a more self-contained descriptor to include the configuration-name element, but this is purely a matter of style.

Now that you know how to specify which container configuration an EJB is using and can define a deployment unit level override, we now will look at the container-configuration child elements in the following sections. A number of the elements specify interface class implementations whose configuration is affected by other elements, so before starting in on the configuration elements you need to understand the org.jboss.metadata.XmlLoadable interface.

The XmlLoadable interface is a simple interface that consists of a single method. The interface definition is:

import org.w3c.dom.Element;
					public interface XmlLoadable
					{
					public void importXml(Element element) throws Exception;
					}
				

Classes implement this interface to allow their configuration to be specified via an XML document fragment. The root element of the document fragment is what would be passed to the importXml method. You will see a few examples of this as the container configuration elements are described in the following sections.