This section includes summaries of the following topics:
To set the default locale of the entire Application Server, which determines the locale of the Admin Console, the logs, and so on, use the Admin Console. In the developer profile, select the Application Server component, the Advanced tab, and the Domain Attributes tab. In the cluster profile, select the domain component. Then type a value in the Locale field. For details, click the Help button in the Admin Console.
This section explains how the Application Server determines the character encoding for the servlet request and the servlet response. For encodings you can use, see http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html.
When processing a servlet request, the server uses the following order of precedence, first to last, to determine the request character encoding:
A hidden field in the form, specified by the form-hint-field attribute of the parameter-encoding element in the sun-web.xml file
The default-charset attribute of the parameter-encoding element in the sun-web.xml file
The default, which is ISO-8859-1
For details about the parameter-encoding element, see parameter-encoding in Sun Java System Application Server 9.1 Application Deployment Guide.
When processing a servlet response, the server uses the following order of precedence, first to last, to determine the response character encoding:
The default, which is ISO-8859-1
A virtual server, also called a virtual host, is a virtual web server that serves content targeted for a specific URL. Multiple virtual servers can serve content using the same or different host names, port numbers, or IP addresses. The HTTP service directs incoming web requests to different virtual servers based on the URL.
When you first install the Application Server, a default virtual server is created. You can also assign a default virtual server to each new HTTP listener you create.
Web applications and Java EE applications containing web components (web modules) can be assigned to virtual servers during deployment. A web module can be assigned to more than one virtual server, and a virtual server can have more than one web module assigned to it.
For more information about virtual servers, see virtual-server in Sun Java System Application Server 9.1 Administration Reference.
Open the HTTP Listeners component under the HTTP Service component.
Select or create a new HTTP listener.
For more information, see Default Web Modules.
For details, click the Help button in the Admin Console from the HTTP Listeners page.
Deploy the application or web module and assign the desired virtual servers to it.
For more information, see Sun Java System Application Server 9.1 Application Deployment Guide.
Open the Virtual Servers component under the HTTP Service component.
Select the virtual server to which you want to assign a default web module.
Select the application or web module from the Default Web Module drop-down list.
For more information, see Default Web Modules.
For details, click the Help button in the Admin Console from the Virtual Servers page.
A default web module can be assigned to the default virtual server and to each new virtual server. For details, see Virtual Servers. To access the default web module for a virtual server, point the browser to the URL for the virtual server, but do not supply a context root. For example:
A virtual server with no default web module assigned serves HTML or JavaServer PagesTM (JSPTM) content from its document root, which is usually domain-dir/docroot. To access this HTML or JSP content, point your browser to the URL for the virtual server, do not supply a context root, but specify the target file.
The Servlet specification recommends that the Web class loader look in the local class loader before delegating to its parent. To make the Web class loader follow the delegation model in the Servlet specification, set delegate="false" in the class-loader element of the sun-web.xml file. It’s safe to do this only for a web module that does not interact with any other modules.
The default value is delegate="true", which causes the Web class loader to delegate in the same manner as the other class loaders. Use delegate="true" for a web application that accesses EJB components or that acts as a web service client or endpoint. For details about sun-web.xml, see The sun-web.xml File in Sun Java System Application Server 9.1 Application Deployment Guide.
For general information about class loaders, see Chapter 2, Class Loaders.
You can use the default-web.xml file to define features such as filters and security constraints that apply to all web applications.
The mime-mapping elements in default-web.xml are global and inherited by all web applications. You can override these mappings or define your own using mime-mapping elements in your web application's web.xml file. For more information about mime-mapping elements, see the Servlet specification.
You can use the Admin Console to edit the default-web.xml file. For details, click the Help button in the Admin Console. As an alternative, you can edit the file directly using the following steps.
Place the JAR file for the filter, security constraint, or other feature in the domain-dir/lib directory.
Edit the domain-dir/config/default-web.xml file to refer to the JAR file.
Restart the server.
For information about configuring logging and monitoring in the web container using the Admin Console, click the Help button in the Admin Console. In the developer profile, Logging and Monitor tabs are accessible from the Application Server page. In the Cluster profile, select Logger Settings under the relevant configuration, or select the Stand-Alone Instances component, select the instance from the table, and select the Monitor tab.
An idempotent request is one that does not cause any change or inconsistency in an application when retried. To enhance the availability of your applications deployed on an Application Server cluster, configure the load balancer to retry failed idempotent HTTP requests on all the Application Server instances in a cluster. This option can be used for read-only requests, for example, to retry a search request.
This section describes the following topics:
To configure idempotent URL response, specify the URLs that can be safely retried in idempotent-url-pattern elements in the sun-web.xml file. For example:
<idempotent-url-pattern url-pattern="sun_java/*" no-of-retries="10"/>
If none of the server instances can successfully serve the request, an error page is returned.
Since all requests for a given session are sent to the same application server instance, and if that Application Server instance is unreachable, the load balancer returns an error message. Normally, the request is not retried on another Application Server instance. However, if the URL pattern matches that specified in the sun-web.xml file, the request is implicitly retried on another Application Server instance in the cluster.
In HTTP, some methods (such as GET) are idempotent, while other methods (such as POST) are not. In effect, retrying an idempotent URL should not cause values to change on the server or in the database. The only difference should be a change in the response received by the user.
Examples of idempotent requests include search engine queries and database queries. The underlying principle is that the retry does not cause an update or modification of data.
A search engine, for example, sends HTTP requests with the same URL pattern to the load balancer. Specifying the URL pattern of the search request to the load balancer ensures that HTTP requests with the specified URL pattern are implicitly retried on another Application Server instance.
For example, if the request URL sent to the Application Server is of the type /search/something.html, then the URL pattern can be specified as /search/*.
Examples of non-idempotent requests include banking transactions and online shopping. If you retry such requests, money might be transferred twice from your account.
In all Editions of the Application Server, the Enumeration from request.getHeaders() contains multiple elements (one element per request header) instead of a single, aggregated value.
The header names used in HttpServletResponse.addXXXHeader() and HttpServletResponse.setXXXHeader() are returned as they were created.
You can configure custom valves and Catalina listeners for web modules or virtual servers by defining properties. In the domain.xml file, valve and listener properties look like this:
<web-module ...> <property name="valve_1" value="org.glassfish.extension.Valve"/> <property name="listener_1" value="org.glassfish.extension.MyLifecycleListener"/> </web-module>
You can define these properties in one of the following ways, then restart the server:
You can define properties using the asadmin set command. For example:
asadmin set domain1.applications.web-module.MyWebMod.property.valve_1="org.glassfish.extension.Valve"
asadmin set config1.http-service.virtual-server.MyVS.property.valve_1="org.glassfish.extension.Valve"
You can define virtual server properties using the Admin Console. Select the HTTP Service component under the relevant configuration, select Virtual Servers, and select the desired virtual server. Select Add Property, enter the property name and value, check the enable box, and select Save. For details, click the Help button in the Admin Console.
An alternate document root (docroot) allows a web application to serve requests for certain resources from outside its own docroot, based on whether those requests match one (or more) of the URI patterns of the web application's alternate docroots.
To specify an alternate docroot for a web application or a virtual server, use the alternatedocroot_n property, where n is a positive integer that allows specification of more than one. This property can be a subelement of a sun-web-app element in the sun-web.xml file or a virtual-server element in the domain.xml file. For more information about these elements, see sun-web-app in Sun Java System Application Server 9.1 Application Deployment Guide and virtual-server in Sun Java System Application Server 9.1 Administration Reference.
A virtual server's alternate docroots 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 docroots are considered only once a request has been mapped to that web module.
If a request matches an alternate docroot's URI pattern, it is mapped to the alternate docroot by appending the request URI (minus the web application's context root) to the alternate docroot's physical location (directory). If a request matches multiple URI patterns, the alternate docroot is determined according to the following precedence order:
Longest path match
For example, the following properties specify three docroots. The URI pattern of the first alternate docroot uses an exact match, whereas the URI patterns of the second and third alternate docroots use extension and longest path prefix matches, respectively.
<property name="alternatedocroot_1" value="from=/my.jpg dir=/srv/images/jpg"/> <property name="alternatedocroot_2" value="from=*.jpg dir=/srv/images/jpg"/> <property name="alternatedocroot_3" value="from=/jpg/* dir=/src/images"/>
The value of each alternate docroot has two components: The first component, from, specifies the alternate docroot's URI pattern, and the second component, dir, specifies the alternate docroot's physical location (directory).
Suppose the above examples belong to a web application deployed at http://company22.com/myapp. The first alternate docroot maps any requests with this URL:
To this resource:
The second alternate docroot maps any requests with a *.jpg suffix, such as:
To this physical location:
The third alternate docroot maps any requests whose URI starts with /myapp/jpg/, such as:
To the same directory as the second alternate docroot.
For example, the second alternate docroot maps this request:
The third alternate docroot maps:
If a request does not match any of the target web application's alternate docroots, or if the target web application does not specify any alternate docroots, the request is served from the web application's standard docroot, as usual.
You can specify that a request for an old URL is treated as a request for a new URL. This is called redirecting a URL.
To specify a redirected URL for a virtual server, use the redirect_n property, where n is a positive integer that allows specification of more than one. This property is a subelement of a virtual-server element in the domain.xml file. For more information about this element, see virtual-server in Sun Java System Application Server 9.1 Administration Reference. Each of these redirect_n properties is inherited by all web applications deployed on the virtual server.
The value of each redirect_n property has two components, which may be specified in any order:
The first component, from, specifies the prefix of the requested URI to match.
The second component, url-prefix, specifies the new URL prefix to return to the client. The from prefix is simply replaced by this URL prefix.
<property name="redirect_1" value="from=/dummy url-prefix=http://etude"/>
To enable Comet support for an HTTP listener and all its associated web applications, set the cometSupport property to true. For more information, see http-listener in Sun Java System Application Server 9.1 Administration Reference.
<servlet> <servlet-name>CheckIn</servlet-name> <servlet-class>CheckInServlet</servlet-class> <load-on-startup>0</load-on-startup> </servlet>
Use the contextXmlDefault property to specify the location, relative to domain-dir, of the context.xml file for a virtual server. For more information about virtual servers, see Virtual Servers. For more information about the context.xml file, see The Context Container.
To enable WebDav in the Application Server, you edit the web.xml and sun-web.xml files as follows.
First, enable the WebDav servlet in your web.xml file:
<servlet> <servlet-name>webdav</servlet-name> <servlet-class>org.apache.catalina.servlets.WebdavServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <init-param> <param-name>listings</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>readonly</param-name> <param-value>false</param-value> </init-param> </servlet>
Then define the servlet mapping associated with your WebDav servlet in your web.xml file:
<servlet-mapping> <servlet-name>webdav</servlet-name> <url-pattern>/webdav/*</url-pattern> </servlet-mapping>
To protect the WebDav servlet so other users can't modify it, add a security constraint in your web.xml file:
<security-constraint> <web-resource-collection> <web-resource-name>Login Resources</web-resource-name> <url-pattern>/webdav/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>Admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>default</realm-name> </login-config> <security-role> <role-name>Admin</role-name> </security-role> </security-constraint>
Then define a security role mapping in your sun-web.xml file:
<security-role-mapping> <role-name>Admin</role-name> <group-name>Admin</group-name> </security-role-mapping>
If you are using the file realm, create a user and password. For example:
asadmin create-file-user --user admin --host localhost --port 4848 --terse=true --groups Admin --authrealmname default admin
You can now use any WebDav client by connecting to the WebDav servlet URL, which has this format:
You can add the WebDav servlet to your default-web.xml file to enable it for all applications, but you can't set up a security role mapping to protect it.
To set up mod_jk, follow these steps:
Obtain the following software:
Apache Tomcat Connectors (http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/)
Apache Tomcat 5.5.16, needed for just one JAR file (http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.16/bin/apache-tomcat-5.5.16.tar.gz)
Apache Commons Logging 1.0.4 (http://archive.apache.org/dist/jakarta/commons/logging/binaries/commons-logging-1.0.4.tar.gz)
Apache Commons Modeler 1.1 (http://archive.apache.org/dist/jakarta/commons/modeler/binaries/modeler-1.1.tar.gz)
Install mod_jk as described at http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html.
Copy the following Tomcat and Jakarta Commons files to as-install/lib:
Create and configure the following files:
/etc/httpd/conf/worker.properties or domain-dir/config/glassfish-jk.properties (to use non-default values of attributes described at http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html)
Examples of these files are shown after these steps. If you use both worker.properties and glassfish-jk.properties files, the file referenced by httpd.conf, or referenced by httpd.conf first, takes precedence.
Enable mod_jk using the following command:
asadmin create-jvm-options -Dcom.sun.enterprise.web.connector.enableJK=8009
If you are using the glassfish-jk.properties file and not referencing it in httpd.conf, point to it using the following command:
asadmin create-jvm-options -Dcom.sun.enterprise.web.connector.enableJK.propertyFile=domain-dir/config/glassfish-jk.properties
Restart the Application Server.
Here is an example httpd.conf file:
LoadModule jk_module /usr/lib/httpd/modules/mod_jk.so JkWorkersFile /etc/httpd/conf/worker.properties # Where to put jk logs JkLogFile /var/log/httpd/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel debug # Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " # JkOptions indicate to send SSL KEY SIZE, JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories # JkRequestLogFormat set the request format JkRequestLogFormat "%w %V %T" # Send all jsp requests to GlassFish JkMount /*.jsp worker1 # Send all glassfish-test requests to GlassFish JkMount /glassfish-test/* worker1
Here is an example worker.properties or glassfish-jk.properties file:
# Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=localhost.localdomain worker.worker1.port=8009 worker.worker1.lbfactor=50 worker.worker1.cachesize=10 worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1 worker.worker1.socket_timeout=300