Elements of the Deployment Descriptor Files

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.

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 ejb 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:

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:

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.

Since Payara Server 4.1.2.181; 5.181

Payara Server and Micro since versions 4.1.2.181 and 5.181 support @RolesAllowed out of the box to secure JAX-RS resources.

In some cases this may clash with existing code that interprets the same annotation using custom code.

The out-of-the-box support of @RolesAllowed for JAX-RS resources can be switched off by setting the <jaxrs-roles-allowed-enabled> tag in WEB-INF/glassfish-web.xml of a war archive to false. E.g.

Since Payara Server 4.1.2.172

Payara Server has re-implemented 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.

Since Payara Server 4.1.2.173

When declaring a secured Web Service based on an EJB using the glassfish-ejb-jar.xml deployment descriptor, it’s necessary to define the login configuration (authentication method, security realm name, etc.) for each EJB Web Service that is secured inside the assembly. For example, if an application contains 2 EJB web services called EJBWS1 and EJBWS2, and they need to be secured using BASIC authentication against the file security realm, the following configuration would be needed:

Notice that the login-config element is repeated exactly like it is in the 2 EJB definitions. Not only that, but if these Web services are defined using annotations for each EJB component, then the JAX-WS information (Port Component Name, Endpoint Address, etc.) would be duplicated too, which is too cumbersome for cases when there are lots of EJB Web service definitions.

For this scenario, the webservice-default-login-config has been introduced to simplify this configuration. When this element is declared, the login configuration inside it will apply to all of the EJB defined Web Services by default.

The previous example can be simplified like this: