<application>
Not required if you deploy your app using Google Cloud SDK-based tooling, such as the gcloud app deploy command, IntelliJ or Eclipse plugins, Maven or Gradle plugins. The Google Cloud SDK-based tooling ignore this element and get the project ID from the gcloud config project property. Note that although you can override the project ID using the gcloud command line tool, this sets a machine-wide project ID, which may cause confusion if you are developing multiple projects. The <application> element contains the application's project ID. This is the project ID you register when you create your project in the Google Cloud console.
<app-engine-apis> Optional. If you want to use the App Engine legacy bundled services for second-generation runtimes, set this field to true.
<entrypoint> Optional and only for second-generation runtimes. Overrides the default entrypoint which is the process command line that boots the Java application. By default, the generated entrypoint for a F4 instance class (memory settings are calculated from the instance class) is equivalent to the following configuration:
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <entrypoint> java -showversion -Xms32M -Xmx819M -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:+PrintCommandLineFlags --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.logging/java.util.logging=ALL-UNNAMED --add-opens java.base/java.util.concurrent=ALL-UNNAMED -Dclasspath.runtimebase=/base/java_runtime -Djava.class.path=/base/java_runtime/runtime-main.jar -Djava.library.path=/base/java_runtime: com/google/apphosting/runtime/JavaRuntimeMainWithDefaults --fixed_application_path=/workspace /base/java_runtime </entrypoint> </appengine-web-app>
You can modify the configuration to add extra JVM process flags or define your own process to boot. Notice that the application is deployed in the /workspace directory, while the runtime JARs are located under /base/java_runtime directory.
<async-session-persistence>
Optional. It's possible to reduce request latency by configuring your application to asynchronously write HTTP session data to the datastore:
<async-session-persistence enabled="true" />
With async session persistence turned on, App Engine will submit a Task Queue task to write session data to the datastore before writing the data to memcache. By default the task will be submitted to the `default` queue. If you'd like to use a different queue, add the `queue-name` attribute:
<async-session-persistence enabled="true" queue-name="myqueue"/>
Session data is always written synchronously to memcache. If a request tries to read the session data when memcache is not available (or the session data has been flushed), it will fail over to Datastore, which might not yet have the most recent session data. This means that asynchronous session persistence can cause your application to see stale session data. However, for most applications the latency benefit far outweighs the risk.
<auto-id-policy> Optional. If you are setting entity identifiers automatically, you can change the method employed by setting the auto ID policy. The following are valid options:
default
legacy
<automatic-scaling>
Optional. For a full explanation, see the automatic scaling section.
<basic-scaling>
Optional. For a full explanation, see the basic scaling section.
<env-variables>
Optional. The appengine-web.xml file can define environment variables that are set when the application is running.
<env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables>
To avoid conflicts with your local environment, the development server does not set environment variables based on this file, and requires that the local environment have these variables already set to matching values.
export DEFAULT_ENCODING="UTF-8" dev_appserver war
When deployed to App Engine, the environment is created with these variables already set.
<inbound-services>
Optional. Before an application can receive email, the application must be configured to enable the service. You enable the service for a Java app by including an <inbound-services> section in the appengine-web.xml file.
The following inbound service is available:
mail
<instance-class>
Optional. The instance class size for this module.
The following instance classes are available when specifying different scaling options:
automatic_scaling
automatic_scaling element.
basic_scaling
basic_scaling element.
manual_scaling
manual_scaling element.
Note: If instance-class is set to F2 or higher, you can optimize your instances by setting max-concurrent-requests to a value higher than 10, which is the default. To find the optimal value, gradually increase it and monitor the performance of your application.
<manual-scaling>
Optional. For a full explanation, see the manual scaling section.
<precompilation-enabled>
Optional. App Engine uses a "precompilation" process with the Java bytecode of an app to enhance the performance of the app in the Java runtime environment. Precompiled code functions identically to the original bytecode.
If for some reason you prefer that your app not use precompilation, you can turn it off by adding the following to your appengine-web.xml file:
<precompilation-enabled>false</precompilation-enabled>
<module>
Note: Modules are now named Services and services are still declared in appengine-web.xml files as modules, for example: <module>service_name</module>.
Required if creating a service. Optional for the default service. Each service and each version must have a name. A name can contain numbers, letters, and hyphens. It cannot be longer than 63 characters, start or end with a hyphen, and contain the string `-dot`. Choose a unique name for each service and each version. Don't reuse names between services and versions.
Also see service.
<public-root>
Optional. The <public-root> is a directory in your application that contains the static files for your application. When a request for a static file is made, the <public-root> for your application is prepended to the request path. This gives the path of an application file containing the content that is being requested.
The default <public-root> is /.
For example, the following would map the URL path /index.html to the application file path /static/index.html:
<public-root>/static</public-root>
<resource-files>
Optional. The files listed in the <resource-files> element are accessible by the application code using the filesystem. These files are stored on the application servers with the app as opposed to how static files are stored and served.
The <resource-files> element can contain the following elements:
<include>
<include> element designates the files as resource files and available to your application code. These files are only available to your code on a read-only basis and not for traffic serving. Including and excluding files.
<exclude>
Files and directories matching <exclude> patterns will not be uploaded or available to your application code. However, these files and directories will still be accessible to your application when running on the local Development Server. For more information, see Including and excluding files.
<resource-files> <include path="/**.xml" /> <exclude path="/feeds/**.xml" /> </resource-files>
This example demonstrates how to designate all .xml files as resource files except those in the feeds/ directory and all of its subdirectories.
App Engine resource files are read using java.io.File or javax.servlet.ServletContext.getResource/getResourceAsStream. They are not accessible via Class.getResourceAsStream().
<runtime>
To use the latest supported Java version, you must specify this entry with the value java21.
<runtime>java21</runtime>
<service>
Services were formerly known as modules.
Currently, defining a service as: <service>service_name</service > is supported only by gcloud app commands.
<service-account>
Optional. The <service-account> element lets you specify a user-managed service account as the identity for the version. The specified service account will be used when accessing other Google Cloud services and executing tasks.
<service-account>[SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com</service-account>
<sessions-enabled>
Optional. App Engine includes an implementation of sessions, using the servlet session interface. The implementation stores session data in Datastore for persistence, and also uses memcache for speed. As with most other servlet containers, the session attributes that are set with `session.setAttribute()` during the request are persisted at the end of the request.
This feature is off by default. To turn it on, add the following to appengine-web.xml:
<sessions-enabled>true</sessions-enabled>
The implementation creates Datastore entities of the kind _ah_SESSION, and memcache entries using keys with a prefix of _ahs. You can delete these entities using the Dataflow template.
Note: Because App Engine stores session data in Datastore and memcache, all values stored in the session must implement the java.io.Serializable interface.
See async-session-persistence element for reducing the latency of the storage of session data.
<ssl-enabled>
Optional. By default, any user can access any URL using either HTTP or HTTPS. You can configure an app to require HTTPS for certain URLs in the deployment descriptor. See Deployment Descriptor: Secure URLs.
If you want to disallow the use of HTTPS for the application, put the following in the appengine-web.xml file:
<ssl-enabled>false</ssl-enabled>
There is no way to disallow HTTPS for some URL paths and not others in the Java runtime environment.
<static-error-handlers>
Optional. When certain errors occur, App Engine serves a generic error page. You can configure your app to serve a custom static file instead of these generic error pages, so long as the custom error data is less than 10 kilobytes. You can set up different static files to be served for each supported error code by specifying the files in your app's appengine-web.xml file. To serve custom error pages, add a <static-error-handlers> section to your appengine-web.xml, as ins this example:
<static-error-handlers> <handler file="default_error.html" /> <handler file="over_quota.html" error-code="over_quota" /> </static-error-handlers>
Warning: Make sure that the path to the error response file does not overlap with static file handler paths.
Each file entry indicates a static file that should be served in place of the generic error response. The error-code indicates which error code should cause the associated file to be served. Supported error codes are as follows:
over_quota
timeout
The error-code is optional; if it's not specified, the given file is the default error response for your app.
You can optionally specify a mime-type to use when serving the custom error. See a complete list of MIME types.
<static-files>
Optional. The <static-files> element specifies patterns that match file paths to include and exclude from the list of static files, overriding or amending the default behavior. Static file are served from dedicated servers and caches that are separate from the application servers and are useful for serving static content such as images, CSS stylesheets or JavaScript files.
The <static-files> element can contain the following elements:
<include>
An <include> element overrides the default behavior of including all non-JSP files. The <include> element can specify HTTP headers to use when responding to request for the specified resources. For more information, see Including and excluding files.
You can override the default static cache expiration by specifying the expiration attribute on the include element. The value is a string of numbers and units, separated by spaces, where units can be d for days, h for hours, m for minutes, and s for seconds. For example, "4d 5h" sets cache expiration to 4 days and 5 hours after the file is first requested. For more information, see Cache expiration.
<exclude>
<exclude> patterns will not be uploaded when you deploy your app to App Engine. However, these files and directories will still be accessible to your application when running on the local Development Server. For more information, see Including and excluding files.
<static-files>
<include path="/my_static-files" >
<http-header name="Access-Control-Allow-Origin"
value="http://example.org" />
</include>
</static-files><system-properties>
Optional. The appengine-web.xml file can define system properties and environment variables that are set when the application is running.
<system-properties>
<property name="myapp.maximum-message-length" value="140" />
<property name="myapp.notify-every-n-signups" value="1000" />
<property name="myapp.notify-url"
value="http://www.example.com/signupnotify" />
</system-properties>
<env-variables>
<env-var name="DEFAULT_ENCODING" value="UTF-8" />
</env-variables>
Optional. You can configure an HTTP connector for improving CPU and memory utilization.
<system-properties>
<property name="appengine.use.httpconnector" value="true"/>
</system-properties>
Optional. You can configure the underlying runtime to work on EE8 or EE10 using the following system property. For more information regarding EE support, see Upgrade to Java 21.
<system-properties>
<property name="appengine.use.EE10" value="true"/> <!-- or EE8 -->
</system-properties>
Starting in Java 21, you can configure your Java web server to use virtual threads. For example:
<system-properties>
<property name="appengine.use.virtualthreads" value="true"/>
</system-properties> For more information regarding thread support, see Jetty 12 – Virtual Threads Support. <url-stream-handler>
Optional. Possible values, native or urlfetch.
The default value is native, which means that standard Java network classes use the standard Java HTTP(S) transport. To use this setting, you must enable billing for your app, or you will get exceptions, which are documented in Issue requests.
If you set url-stream-handler to urlfetch, URL.openConnection and related methods will use URL Fetch for http and https transport.
<url-stream-handler>urlfetch</url-stream-handler>
<version>
The <version> element contains the version identifier for the latest version of the app's code. The version identifier can contain lowercase letters, digits, and hyphens. It cannot begin with the prefix "ah-" and the names "default" and "latest" are reserved and cannot be used.
Version names should begin with a letter, to distinguish them from numeric instances which are always specified by a number. This avoids the ambiguity with URLs like 123.my-module.uc.r.appspot.com, which can be interpreted two ways: If version "123" exists, the target will be version "123" of the given module. If that version does not exist, the target will be instance number 123 of the default version of the module.
<warmup-requests-enabled>
Optional. Default: true. Warmup requests are enabled by default for Java applications.
With warmup requests enabled, the App Engine infrastructure issues `GET` requests to /_ah/warmup, initializing <load-on-startup> servlets, ServletContextListeners, and custom warmup servlets, which allow you to initialize your application's code as it requires. You might need to implement your own handler for /_ah/warmup depending on which of these methods you choose.
To disable warmup requests, specify false for this element:
<warmup-requests-enabled>false</warmup-requests-enabled>
<vpc-access-connector>
Optional. Configures your application to use a Serverless VPC Access connector, enabling the application to send requests to internal resources in your VPC network. Specify the fully-qualified name of a connector in the <name> element:
<vpc-access-connector> <name>projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]</name> </vpc-access-connector>
For more information, see Connecting to internal resources in a VPC network.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4