11.4. Applications

JBoss Enterprise Application Platform 5 is a fully-compliant implementation of the Java Enterprise Edition 5 (Java EE 5) Platform Specification. Java EE 5 defines the metadata associations of the Java language which can be used to annotate application code and eliminate the need for deployment descriptors wherever possible. Default behavior is also defined with the ability to override as needed. This is known as configuration by exception.
Portable Java EE applications running on Enterprise Application Platform 4.x can be deployed to Enterprise Application Platform 5 without any changes. However, runtime-specific deployment information may be required when migrating from another vendor's application server to JBoss Enterprise Application Platform 5.
Enterprise Application Platform 5 users can take advantage of the simplified packaging and deployment rules defined in the Java EE 5 Platform Specification, such as no longer requiring an application.xml file in Enterprise Archives (EARs). Additionally, a default library directory (lib) in the root directory of an EAR makes the JARs available to all components packaged within the EAR. If an application.xml file is included, the library-directory element can be used to specify the location of the lib directory.
Enterprise Application Platform 5 also introduces a new deployable unit: the MCBeans archive, after JBoss Microcontainer, which typically takes the .beans or .deployer suffix. MCBeans archives package a POJO deployment in a JAR file with a META-INF/jboss-beans.xml descriptor. This format is common in Enterprise Application Platform deployers.
Application verification for all file types is enabled by default, and can be configured in the deployers/ear-deployer-jboss-beans.xml file, specifically: 
<!-- uncomment to disable xml validation
   <property name="useValidation">false</property -->
<!-- in case xml validation is disabled, it's also better to turn off schema validation
   <property name="useSchemaValidation">false</property -->
Enterprise JavaBean 2.0 archive verification remains the same between Enterprise Application Platform 4.x and Enterprise Application Platform 5. However, the properties that control verification have been moved from deploy/ejb-deployer.xml to deployers/ejb-deployer-jboss-beans.xml.
If an enterprise archive contains only an application client and refers to EJBs, you must also add the </ignore-dependency> element to the ejb-ref or ejb-local-ref definitions in the jboss-client.xml deployment descriptor. This informs the deployer to deploy the archive without resolving the referenced dependencies.

11.4.1. Classloading

The new ClassLoader is fully backwards compatible, with one exception that does not affect common use ( http://www.jboss.org/community/docs/DOC-12840 ). All classloading configurations from EAP 4.x will still work with the new implementation, and most default settings retain the behavior of the previous version.
The new ClassLoader shares many design and implementation details with the original UnifiedClassLoader, but makes the following improvements:
  • the classloader no longer depends upon JMX, so it can be used in any environment as a standalone.
  • it is much easier to implement your own classloader policy.
  • increased control over which classloaders your classloader delegates to.
  • increased control over which classes are visible to other classloaders.
  • hierarchical repositories have been replaced by domains, and can now extend beyond a single level.

Note

useJBossWebClassLoader="true" is not used in JBoss Enterprise Application Platform 5. All WAR classloaders in Enterprise Application Platform 5 are JBoss ClassLoader s, so the WarDeployer no longer handles the configuration details for web applications.
There are several methods available to change the classloading configuration of a WAR:
Remove the WarClassLoaderDeployer
The WarClassLoaderDeployer automatically implements the defined classloading rules for WARs. Each WAR is assigned a scoped classloading domain. Its classes are not visible to other applications or to any parent EAR, and where possible the WAR's classes are called first. To remove this behavior and make WAR classloading behave like other deployers, comment out the WarClassLoaderDeployer in deployers/jbossweb.deploy/META-INF/war-deployers-jboss-beans.xml.
Define classloading rules explicitly for the WAR
Add a WEB-INF/jboss-classloading.xml with the following content to your WAR. 
<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
   name="mywar.war"
   domain="DefaultDomain"
   export-all="NON_EMPTY"
   import-all="true">
</classloading>
This lets you define how the WAR's classloader is constructed. In this case, the WAR's classloader has been placed in the DefaultDomain, which is shared with all other applications that do not define their own domain. import-all is enabled, which means the classloader will look at all other classes exported by other applications. export-all is set to expose all classes in our application to other classes.