Ok, I have been through the container configuration setup logic in some detail
and this is there seems to be a discrepency between what I am seeing and
the suggested ability to have a custom container config pick up the corresponding
standard config elements. The net result of the review is:
1. If you define a container-name in jboss.xml that DOES NOT correspond to
a name that exist in the standardjboss.xml file you are defining a custom config
that must be completely specified as it will pickup no config info from
standardjboss.xml.
2. If you define a container-name in jboss.xml that DOES correspond to
a name that exist in the standardjboss.xml file you are extending the standard
config and you can use a partial definition to selectively override the standard
config.
3. If there is no jboss.xml or no container-configuration info, any EJBs defined
in the ejb-jar.xml file will pickup the standard config based on the type of bean
and the JDK version.
+++ Code review notes:
1. The standardjboss.xml file is loaded by the org.jboss.metadata.XmlFileLoader.load()
method(line 109). This creates ConfigurationMetaData objects for everything in
the standardjboss.xml file and this should correspond to these constants defined
in ConfigurationMetaData:
// Constants -----------------------------------------------------
public static final String CMP_13 = "Standard CMP EntityBean";
public static final String BMP_13 = "Standard BMP EntityBean";
public static final String STATELESS_13 = "Standard Stateless SessionBean";
public static final String STATEFUL_13 = "Standard Stateful SessionBean";
public static final String MESSAGE_DRIVEN_13 = "Standard Message Driven Bean";
public static final String CMP_12 = "jdk1.2.2 CMP EntityBean";
public static final String BMP_12 = "jdk1.2.2 BMP EntityBean";
public static final String STATELESS_12 = "jdk1.2.2 Stateless SessionBean";
public static final String STATEFUL_12 = "jdk1.2.2 Stateful SessionBean";
public static final String MESSAGE_DRIVEN_12 = "jdk1.2.2 Message Driven Bean";
This is done by the ApplicationMetaData.importJbossXml(Element) method.
The key code here is:
String confName = getElementContent(getUniqueChild(conf, "container-name"));
// find the configuration if it has already been defined
// (allow jboss.xml to modify a standard conf)
ConfigurationMetaData configurationMetaData = getConfigurationMetaDataByName(confName);
// create it if necessary
if (configurationMetaData == null) {
configurationMetaData = new ConfigurationMetaData(confName);
configurations.put(confName, configurationMetaData);
}
try {
configurationMetaData.importJbossXml(conf);
} catch (DeploymentException e) {
throw new DeploymentException("Error in jboss.xml for
container-configuration " + configurationMetaData.getName() + ": " +
e.getMessage());
}
2. A META-INF/jboss.xml file is loaded if it exits. This occurs at line 120 of
XmlFileLoader.
This also invokes ApplicationMetaData.importJbossXml(Element) with the jboss.xml
root element as so the code from above is executed. The only way a
container-configuration
specified in the jboss.xml file is going to inherit information from the
standardjboss.xml file
is if the container-name elements are the same.
3. The ApplicationMetaData.importJbossXml(Element) method also handles the
enterprise-beans
tags from the jboss.xml file. For each type of bean a BeanMetaData object is created
and
its importJbossXml(Element) is called. A BeanMetaData is the only config object that
knows enough that it could get the 'default config info for a xxx bean'.
However, its importJbossXml(Element) method is only concerned that a configuration
exists if a configuration-name element was specified. This method does the following:
// set the configuration (optional)
configurationName = getElementContent(getOptionalChild(element, "configuration-name"));
if (configurationName != null &&
getApplicationMetaData().getConfigurationMetaDataByName(configurationName) == null) {
throw new DeploymentException("configuration '" + configurationName + "' not found
in standardjboss.xml or jboss.xml");
}
4. The ContainerFactory is where the ConfigurationMetaData is actually used. It is
obtained via the BeanMetaData object as follows:
// Load XML
ApplicationMetaData metaData = efm.load();
...
// Get list of beans for which we will create containers
Iterator beans = metaData.getEnterpriseBeans();
while(beans.hasNext())
{
BeanMetaData bean = (BeanMetaData)beans.next();
...
// get the container configuration for this bean
// a default configuration is now always provided
ConfigurationMetaData conf = bean.getContainerConfiguration();
...
}
Now, the BeanMetaData.getContainerConfiguration() simply obtains the configuration
object corresponding to the BeanMetaData configurationName from the ApplicationMetaData
object:
public String getConfigurationName() {
if (configurationName == null) {
configurationName = getDefaultConfigurationName();
}
return configurationName;
}
public ConfigurationMetaData getContainerConfiguration() {
if (configuration == null) {
configuration = application.getConfigurationMetaDataByName(getConfigurationName());
}
return configuration;
}
The getDefaultConfigurationName() method is abstract and overriden by the
various container types to return one of the ConfigurationMetaData contstants.
The BeanMetaData class does not try to merge a non-standard configuration
with the standard configuration according to the bean type.
