Elements of the Deployment Descriptor Files

This page is a reference for extra elements added to the GlassFish proprietary deployment descriptors


With this option its possible to enable/disable class loading delegation. This allows deployed application to use libraries included on them, overriding the versions included on the server.

For more information about how class delegation can be configured on Payara Server, see the Enhanced Class loading section.


Used to whitelist packages on extreme class loading isolation. Whitelisted packages are taken into account by the server when scanning libraries.

For more information about how extreme class loading isolation works on Payara Server, see the Enhanced Classloading section.


In a WAR file, it is possible to set the property bean-discovery-mode equal to none to turn off implicit scanning of the archive for bean defining annotations, as defined by the CDI 1.1 specification. The default value of this setting is defined as annotated in the specification, so the archive is scanned for any bean-defining annotations, which can cause unwanted side effects.

In the glassfish-application.xml deployment descriptor for an EAR file, the property enable-implicit-cdi can be set to false to achieve the same goal for all modules inside the EAR assembly. The default value is true, in line with the default value for WAR files.

If implicit CDI scanning causes problems for an EAR assembly, the value false will disable implicit CDI scanning for all CDI modules inside the EAR assembly:


The default behavior of the admin console is for the Implicit CDI checkbox to be enabled, but this will not override the application configuration.

When implicit CDI is configured by using either the enable-implicit-cdi property in the glassfish-application.xml or the attribute bean-discovery-mode="none" from the beans.xml file in a WAR, the admin console checkbox *is always ignored*.

scanning-exclude and scanning-include

Modern WAR and EAR files very often include a number of 3rd party JARs. In situations where some JARs require CDI scanning and others may break if scanned, these can now be explicitly included or excluded from such component scanning.

Both the glassfish-application.xml and the glassfish-web.xml files support the following directives:


In the above example, all JARs will be excluded by default, then all JARs beginning with ejba will be scanned along with the JAR named conflicting-web-library.


This property configures whether to enable or disable the calling of ServletContainerInitializer component classes defined in JAR files bundled inside a WAR assembly.

For performance considerations, you can explicitly disable the servlet container initializer by setting the container-initializer-enabled element to false. This can help solve the deployment of web applications that can suffer from conflicts with a custom bootstrapping process.

The default value for this configuration element is true.


With this property, you can set whether to enable the default group to role mappings for your application’s security settings. This element is set up as a property element with a Boolean value attribute like this:

<property name="default-role-mapping" value="true">
  <description>Enable default group to role mapping</description>

Enabling the default group to role mappings will cause all named groups in the application’s linked security realm to be mapped to a role of the same name. This will save you the time of having to redefine the same roles and map them to the realm groups each time they are modified.

This will have the same effect as executing the following asadmin command:

asadmin set configs.config.server-config.security-service.activate-default-principal-to-role-mapping=true

Except its effect will only limit itself to the application instead of all applications deployed on the server. This setting is configured by default to true on the production-ready-domain

The default value of this property is false. This property can be set in the glassfish-web.xml, glassfish-ejb-jar.xml and glassfish-application.xml deployment descriptors.

In an EAR assembly, only the property set in the glassfish-application.xml will take effect and if set in the glassfish-web.xml and glassfish-ejb-jar.xml, it will be ignored. Setting this configuration property in any of these files will always take precedence over any setting configured on the server.


From version, Payara Server has reimplemented a property of the glassfish-ejb-jar.xml descriptor that was available in GlassFish in versions prior to 4.0.

The bean-pool element allows users to specify controls on a per-EJB basis for pooled stateless EJBs. Payara Server has reintroduced max-wait-time-in-millis to govern what happens when the number of requests for an EJB exceeds the number of beans available in the pool.

A value of -1 disables the property and means that, when the pool is at maximum usage and another request is made, a new EJB instance is created immediately, with no upper bound.

A value of 0 means the server will wait indefinitely for an existing EJB instance to be freed.

A value between 1 and MAX_INTEGER means that the server will wait for the given amount of milliseconds for an EJB to be freed. Only after this max-wait-time-in-millis is exceeded will the server create a new instance of the requested EJB.

For more detail, see the Enhanced EJB configuration section.

results matching ""

    No results matching ""