WildFly ee Subsystem Configuration: Difference between revisions
Line 18: | Line 18: | ||
=ear-subdeployments-isolated= | =ear-subdeployments-isolated= | ||
As noted above, 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 <tt>ear-subdeployments-isolated</tt> setting of the <tt>ee</tt> subdomain. By default, the value is implicitly <tt>true</tt>. It can be changed as follows: | |||
<pre> | |||
<subsystem xmlns="urn:jboss:domain:ee:1.0" > | |||
<ear-subdeployments-isolated>false</ear-subdeployments-isolated> | |||
</subsystem> | |||
</pre> | |||
The <tt>ear-subdeployments-isolated</tt> element value has no effect on the isolated classloader of the WAR file(s). i.e. irrespective of whether this flag is set to <tt>true</tt> or <tt>false</tt>, 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 <tt>ear-subdeployments-isolated</tt> is set to <tt>true</tt> then no automatic module dependencies between the sub-deployments are set up. User must manually setup the dependency with <tt>Class-Path:</tt> 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 <tt>Class-Path:</tt> entry is set in the <tt>MANIFEST.MF</tt>. So portable applications should always use <tt>Class-Path:</tt> entry to explicitly state their dependencies. | |||
The global <tt>ear-subdeployments-isolated</tt> setting can overridden in the <tt>[[jboss-deployment-structure.xml#Overview|jboss-deployment-structure.xml]]</tt> deployment descriptor. |
Revision as of 23:11, 18 March 2016
Internal
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>
ear-subdeployments-isolated
As noted above, 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 subdomain. By default, the value is implicitly true. It 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.