Make Google Ignore JSESSIONID

Search engines like Google will often index content with params like JSESSIONID and other session or conversation scope params. This causes two problems: first the links returned in the Google search results can have these parameters in them, resulting in “session not found” or other incompatible session state issues. Secondly it can cause a single page of content, to be indexed multiple times (with differing parameters) this diluting your page’s rank.

I’ve posted two solutions to this issue in the past: Using Apache to ReWrite URLs to remove JSESSIONID and a more advanced solution of using a Servlet Filter to avoid adding JSESSIONID for GoogleBot Requests.

Now there’s an even better way to handle this. Google has added an amazing new feature to their Webmaster Tools which allows you to specify how the GoogleBot indexer should handle various parameters. You can ignore certain parameters such as JSESSIONID, cid, and others, and also specifically not ignore other parameters such as productId, skuId, etc…

Log into your Google Webmaster Tools, and select the site you wish to work with. Under “Site Configuration” -> “Settings” there is a new section at the bottom called “Parameter handling”. Click on “adjust parameter settings” to expand the parameter handling configuration for your site. Sometimes Google will suggest various parameters it has discovered while crawling your site, and other times you just enter the parameters you want Google to ignore or pay attention to.

Google Webmaster Tools Parameter Handling Interface

This is a much more elegant solution to the JSESSIONID problem, and also allows you to easily handle other parameters your site may use for either session state or dynamic content generation correctly. The only downside is that this only impacts Google, whereas with the correct configuration my older two solutions can handle any Search Engine Bot. Maybe other search providers will or do provide a similar feature.

Seam 2.x Web Development

Seam 2.x Web Development by David Salter

Seam 2.x Web Development by David Salter

Packt Publishing just sent me a copy of their new Seam book entitled Seam 2.x Web Development. Authored by David Salter, it seems to be a well laid out practical guide to building web apps with Seam 2. I’ve only skimmed it so far, but will be posting an in-depth review once I’m able to read through it.

It’s great to have a book that covers the new features of Seam 2 and provides examples of common Web 2.0 requirements such as OpenID integration, AJAX/RIA interfaces, and multi-tabbed browsing support using conversation scoped components. Personally I’m interested in reading about the new(ish) Identity Manager API (which I haven’t played with yet) and trying to add OpenID support for the application I am currently building.

You can read the second chapter online here: Chapter 2: Developing Seam Applications and let me know what you think of it!

Environment specific mail auth and Seam’s MailSession

If you are using Seam’s MailSession to send out going e-mail from your Seam application you can run into trouble if you have a mail server in any environment (dev, test, stage, prod) that allows outgoing mail based on the client’s IP address and does not use username and password based authentication.

The standard configuration for the MailSession is in the components.xml file and looks like this (if you’ve used SeamGen to create your project):

	<mail:mail-session host="@mailhost@" port="@mailport@" username="@mailusername@" password="@mailpassword@" />

Then each of your environments has a components-{env}.properties file, which is deployed out and used to populate the @variable@ placeholders in the components.xml file. For instance your components.dev.properties file might look like this:

jndiPattern=YourApp/#{ejbName}/local
debug=true
mailhost=mail.mydomain.com
mailport=25
mailusername=mailus3r
mailpassword=mailp4ss

Which works great. However, if for instance your production environment uses IP based mail authentication for outbound e-mail, you might try to set your components-prod.properties file to look like this:

jndiPattern=YourApp/#{ejbName}/local
debug=false
mailhost=prodmail.mydomain.com
mailport=25
mailusername=
mailpassword=

However, that ends up setting empty strings into the username and password member variables of the MailSession component, and unfortunately the logic which determines whether or not to authenticate with the mail server checks for nulls only. So with empty strings, it attempts to authenticate with the mail server using a blank username and password. Which fails, and causes an unhelpful Faces error (unless you turn on debug on the MailSession component).

I’ve logged a Jira ticket about it here: JBSEAM-4176

You can do a simple workaround by overriding the MailSession component with your own sub-class of the MailSession class. In your sub-class you can override the setUsername and setPassword methods, check for empty strings and set null into the member variable if the parameter is null or empty. Luckily the Seam Install precedence system makes it very easy to override the default Seam component.

package com.myapp.mail;

import static org.jboss.seam.ScopeType.APPLICATION;

import org.jboss.seam.annotations.Install;
import org.jboss.seam.annotations.Name;
import org.jboss.seam.annotations.Scope;
import org.jboss.seam.annotations.intercept.BypassInterceptors;

/**
 * The Class MailSession. This is an overriding class designed to work around
 * https://jira.jboss.org/jira/browse/JBSEAM-4176
 */
@Name("org.jboss.seam.mail.mailSession")
@Install(precedence = org.jboss.seam.annotations.Install.APPLICATION, classDependencies = "javax.mail.Session")
@Scope(APPLICATION)
@BypassInterceptors
public class MailSession extends org.jboss.seam.mail.MailSession {

    @Override
    public void setPassword(String pPassword) {
	if (pPassword == null || pPassword.trim().length() == 0) {
	    super.setPassword(null);
	} else {
	    super.setPassword(pPassword);
	}
    }

    @Override
    public void setUsername(String pUsername) {
	if (pUsername == null || pUsername.trim().length() == 0) {
	    super.setUsername(null);
	} else {
	    super.setUsername(pUsername);
	}
    }

}

Make A Custom RichFaces Skin

Using RichFaces in your application makes it easy to build great rich interfaces without spending a ton of time writing custom JavaScript for the front end and the back-end support for the JavaScript calls. It ties into your JSF components easily and makes dynamic interaction easy to build. It also comes with a number of default skins which is great when you’re first starting to build out a new application because it gives it a nice polished look instead of just black and white unstyled elements.

However, once you you get your own site design in place, the RichFaces skins probably won’t match your design perfectly. You can always override any of the particular element styles using CSS, but if you want to quickly change the global look and feel for all the RichFaces components, the easiest thing to do is to create a customized RichFaces skin.

You should start with the RichFaces skin that most closely matches your design and build your custom skin based on that. The skins are defined in properties files in the RichFaces jar file under /META-INF/skins/. You can also just download them from here, to avoid having to unpack the jar file yourself: richfaces-skins.zip.

Copy the skin file that’s closest to your design into your project. If you’re using a Seam project created with seam-gen, you’re in luck because the ant build file is already setup to deploy RichFaces skins if you have them. Just drop the skinname.skin.properties file into the “resources” directory of your Seam project. Rename it to a custom name for your site’s skin, i.e. mysite.skin.properties.

Now you need to configure your application to use the new custom skin. Edit /resources/WEB-INF/web.xml, and change the org.richfaces.SKIN param to the name of your new skin:

   <context-param>
      <param-name>org.richfaces.SKIN</param-name>
      <param-value>mysite</param-value>
   </context-param>

Now you can edit the skin file to adjust the colors and look and feel of the skin to match your site’s design. The ant build file will automatically deploy the custom skin file into the war file.

There are also other ways to customize RichFaces and build custom skins including extending an existing skin, or using the new Plug-n-Skin feature, or using XCSS, etc… But this should get you started!

Setting Cache Headers from JBoss

Having control over the HTTP response headers allows you to set cache related headers in responses for various content you’d like cached on the browser (or an intermediary proxy). I created the ATG Cache Control DAS pipeline Servlet a year ago, but when you’re using JBoss you need another solution.

Since the DAF pipeline is only executed for JSPs the pipeline Servlet it doesn’t allow you to set headers for the static media items you’re more likely to want to cache. I created a Servlet Filter which allows you to set cache headers in JBoss based on URI patterns. It doesn’t allow the same fine grained control that the old pipeline Servlet does, but it should work for most situations.

Servlet Filters are very similar to ATG pipeline Servlets in that they are executed within the lifecycle of a request and can read the request and modify the response. The filter I created gets configured from the web.xml and sets the response headers relating to caching. You can configure different instances of the filter for each cache time you need, an hour, a day, or a week, and map different URL patterns to the appropriate instances.

I’ve added the filter into Foundation, the open source ATG e-commerce framework project, which is hosted at the Spark::red Development Community.

The Servlet filter code looks like this:

package org.foundation.servlet.filter;

import java.io.IOException;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Date;
import java.util.Locale;
import java.util.TimeZone;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;

/**
 * The Class CacheHeaderFilter.
 *
 * @author Devon Hillard
 */
public class CacheHeaderFilter implements Filter {

    /**
     * The Constant MILLISECONDS_IN_SECOND.
     */
    private static final int MILLISECONDS_IN_SECOND = 1000;

    /** The Constant POST_CHECK_VALUE. */
    private static final String POST_CHECK_VALUE = "post-check=";

    /** The Constant PRE_CHECK_VALUE. */
    private static final String PRE_CHECK_VALUE = "pre-check=";

    /** The Constant MAX_AGE_VALUE. */
    private static final String MAX_AGE_VALUE = "max-age=";

    /** The Constant ZERO_STRING_VALUE. */
    private static final String ZERO_STRING_VALUE = "0";

    /** The Constant NO_STORE_VALUE. */
    private static final String NO_STORE_VALUE = "no-store";

    /** The Constant NO_CACHE_VALUE. */
    private static final String NO_CACHE_VALUE = "no-cache";

    /** The Constant PRAGMA_HEADER. */
    private static final String PRAGMA_HEADER = "Pragma";

    /** The Constant CACHE_CONTROL_HEADER. */
    private static final String CACHE_CONTROL_HEADER = "Cache-Control";

    /** The Constant EXPIRES_HEADER. */
    private static final String EXPIRES_HEADER = "Expires";

    /** The Constant LAST_MODIFIED_HEADER. */
    private static final String LAST_MODIFIED_HEADER = "Last-Modified";

    /** The Constant CACHE_TIME_PARAM_NAME. */
    private static final String CACHE_TIME_PARAM_NAME = "CacheTime";

    /** The Static HTTP_DATE_FORMAT object. */
    private static final DateFormat HTTP_DATE_FORMAT = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z", Locale.US);

static {
HTTP_DATE_FORMAT.setTimeZone(TimeZone.getTimeZone("GMT"));
}

    /** The reply headers. */
    private String[][] mReplyHeaders = { {} };

    /** The cache time in seconds. */
    private Long mCacheTime = 0L;

    /**
     * Initializes the Servlet filter with the cache time and sets up the unchanging headers.
     *
     * @param pConfig the config
     *
     * @see javax.servlet.Filter#init(javax.servlet.FilterConfig)
     */
    public void init(final FilterConfig pConfig) {
        final ArrayList<String[]> newReplyHeaders = new ArrayList<String[]>();
        this.mCacheTime = Long.parseLong(pConfig.getInitParameter(CACHE_TIME_PARAM_NAME));
        if (this.mCacheTime > 0L) {
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, MAX_AGE_VALUE + this.mCacheTime.longValue() });
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, PRE_CHECK_VALUE + this.mCacheTime.longValue() });
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, POST_CHECK_VALUE + this.mCacheTime.longValue() });
        } else {
            newReplyHeaders.add(new String[] { PRAGMA_HEADER, NO_CACHE_VALUE });
            newReplyHeaders.add(new String[] { EXPIRES_HEADER, ZERO_STRING_VALUE });
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, NO_CACHE_VALUE });
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, NO_STORE_VALUE });
        }
        this.mReplyHeaders = new String[newReplyHeaders.size()][2];
        newReplyHeaders.toArray(this.mReplyHeaders);
    }

    /**
     * Do filter.
     *
     * @param pRequest the request
     * @param pResponse the response
     * @param pChain the chain
     *
     * @throws IOException Signals that an I/O exception has occurred.
     * @throws ServletException the servlet exception
     *
     * @see javax.servlet.Filter#doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse,
     *      javax.servlet.FilterChain)
     */
    public void doFilter(final ServletRequest pRequest, final ServletResponse pResponse, final FilterChain pChain)
            throws IOException, ServletException {
        // Apply the headers
        final HttpServletResponse httpResponse = (HttpServletResponse) pResponse;
        for (final String[] replyHeader : this.mReplyHeaders) {
            final String name = replyHeader[0];
            final String value = replyHeader[1];
            httpResponse.addHeader(name, value);
        }
        if (this.mCacheTime > 0L) {
            final long now = System.currentTimeMillis();
             final DateFormat httpDateFormat = (DateFormat) HTTP_DATE_FORMAT.clone();
            httpResponse.addHeader(LAST_MODIFIED_HEADER, httpDateFormat.format(new Date(now)));
            httpResponse.addHeader(EXPIRES_HEADER, httpDateFormat.format(new Date(now
                    + (this.mCacheTime.longValue() * MILLISECONDS_IN_SECOND))));
        }
        pChain.doFilter(pRequest, pResponse);
    }

    /**
     * Destroy all humans!
     *
     * @see javax.servlet.Filter#destroy()
     */
    public void destroy() {
    }

}

And the web.xml configuration looks like this:

	<filter>
		<filter-name>CacheFilterOneWeek</filter-name>
		<filter-class>org.foundation.servlet.filter.CacheHeaderFilter</filter-class>
		<init-param>
			<param-name>CacheTime</param-name>
			<param-value>604800</param-value>
		</init-param>
	</filter>

	<filter>
		<filter-name>CacheFilterOneDay</filter-name>
		<filter-class>org.foundation.servlet.filter.CacheHeaderFilter</filter-class>
		<init-param>
			<param-name>CacheTime</param-name>
			<param-value>86400</param-value>
		</init-param>
	</filter>

	<filter>
		<filter-name>CacheFilterOneHour</filter-name>
		<filter-class>org.foundation.servlet.filter.CacheHeaderFilter</filter-class>
		<init-param>
			<param-name>CacheTime</param-name>
			<param-value>3600</param-value>
		</init-param>
	</filter>

.......

<filter-mapping>
		<filter-name>CacheFilterOneDay</filter-name>
		<url-pattern>*.js</url-pattern>
	</filter-mapping>
	<filter-mapping>
		<filter-name>CacheFilterOneDay</filter-name>
		<url-pattern>*.css</url-pattern>
	</filter-mapping>
	<filter-mapping>
		<filter-name>CacheFilterOneWeek</filter-name>
		<url-pattern>*.jpg</url-pattern>
	</filter-mapping>
	<filter-mapping>
		<filter-name>CacheFilterOneWeek</filter-name>
		<url-pattern>*.gif</url-pattern>
	</filter-mapping>