Friday May 29, 2009

New sorting options for directory listings in GlassFish v3

New sorting options for directory listings in GlassFish v3

New sorting options for directory listings in GlassFish v3

The section in the Servlet specification that talks about Welcome Files has this:

If no matching welcome file is found in the manner described, the container may handle the request in a manner it finds suitable. For some configurations this may mean returning a directory listing or for others returning a 404 response.

GlassFish may be configured to return a directory listing if a request fails to be mapped to any welcome page, by setting the listings init parameter in the DefaultServlet declaration of the domain's default-web.xml to true, as follows:


Up until now, the directory listings were always sorted in alphabetical order.

The latest GlassFish v3 provides additional sorting options by last-modified date and size, by introducing a new init parameter with name sortedBy for the DefaultServlet, whose value may be set to one of NAME (the default), LAST_MODIFIED, or SIZE, as follows:


Please send any questions or comments you may have to the GlassFish webtier alias, or post them to the GlassFish webtier forum.

Thursday Dec 11, 2008

Changes to Servlet and Filter Registration APIs in Servlet 3.0

Changes to Servlet and Filter Registration APIs in Servlet 3.0

Changes to Servlet and Filter Registration APIs in Servlet 3.0

Right after the Public Review draft of the Servlet 3.0 specification had been handed off to the JCP for publication, the Servlet EG changed the signature of the addServlet and addFilter APIs on javax.servlet.ServletContext. These APIs are new in Servlet 3.0, and allow servlets and filters to be registered at runtime, without having to be declared in a web.xml deployment descriptor.

It was felt that the previous method signatures:

  addServlet(String servletName, String description, String className, Map initParameters, int loadOnStartup, boolean isAsyncSupported)


  addFilter(String filterName, String description, String className, Map initParameters, boolean isAsyncSupported)

had too many parameters, and there was concern that these methods would have to be overloaded every time a new parameter was added in the future.

Therefore, the Servlet EG decided to change addServlet to take just servletName and className parameters, and to change addFilter to take just filterName and className parameters, and to have these methods return ServletRegistration and FilterRegistration objects, respectively, on which any further configuration would occur.

For example, the following ServletContextListener registers one servlet and one filter when invoked at its contextInitialized method, and then further configures the registered servlet and filter through their respective ServletRegistration and FilterRegistration objects:

  public void contextInitialized(ServletContextEvent sce) {
      ServletContext sc = sce.getServletContext();

       \* Register servlet
      ServletRegistration sr = sc.addServlet("NewServlet", "test.NewServlet");
      sr.setInitParameter("servletInitName", "servletInitValue");
      sc.addServletMapping("NewServlet", new String[] {"/newServlet"});

       \* Register filter that is going to intercept any requests to the
       \* servlet
      FilterRegistration fr = sc.addFilter("NewFilter", "test.NewFilter");
      fr.setInitParameter("filterInitName", "filterInitValue");
          EnumSet.of(DispatcherType.REQUEST), true, "NewServlet");

While these changes are not reflected in the Public Review draft of the Servlet 3.0 specification, they have already been implemented in the trunk version of GlassFish v3, which is going to be the reference implementation of the Servlet 3.0 specification.

Please send any questions or comments to the GlassFish webtier alias, or post them to the GlassFish webtier forum.

Monday Dec 08, 2008

How to downshift from HTTPS to HTTP in your web application

How to downshift from HTTPS to HTTP in your web application

How to downshift from HTTPS to HTTP in your web application

Problem description

Web applications will normally protect any of their web resources that process security-sensitive information (e.g., the login page used by FORM authentication) with SSL, to ensure that the information submitted by the user (e.g., username and password security credentials) will not be transmitted in the clear.

Some web applications will only protect web resources that process security-sensitive information in this manner, while allowing requests for other resources to travel in the clear.

Imagine a user accessing some of the unprotected resources of a web application (over HTTP) before accessing a resource that requires FORM authentication, where the FORM login page is guarded by a transport guarantee of CONFIDENTIAL according to the web application's deployment descriptor. In this case, the protocol will change from HTTP to HTTPS (to satisfy the transport guarantee of the login page), and will remain HTTPS even after the user has authenticated successfully and continues accessing any of the unprotected resources.

The fact that the protocol remains HTTPS once it has been changed to HTTPS, even though HTTPS may no longer be required, can be a problem for performance sensitive applications that do not want to incur the overhead of SSL unless required.

This blog explains how a web application can be written so that the protocol changes back to HTTP when HTTPS is no longer needed.


Imagine a very simple web application containing two servlets and, which are mapped to /useHttp and /useHttps, respectively. Further assume that the web application must satisfy the following requirements:

  • REQ_1: Access to "/useHttps" must be over HTTPS (otherwise, the servlet will throw an exception). This means that if the current protocol is HTTP, it must be upgraded to HTTPS.
  • REQ_2: Access to "/useHttp" must be over HTTP (otherwise, the servlet will throw an exception). This means that if the current protocol is HTTPS, it must be downshifted to HTTP.

REQ_1 will be handled automatically by the container, by declaring the following security constraint in the web application's web.xml:

      <web-resource-name>Protected resource</web-resource-name>

REQ_2 cannot be handled automatically by the container, and must be implemented by the application itself. In order to address REQ_2, we are going to implement a filter that intercepts every request and determines programmtically whether the target resource is guarded by a transport guarantee of CONFIDENTIAL. If it is not, and the request came in over HTTPS, the filter will issue a redirect to the target resource over HTTP.

In order to determine if a requested resource is guarded by HTTPS, the filter leverages the JavaTM Authorization Contract for Containers (Java ACC), which defines new classes to satisfy the authorization model of the Java Platform, Enterprise Edition. In our particular case, the filter creates and uses an instance of to check if the target resource of a request is guarded by HTTPS.

The complete source code of the filter and the two servlets, as well as the web.xml, are provided as part of the sample application's WAR file and may be downloaded from this link.

For the sake of simplicity, we assume the default GlassFish configuration of three HTTP listeners: one listener reserved for any admin requests, a second listener for user traffic over HTTP (on port 8080), and a third listener for user traffic over HTTPS (on port 8181). (Notice that when you are using GlassFish v3 Prelude, you must enable the HTTPS listener on port 8181, which is disabled by default.)

The port number of the HTTP port for user requests is fed into the filter via an init parameter in web.xml:


This is necessary so that the filter will know which port number to use when redirecting from HTTPS to HTTP.


To see the upshift from HTTP to HTTPS, and downshift from HTTPS to HTTP in action, follow these simple steps:

  1. Download and install GlassFish v2 UR2 or GlassFish v3 Prelude.
  2. Download the sample web application sample.war, and deploy it to GlassFish.
  3. Access this URL: http://leah:8080/sample/useHttps. Notice how the request gets redirected to the HTTPS port, and how the protocol changes from HTTP to HTTPS: https://localhost:8181/sample/useHttps.
  4. Now edit the above HTTPS URL in your browser's address window by removing the trailing s from useHttps, so that the URL reads: https://localhost:8181/sample/useHttp, and hit return. Notice how the browser displays this warning message: You are about to leave an encrypted page. Information you send or receive from now on could easily be read by a third party, before issuing a redirect to the HTTP port and downshifting the protocol from HTTPS to HTTP: http://localhost:8080/sample/useHttp

I hope you found this blog useful. Please send any questions or comments you may have to the GlassFish webtier alias, or post them to the GlassFish webtier forum. I also would like to thank GlassFish security architect Ron Monzillo for his Java ACC related contribution to the idea behind this blog and to the filter code of the sample web application.

Thursday Oct 16, 2008

How to configure the security of HTTP session and Single-Sign-On cookies in GlassFish

How to configure the security of HTTP session and Single-Sign-On cookies in GlassFish

How to configure the security of HTTP session and Single-Sign-On cookies in GlassFish


The javax.servlet.http.Cookie API allows servlets to mark application specific cookies as secure by calling setSecure. However, there is no programmtic support for marking container-generated cookies, such as HTTP session (aka JSESSIONID) and Single-Sign-On (aka JSESSIONIDSSO) related cookies, as secure. This blog explains how the security aspects of these types of cookies may be configured in the upcoming GlassFish v2.1 and GlassFish v3 Prelude releases.


The syntax for cookies, as given by the cookie specification, defines a Secure attribute (with no value). This attribute serves as an indication by the server to the client that the cookie contents require protection.

The client may determine what level of security it considers appropriate for cookies marked as secure. In most cases, it will send a secure cookie back to the server only if the connection is protected with SSL.

By default, a JSESSIONID cookie inherits the security setting of the request that initiated the corresponding HTTP session: If the HTTP session has been initiated by an HTTPS request, the secure attribute of its JSESSIONID cookie will be set to true, and will remain false if the session was initiated by a plain HTTP request.

In some cases, it may be necessary to override this default behaviour. For example, if the GlassFish instance is front-ended by an SSL-offloading loadbalancer (as shown in the image below), all requests received by it will be of type HTTP, whereas the traffic between the client and the loadbalancer is over HTTPS. In this case, any JSESSIONID cookies created by the web container on the GlassFish instance must be marked as secure (even though the corresponding sessions were initiated by HTTP requests), so that their contents (in particular the session ids) will be protected as they travel between the client and the loadbalancer.

Security configuration of HTTP session cookies

The upcoming GlassFish v2.1 and GlassFish v3 Prelude releases add support for configuring a JSESSIONID cookie's secure attribute through a cookie property with name cookieSecure in sun-web.xml, as follows:

  <?xml version="1.0" encoding="UTF-8"?>
        <b><property name="cookieSecure" value="[true|false|dynamic]"/></b>

The semantics of the possible values of the cookieSecure property are as follows.

  • true: Any JSESSIONID cookies created by the container on behalf of the web application will be marked as secure.
  • false: Any JSESSIONID cookies created by the container on behalf of the web application will be marked as non-secure.
  • dynamic: A JSESSIONID cookie created by the container on behalf of the web application will inherit its security setting from the request that initiated the correspoding session: If the session was initiated by an HTTPS request, its JSESSIONID cookie will be marked as secure, and will remain non-secure otherwise. This is the default.

Notice that the next version of the Servlet Specification (Servlet 3.0) is going to provide programmatic configuration support (including security) for JSESSIONID cookies by defining a new javax.servlet.SessionCookieConfig class along with a new setSessionCookieConfig method on javax.servlet.ServletContext which takes an argument of type javax.servlet.SessionCookieConfig. The configuration options provided by javax.servlet.SessionCookieConfig will be equivalent to the cookie-properties in sun-web.xml (with the addition of configuration support for the httpOnly cookie property).

Security configuration of Single-Sign-On cookies

Based on a user request, GlassFish v3 Prelude adds support for configuring the security of JSESSIONIDSSO cookies used in the context of Single-Sign-On (SSO). Since multiple applications may participate in SSO, and since only applications deployed to the same virtual server and belonging to the same security realm may participate in SSO, exposing the configuration of a JSESSIONIDSSO cookie's Secure attribute at the virtual server level seemed appropriate. Therefore, GlassFish v3 Prelude defines a new virtual-server property with name ssoCookieSecure, which may be set to true, false, or dynamic. The semantics are the same as described above for JSESSIONID cookies, except that in the case of dynamic (the default), the security setting of the JSESSIONIDSSO cookie is derived from the first request that initiated a session participating in SSO.

Please send any follow-up questions, or any questions on the GlassFish webtier in general, to, or post them to the webtier forum.

Wednesday Oct 01, 2008

Retain session data during redeployment

Retain session data during redeployment

Retain session data during redeployment


The just-released GlassFish v3 Prelude provides a new feature that is going to become very popular with developers: the ability to retain HTTP session data across redeploys, which is something Jerome Dochez and I have worked on together.


Let me briefly explain what motivated this feature, and why it is so important: When you redeploy a application, the application first gets undeployed, and then its new, updates bits are deployed. During the undeploy, GlassFish is going to remove any and all traces of the application, including its classloader, compiled JSPs, and file-persisted HTTP sessions (in case a file-based persistence mechanism is being used). In addition, any active HTTP sessions will be destroyed. In many cases, a number of HTTP sessions will have been created during each development cycle. After a redeployment, these sessions will have to be recreated from scratch: A tedious and time-consuming task!

How to enable

GlassFish v3 Prelude adds the ability to preserve any active HTTP sessions during a redeploy. A user may request this feature by passing the new keepSessions property (set to true) to the asadmin redeploy command.

Example usage:

  asadmin redeploy --properties keepSessions=true --name myapp myapp.war

The GlassFish admin console also exposes this new feature, which has also been incorporated into the Deploy on change feature of Netbeans, which instantly redeploys a WAR- or EAR-based, directory-exploded application as soon as one of its class files or descriptors has changed. Both Netbeans and the GlassFish Plugin for Eclipse allow developers to enable this feature by clicking on the new Preserve Sessions Across Redeployment checkbox, which can be seen at the bottom of the snapshots taken for NetBeans and GlassFish Plugin for Eclipse.

Implementation details

Behind the scenes, any active sessions will no longer be destroyed during a redeployment if so requested by the user: Instead, they will be stored in memory in serialized form, and restored from memory and deserialized when the redeployment has completed.

If any of the active sessions of the application fail to be serialized or deserialized, a warning will be logged, and the redeployment will continue, but none of the sessions that were active prior to the redeployment will be available following the redeployment.

The new classloader of the redeployed application will be used to deserialize any sessions previously saved. The usual restrictions about serialization and deserilization apply. For example, any application specific classes referenced by a session attribute may evolve only in a backwards compatible way.


GlassFish v3 Prelude simplifies your development cycles and increases your productivity by allowing you to preserve any active HTTP sessions when you redeploy your applications.

Monday Sep 17, 2007

New Web Container Features in GlassFish V2

New Web Container Features in GlassFish V2

New Web Container Features in GlassFish V2

GlassFish V2 has been released today. Following is a short summary of the new web container features available in this release (please see Jeanfrancois Arcand's blog for new Grizzly related features in GlassFish V2, including support for Comet and HTTP compression):
  • Alternate docroots:

    Alternate docroots allow a virtual server or web application to use docroots other than the docroot assigned to them by the web container. Alternate docroots are configured with, and matched by, request URL patterns, similar to how requests are mapped to servlets. Alternate docroots may be configured either at the virtual server level or for individual web applications.

    One of the many use cases made possible by alternate docroots is the sharing of resources across multiple web applications, by storing these resources in alternate docroots instead of bundling them with each web application.

  • Dynamic reconfiguration:

    All aspects of the web container, including the creation and removal of HTTP listeners and virtual servers, as well as any changes to existing HTTP listeners and virtual servers, are now dynamically reconfigurable, meaning they no longer require any server restart in order to take effect.

  • In-memory compilation of JavaServer(TM) Pages (JSPs):

    The JSP compiler has taken advantage of the Java(TM) Compiler API, which has been standarized under JSR 199. This means that the compilation of the servlet derived from a JSP page may now be performed programmatically by invoking the Java Compiler API, instead of by running "javac" on a forked process. This also means that the generated .java and .class files no longer need to be written to, or read from, disk. Overall, this feature, which is available only when using a Java 6 based runtime, has improved the first-access response time of JSP pages dramatically. See Kin-Man Chung's blog for details.

  • In-memory replication of HTTP sessions:

    GlassFish V2 supports a new session persistence type called in-memory replication, which provides high availability and failover capabilities of HTTP sessions and stateful session beans in a cluster environment, without persisting the sessions to a database (as is the case with HADB). The web container has added versioning support to HTTP sessions, to allow the replication framework to detect a failover situation, identify stale session data, and fetch, either from its local replication cache or from another instance in the cluster, the most recent version of an HTTP session that would satisfy the client request.

  • Smoother migration support from Tomcat:

    In order to allow for a smoother migration from Tomcat, GlassFish V2 now detects and processes Tomcat's context.xml configuration files. See Amy Roh's blog for details.

  • Improved I18N support:

    GlassFish V2 has improved support for web applications with multi-byte requirements. For example, multi-byte request URLs are now supported out-of-the-box, by using UTF-8 (instead of ISO-8859-1) as the default URL decoding. Alternative decodings may now be specified through a configuration property at the http-service and http-listener levels in domain.xml. In addition, multi-byte context roots and RFC 3490 style, internationalized domain names are now supported.

  • Virtual server security realms:

    A virtual server may now be configured with its own security realm, avoiding the need for individual web applications deployed on the virtual server to specify their own: They simply inherit the security realm of the virtual server on which they have been deployed, but can still override it with their own (as specified in their deployment descriptor) if needed.

  • Self-contained Expression Language:

    The JSP 2.1 Specification (JSR 245) has undergone a Maintenance Release (MR) in an effort to take the Expression Language (EL) out of JSP 2.1 and turn it into a self-contained specification.

  • Support for pluggable network authentication modules:

    Glassfish V2 is the reference implementation for a new standard, the Authentication SPI for Containers (aka, JSR 196). This standard is a general purpose framework which extends the pluggable authentication model of JAAS to the authentication of network messages. Support by the Glassfish web container for the Servlet profile of the 196 standard exposes a simple contract by which implementations of network authentication mechanisms can be configured (in the field) for use by the Glassfish web container in its processing of security contraints on behalf of portable web applications. The JSR 196 standard is available on the jcp web site.

  • Various performance optimizations:

    We've improved performance at various levels, both during web container startup as well as during normal request processing.

    For example, all web modules are now started concurrently when the web container is brought up.

    In addition, a virtual server's default web module is no longer implemented as a separate web module (it used to be implemented as an exact copy of the web module that had been declared as the virtual server's default web module). Instead, we've enhanced the container's request mapping algorithm by making it default web module aware, so that any requests mapped to the virtual server's root context are now routed to the web module that is acting as the virtual server's default web module (if any default web module has been configured for the virtual server). This has improved the container's startup performance, since it reduces the number of web modules that need to be started. In some cases, as with the admingui (which acts as the default web module of the admin virtual server), the savings have been significant, since the admingui used to initialize the JavaServer Faces (JSF) runtime during its startup, meaning the JSF runtime used to be initialized twice during server startup - and initializing the JSF runtime is not cheap!

    We've not only avoided initializing the admingui's JSF runtime twice during startup, but we actually went one step further by deferring the initialization of the admingui's JSF runtime to the time when the first request for the admingui is received.

    See Prashanth Abbagani's blog for how (in numbers) each of the above optimizations has contributed to improving startup performance.

    We also improved the way the Servlet and JSP containers cooperate, by having the Servlet container pass information about a web application's Tag Library Descriptor (TLD) related mappings to the JSP container, so that the JSP container does not need to parse this information again.

    In addition, the JSP compiler now creates a JSP tag library instance only once per web application (so that it may be shared by all the JSP pages in the web application that import it via a taglib directive or namespace declaration), instead of once per translation unit, which has improved JSP performance and reduced memory footprint.




« April 2014