Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -268,17 +268,17 @@ To disable class loading delegation globally, you can set the system property `f
It's possible to disable class loading delegation directly at the application level. This can be done for both WAR and EAR applications.

[[disabling-classloading-delegation-on-webapps]]
For *Web* applications, you can include `<class-loader delegate="false"/>` element in the `payara-web.xml`/`glassfish-web.xml` deployment descriptors.
For *Web* applications, you can include `<class-loader delegate="false"/>` element in the `payara-web.xml` deployment descriptors.

Here's an example:

[source, xml]
----
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app error-url="">
<!DOCTYPE payara-web-app PUBLIC "-//Payara.fish//DTD Payara Server 4 Servlet 3.0//EN" "https://docs.payara.fish/schemas/payara-web-app_4.dtd">
<payara-web-app error-url="">
<class-loader delegate="false"/>
</glassfish-web-app>
</payara-web-app>
----

[[disabling-classloading-delegation-on-ears]]
Expand All @@ -300,19 +300,19 @@ Here is an example:

It's possible to configure an extreme isolation level on the class loading delegation for deployed applications. With this extreme isolation behavior, a deployed application can force the server to load only classes and resources from libraries included on the server that belong to *whitelisted packages* defined on its deployment descriptors.

To configure whitelist packaging you can use the `<whitelist-package>` element on the `payara-web.xml` / `glassfish-web.xml` (for WAR artifacts) or the `glassfish-application.xml` (for EAR artifacts) deployment descriptors. This element can be included multiple times to whitelist multiple packages.
To configure whitelist packaging you can use the `<whitelist-package>` element on the `payara-web.xml` (for WAR artifacts) or the `glassfish-application.xml` (for EAR artifacts) deployment descriptors. This element can be included multiple times to whitelist multiple packages.

Here is an example of whitelisting both the *Google Guava*, *Jackson* and *Faces Config* packages for a WAR application:

[source, xml]
----
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app error-url="">
<!DOCTYPE payara-web-app PUBLIC "-//Payara.fish//DTD Payara Server 4 Servlet 3.0//EN" "https://docs.payara.fish/schemas/payara-web-app_4.dtd">
<payara-web-app error-url="">
<whitelist-package>com.google.guava</whitelist-package>
<whitelist-package>com.fasterxml.jackson</whitelist-package>
<whitelist-package>com.sun.faces.spi.FacesConfigResourceProvider</whitelist-package>
</glassfish-web-app>
</payara-web-app>
----

The whitelist syntax is simple: Define the name of the package which contains the classes or resources in question. For example writing `com.google` would whitelist all Google libraries included on the server, while writing `com.google.guava` would only whitelist the Google Guava library instead.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -218,7 +218,7 @@ To disable connection pooling, set the _Pooling_ attribute to `false`. The defau
[[using-application-scoped-connectors]]
=== Using Application-Scoped Connectors

You can define an application-scoped connector or other resource for an enterprise application, web module, EJB module, connector module, or application client module by supplying a `payara-resources.xml` or `glassfish-resources.xml` deployment descriptor file. For details, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Deploying Applications.adoc#application-scoped-resources[Application-Scoped Resources]" in the Payara Server Application Deployment section.
You can define an application-scoped connector or other resource for an enterprise application, web module, EJB module, connector module, or application client module by supplying a `payara-resources.xml` deployment descriptor file. For details, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Deploying Applications.adoc#application-scoped-resources[Application-Scoped Resources]" in the Payara Server Application Deployment section.

[[inbound-communication-support]]
== Inbound Communication Support
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ You deploy a web service endpoint to Payara Server just as you would any servlet

IMPORTANT: For complex services with dependent classes, user specified WSDL files, or other advanced features, auto-deployment of an annotated file is not sufficient.

The Payara Server deployment descriptor files `glassfish-web.xml`/`payara-web.xml` and `glassfish-ejb-jar.xml` provide optional web service enhancements in the `webservice-endpoint` and `webservice-description` elements, including a `debugging-enabled` sub-element that enables the creation of a test page.
The Payara Server deployment descriptor files `payara-web.xml` and `glassfish-ejb-jar.xml` provide optional web service enhancements in the `webservice-endpoint` and `webservice-description` elements, including a `debugging-enabled` sub-element that enables the creation of a test page.

The test page feature is enabled by default and described in xref:#the-web-service-uri-wsdl-file-and-test-page[The Web Service URI, WSDL File, and Test Page].

Expand All @@ -38,7 +38,7 @@ http://${host}:${port}/${context-root}/${servlet-mapping-url-pattern}
----

The context-root is defined in the `application.xml` or `web.xml` file, and can be overridden in the `glassfish-application.xml` or
`glassfish-web.xml`/`payara-web.xml` file. The servlet-mapping-url-pattern is defined in the `web.xml` file.
`payara-web.xml` file. The servlet-mapping-url-pattern is defined in the `web.xml` file.

In the following example, the context-root is `my-ws` and the servlet-mapping-url-pattern is `/simple` for local deployment in the default port:

Expand Down Expand Up @@ -68,7 +68,7 @@ You can also test a service using the Administration Console. Open the _Web Serv
WARNING: The tester webpage works only for WS-I compliant web services. This means that the tester servlet does not work for services with WSDL files that use RPC/encoded binding.

The Web Service tester application is enabled by default. You can disable the test page for a web service by setting the value of the
`debugging-enabled` element in the `glassfish-web.xml`/`payara-web.xml` and `glassfish-ejb-jar.xml` deployment descriptor to `false`.
`debugging-enabled` element in the `payara-web.xml` and `glassfish-ejb-jar.xml` deployment descriptor to `false`.

[[the-databinding-provider]]
== The Databinding Provider
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ For example, if your servlet returns a stock quote that updates every *5 minutes

Whether to cache results and how to cache them depends on the data involved. For example, it makes no sense to cache the results of a quiz submission, because the input to the servlet is different each time. However, it makes sense to cache a high level report showing demographic data taken from quiz results that is updated once an hour.

To define how a web application handles response caching, you'll have to modify specific attributes in the `glassfish-web.xml` or `payara-web.xml` deployment descriptor file.
To define how a web application handles response caching, you'll have to modify specific attributes in the `payara-web.xml` deployment descriptor file.

WARNING: A servlet that uses caching is not portable.

Expand Down Expand Up @@ -74,7 +74,7 @@ If you enable caching but do not provide any special configuration for a servlet
[[caching-example]]
==== Caching Example

Here is an example cache element in the `glassfish-web.xml`/`payara-web.xml` file:
Here is an example cache element in the `payara-web.xml` file:

[source,xml]
----
Expand Down Expand Up @@ -117,14 +117,14 @@ Here is an example cache element in the `glassfish-web.xml`/`payara-web.xml` fil
</cache>
----

For more information about the `glassfish-web.xml`/`payara-web.xml` caching settings, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#cache[cache]" in the Payara Server Application Deployment section.
For more information about the `payara-web.xml` caching settings, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#cache[cache]" in the Payara Server Application Deployment section.

[[the-cachekeygenerator-interface]]
==== The CacheKeyGenerator Interface

The built-in default `CacheHelper` implementation allows web applications to customize the key generation. An application component (in a servlet or JSP) can set up a custom `CacheKeyGenerator` implementation as an attribute in the `ServletContext`.

The name of the context attribute is configurable as the `value` of the `cacheKeyGeneratorAttrName` property in the `default-helper` element of the `glassfish-web.xml`/`payara-web.xml` deployment descriptor.
The name of the context attribute is configurable as the `value` of the `cacheKeyGeneratorAttrName` property in the `default-helper` element of the `payara-web.xml` deployment descriptor.

For more information, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#default-helper[default-helper]" in the Payara Server Application Deployment section.

Expand Down Expand Up @@ -358,7 +358,7 @@ This section describes how to create and manage HTTP sessions that allows users
[[http-sessions-cookies-and-url-rewriting]]
==== HTTP Sessions, Cookies, and URL Rewriting

To configure whether and how HTTP sessions use cookies and URL rewriting, edit the `session-properties` and `cookie-properties elements in the `glassfish-web.xml` or `payara-web.xml` file for an individual web application. For more details about the properties you can configure, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#session-properties[session-properties]" "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#cookie-properties[cookie-properties]" and in the Payara Server Application Deployment section.
To configure whether and how HTTP sessions use cookies and URL rewriting, edit the `session-properties` and `cookie-properties elements in the `payara-web.xml` file for an individual web application. For more details about the properties you can configure, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#session-properties[session-properties]" "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#cookie-properties[cookie-properties]" and in the Payara Server Application Deployment section.

For information about configuring default session properties for the
entire web container, see xref:#using-the-default-web.xml-file[Using the `default-web.xml` File].
Expand All @@ -377,7 +377,7 @@ The default for the `--keepstate` is `false`. This option is supported only on t

NOTE: This option is not supported and ignored for other targets (clusters and deployment groups included).

For web applications, this feature is applicable only if in the `payara-web.xml` / `glassfish-web.xml` deployment descriptor files when the `persistence-type` attribute of the `session-manager` element is set to `file`.
For web applications, this feature is applicable only if in the `payara-web.xml` deployment descriptor files when the `persistence-type` attribute of the `session-manager` element is set to `file`.

If any active web session fails to be preserved or restored, none of the sessions will be available when the redeployment is complete. However, the redeployment continues and a warning is logged.

Expand Down Expand Up @@ -454,7 +454,7 @@ correctly rolled back or committed.

A session manager automatically creates new session objects whenever a new session starts. In some circumstances, clients do not join the session, for example, if the session manager uses cookies and the client does not accept cookies.

The Payara Platform offers these session management options, determined by the `session-manager` element's `persistence-type` attribute in the `glassfish-web.xml`/`payara-web.xml` file:
The Payara Platform offers these session management options, determined by the `session-manager` element's `persistence-type` attribute in the `payara-web.xml` file:

* xref:#the-memory-persistence-type[The `memory` Persistence Type]
* xref:#the-file-persistence-type[The `file` Persistence Type], which uses a file to store session data
Expand All @@ -469,7 +469,7 @@ For more information, see "xref:Technical Documentation/Payara Server Documentat

This persistence type is not designed for a production environment that requires session persistence as it provides no actual session persistence. However, you can configure it so that the session state in memory is written to the file system prior to server shutdown.

To specify the `memory` persistence type for a specific web application, edit the `glassfish-web.xml` or `payara-web.xml` file as in the following example. The `persistence-type` attribute is optional, but must be set to `memory` if included. This overrides the web container availability settings for the web application.
To specify the `memory` persistence type for a specific web application, edit the `payara-web.xml` file as in the following example. The `persistence-type` attribute is optional, but must be set to `memory` if included. This overrides the web container availability settings for the web application.

[source,xml]
----
Expand Down Expand Up @@ -498,7 +498,7 @@ The store also provides passivation and activation of the session state to help

NOTE: Make sure the `delete` option is set in the `server.policy` file, or expired file-based sessions might not be deleted properly. For more information about `server.policy`, see xref:Technical Documentation/Application Development/Securing Applications.adoc#the-server.policy-file[The`server.policy` File].

To specify the `file` persistence type for a specific web application, edit the `glassfish-web.xml` or `payara-web.xml` file as in the following example. Note that `persistence-type` must be set to `file`. This overrides the web container availability settings for the web application.
To specify the `file` persistence type for a specific web application, edit the `payara-web.xml` file as in the following example. Note that `persistence-type` must be set to `file`. This overrides the web container availability settings for the web application.

[source,xml]
----
Expand Down Expand Up @@ -668,8 +668,8 @@ This section explains how the server runtime determines the character encoding f
When processing a servlet request, the server uses the following order of precedence, first to last, to determine the request character encoding:

* The `getCharacterEncoding` method.
* A hidden field in the form, specified by the `form-hint-field` attribute of the `parameter-encoding` element in the `glassfish-web.xml` or `payara-web.xml` deployment descriptor
* The `default-charset` attribute of the `parameter-encoding` element in the `glassfish-web.xml` or `payara-web.xml` deployment descriptor
* A hidden field in the form, specified by the `form-hint-field` attribute of the `parameter-encoding` element in the `payara-web.xml` deployment descriptor
* The `default-charset` attribute of the `parameter-encoding` element in the `payara-web.xml` deployment descriptor
* The default encoding, which is `ISO-8859-1`

For details about the `parameter-encoding` element, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#parameter-encoding[parameter-encoding]" in the Payara Server Application Deployment section.
Expand Down Expand Up @@ -768,7 +768,7 @@ A listener class for a web module must implement one the following interfaces:
* `org.apache.catalina.LifecycleListener`
* `org.apache.catalina.InstanceListener`

In the `glassfish-web.xml`/`payara-web.xml` deployment descriptor, valve and listener properties for a web module look like this:
In the `payara-web.xml` deployment descriptor, valve and listener properties for a web module look like this:

[source,xml]
----
Expand Down Expand Up @@ -816,7 +816,7 @@ NOTE: Not all context definitions are supported by the Payara Platform.
[[enabling-webdav]]
==== Enabling WebDav

To enable WebDav in Payara Server, you edit the `web.xml` and `glassfish-web.xml`/`payara-web.xml` files as follows.
To enable WebDav in Payara Server, you edit the `web.xml` and `payara-web.xml` files as follows.

First, enable the WebDav servlet in your `web.xml` file:

Expand Down Expand Up @@ -875,7 +875,7 @@ To protect the WebDav servlet so other users can't modify it, you must add a sec
</security-constraint>
----

Then define a security role mapping in your `glassfish-web.xml` or `payara-web.xml` deployment descriptor:
Then define a security role mapping in your `payara-web.xml` deployment descriptor:

[source,xml]
----
Expand Down Expand Up @@ -1024,9 +1024,9 @@ An alternate document root (`docroot`) allows a web application to serve request

To specify an alternate document root for a web application or a virtual server, use the `alternatedocroot_n` property, where n is a positive integer greater than zero that allows specifying more than one.

This property can be a sub-element of a `glassfish-web-app`/`payara-web-app` element in the `glassfish-web.xml`/`payara-web.xml` file or a virtual server property.
This property can be a sub-element of a `payara-web-app` element in the `payara-web.xml` file or a virtual server property.

For more information about these elements, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#glassfish-web-app[glassfish-web-app]" in the Payara Server Application Deployment section.
For more information about this element, see "xref:Technical Documentation/Payara Server Documentation/Application Deployment/Elements of Deployment Descriptors.adoc#glassfish-web-app[payara-web-app]" in the Payara Server Application Deployment section.

A virtual server's alternate document roots are considered only if a request does not map to any of the web modules deployed on that virtual server. A web module's alternate document roots are considered only once a request has been mapped to that web module.

Expand All @@ -1036,7 +1036,7 @@ If a request matches an alternate document root's URI pattern, it is mapped to t
* Longest path match
* Extension match

For example, the following properties specify three `glassfish-web.xml`/ `payara-web.xml` document root configurations. The URI pattern of the first alternate document root uses an exact match, whereas the URI patterns of the second and third alternate document roots use extension and longest path prefix matches, respectively:
For example, the following properties specify three `payara-web.xml` document root configurations. The URI pattern of the first alternate document root uses an exact match, whereas the URI patterns of the second and third alternate document roots use extension and longest path prefix matches, respectively:

[source,xml]
----
Expand Down
Loading