WildFly ee Subsystem Configuration

Internal

• WildFly ee Subsystem

Relevance

• EAP 6.4

Overview

<subsystem xmlns="urn:jboss:domain:ee:1.2">
  <spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
  <jboss-descriptor-property-replacement>true</jboss-descriptor-property-replacement>
  <annotation-property-replacement>false</annotation-property-replacement>
</subsystem>

Configuration

spec-descriptor-property-replacement

"spec-descriptor-property-replacement" configures JEE descriptor property replacement. JEE descriptor property replacement substitutes properties found in standard JEE descriptors with current values from runtime. JEE descriptor property replacement is disabled by default. When enabled, system properties will be replaced in the following descriptors: ejb-jar.xml and persistence.xml.

jboss-descriptor-property-replacement

"jboss-descriptor-property-replacement" configures JBoss-specific descriptor property replacement. JBoss-specific descriptor property replacement substitutes properties found in JBoss descriptors with current values from runtime. JBoss-specific descriptor property replacement is enabled by default, and includes the following descriptors:

• jboss-ejb3.xml
• jboss-app.xml
• jboss-web.xml
• *-jms.xml
• *-ds.xml

annotation-property-replacement

"spec-descriptor-property-replacement" configures annotation property replacement. Annotation property replacement substitutes properties found in annotations with current values from runtime. Annotation property replacement is disabled by default. When enabled, it works with:

• @ResourceAdapter("${some.property.that.must.be.defined.externally:default-value}")
• @Resource(name="${some.property.that.must.be.defined.externally:default-value}")

ear-subdeployments-isolated

As described in the WildFly Module - EAR Deployments section, the default behavior of the application server is to isolate EAR sub-deployments, so classes from a sub-deployment do not have by default access to classes from other sub-deployment. This behavior can be configured via ear-subdeployments-isolated setting of the ee subsystem. By default, in EAP 6 the value is implicitly true: the JEE modules are isolated, they do not have visibility into each other. In EAP 7, the default is false: the JEE modules can see each other's types.

This behavior can be changed as follows:

<subsystem xmlns="urn:jboss:domain:ee:1.0" >            
  <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
</subsystem>

The ear-subdeployments-isolated element value has no effect on the isolated classloader of the WAR file(s). i.e. irrespective of whether this flag is set to true or false, the WAR within a EAR will have an isolated classloader and other sub-deployments within that EAR will not be able to access classes from that WAR. JEE specifications mandate this behavior.

If the ear-subdeployments-isolated is set to true then no automatic module dependencies between the sub-deployments are set up. User must manually setup the dependency with Class-Path: entries, or by setting up explicit module dependencies. The Java EE specification says that portable applications should not rely on sub deployments having access to other sub deployments unless an explicit Class-Path: entry is set in the MANIFEST.MF. So portable applications should always use Class-Path: entry to explicitly state their dependencies.

The global ear-subdeployments-isolated setting can overridden in the jboss-deployment-structure.xml deployment descriptor.

Global Module

It is possible to set up global modules that are accessible to all JEE deployments:

<subsystem xmlns="urn:jboss:domain:ee:1.2">           
  <global-modules>
    <module name="io.novaordis.playground.wildfly.custommodule" slot="1.0" />            
  </global-modules> 
</subsystem>