Technical Beef -

Imagine you're developping a web site that manages subdomains for your users, in such a way that all your users automatically get a http://user1.example.com or http://user2.example.com subdomain.

In order to keep the normal session available on all the subdomains, one just needs to make the session cookie associated to the smallest common domain, in this exemple, the example.com domain, so that www.example.com share the same cookie with all the other http://[whatever].example.com subdomains. Piece of cake: cookie.setDomain("example.com"), right? Almost. Just, not in a servlet container. Because, you can't.

It's amazing, but in a servlet container, you just can't tell which domain the JSESSIONID cookie is associated to. Unfortunately, Tomcat provides no container-specific way to modify this behaviour.

So, here's a simple patch that fixes the issue. It's not suited for all purpose, it just removes any www prefix that appears in the hostname, and use it as cookie domain. If there's no www prefix, the normal behaviour applies.

In apache-tomcat-6.0.18-src/java/org/apache/catalina/connector/Request.java, find the configureSessionCookie() method, and replace it with this one:

    /**
     * Configures the given JSESSIONID cookie.
     *
     * @param cookie The JSESSIONID cookie to be configured
     */
    protected void configureSessionCookie(Cookie cookie) {
        cookie.setMaxAge(-1);
        String contextPath = null;
        if (!connector.getEmptySessionPath() && (getContext() != null)) {
            contextPath = getContext().getEncodedPath();
        }
        if ((contextPath != null) && (contextPath.length() > 0)) {
            cookie.setPath(contextPath);
        } else {
            cookie.setPath("/");
        }
        if (isSecure()) {
            cookie.setSecure(true);
        }

        // CHANGES BELOW
	String domain = this.getServerName();
	if (domain != null)
	    {
		if (domain.toLowerCase().startsWith("www."))
		    domain = domain.substring(4);
		
		cookie.setDomain(domain);
	    }

    }

Now compile (with a JDK 1.5... as of Tomcat 6.0.18 you can't compile it with JDK1.6 because of a DBCP issue), and use this distribution. Or just grab the catalina.jar.

Not that I'm much into Windows development, but I've personnally always preferred using the Microsoft CHM format rather than plain HTML. It's compact, it's fast to open, and pretty fast to search for a specific class or method.

I took some time this morning to generate the Wicket javadocs WITHOUT the examples packages (I can't see why they are included in the default javadocs, it's just annoying to have them mixed with the Wicket API), and the corresponding CHM file using the jd2chm javadocs-to-chm converter. This program works amazingly well.

For those interested, I generated two flavours of the wicket-javadocs:

• Wicket 1.4rc4 CHM (standard version, 7.76Mb)
• Wicket 1.4rc4 CHM with the linksource option (12.5Mb)

• Wicket 1.4rc2 CHM (standard version, 7.76Mb)
• Wicket 1.4rc2 CHM with the linksource option (12.5Mb)

The linksource option provides a link between a method and its java source code, which makes it a breeze to check what the code does under the water (and that's utterly useful when the documentation of some method is not available).

Other adjustments I've made to the javadocs:

• The Java API classes link to the online JDK1.6 javadocs
• I've separated the core wicket packages and other extension packages that are bundled in a different jar, so that they appear in different groups

A quick post just to share a country list model I did a few days ago. It's no big deal, but I think it's worth sharing to avoid my fellow wicketeers the trouble to do it.

So, it's a standard Wicket Model that uses a standard ISO-3166-1 (2-char long) code to store the country name. The idea is to keep simplicity in my domain object, so the country property is just a String that stores the ISO3166 code. As it's not easily possible to use this ISO3166 code directly in a Wicket DropDownChoice (I want to display a localized country full name, but store the ISO-3166 short code), I had to create a Country object, which is internally used. Note however that the CountryList class provides an adaptor that converts this internally-used Country object into the property string of my domain POJO, so it's transparent.

The country list is localized, and comes from the ISO files I found at http://www.iso.org/iso/country_codes/iso_3166_code_lists.htm. Unfortunately, the ISO organization only provides english and french locales from the country name, so if you want more, you'll have to translate them yourselves and add the resource file to the jar.

Actually, using it is pretty straightforward, so I'll just show how to use it in an example.

The HTML is, as expected, the standard:

<select wicket:id="country">
 <option value="US">United States</option>
 <option value="FR">France</option>
</select> 

The java code instanciates a country list, and uses it as a model for the DropDownChoice element (although it can be used with any component that uses an IModel<List> ).

CountryList countrylist = new CountryList(); // (1)
DropDownChoice country = new DropDownChoice("country", 
		    countrylist.getAdaptor(new PropertyModel(this.obj, "country")), // (2)
		    countrylist, // (3)
		    countrylist.getRenderer()); // (4)
form.add(country);

in (1), we instantiate the CountryList class using the default constructor, which uses the Wicket Session locale. It is also possible to pass a Locale object to the constructor.

in (2), we use the adaptor provided by the CountryList class: this is a very basic IModel<Country> that takes a IModel<String> as its own model to set and get the correct Country element. This allows our POJO to just use a String property, instead of dealing with an annoying Country object.

in (3), this is actually the list of countries itself

in (4), this is the ChoiceRenderer that displays the full country names, instead of the short code.

Download

• The full project (includes the jar binary and an example): Wountry-1.0.zip (100Kb)
  (NOTE: oooops, the file HomePage.java from the example was wrong, please download again if you got the first version of the archive)
• The jar binary only: wountry-1.0.jar (10Kb)

In hosted mode, GWT redirects all the logging calls made with commons-logging to its own "TreeLogger", so that any useful logs emitted server-side are redirected to it (and most likely lost). Not only is this annoying, it also breaks the expected consistency with the normal deployment state.

Technically, the GWT makes a System.setProperty("org.apache.commons.logging.Log", adapterClassName) call. Fortunately, the apache commons logging library preempts this setting with its own configuration file.

Just create a file called "commons-logging.properties" at the root of your classpath, and add the following line:

[to use the Log4j backend]

org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger

[to use the JDK14 backend]

org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger

[to use the SimpleLog backend]

org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog

etc. well, you got it.

(OK, the title of this article is misleading, we're not really asking the GWT to not redirect, but rather asking commons-logging to ignore the GWT request)

I just finished reading an article comparing GWT-EXT and EXT-GWT, it was a few minutes ago, and now I can't even remember which is which. I don't know which was created first, and really I don't care, but there's something obvious that should cross the mind of anyone: when there's already a project called X-Y, don't call yours Y-X. That's utterly lame.

I don't know who exactly, but someone out there is a total moron. Or totally lacks imagination. Or both.