sleepydisco » Programming

Documenting HttpServletRequest

David — Sun, 20 Dec 2009 14:27:29 +0000

For such a core object the HttpServletRequest javadoc is a little lacking in the Examples Dept. when it comes to documented output. With various methods returning various parts of URLs, it’s often easy to pick the wrong one, so I thought I’d knock up a little table with the getters which trip me up sometimes.

This assumes a simple webapp, living on a server on the local machine, sitting under the context called ‘context’, responding to the URL:

http://localhost:8080/context/hello/world?foo=bar

Method	Response	Notes
getContextPath()	/context	The context part of the URL. Should be obvious.
getPathInfo()	/hello/world	The part of the URL after the context, but not including the query string.
getPathTranslated()	/Users/david/projects/java/hello-world-webapp/target/context/hello/world	Hrm. Sort of where this would be on the local filesystem, but not really.
getProtocol()	HTTP/1.1	This doesn’t produce anything verbatum from the URL, such as ‘http’ or ‘https’ or ‘ftp’ or…
getQueryString()	foo=bar	Like it says, the query string.
getRequestURI()	/context/hello/world	Everything from but not including the port, up to but not including the query string.
getRequestURL()	http://localhost:8080/context/hello/world	This is a StringBuffer object, containing everything but the query string.
getServerName()	localhost	The server name as presented in the URL, not the hostname of the box.
getServerPort()	8080	As expected. Good, good.
getServletPath()		This is the path that the servlet is configured (e.g. in web.xml) to respond to relative to the context. It’ll be an empty-string if, as here, this is in response to a wildcard mapping “/*”.

URL connection timeouts… not timing out

David — Tue, 14 Apr 2009 21:48:17 +0000

After much fussing about, I’ve found out that the default UrlConnection object in the core Java libraries doesn’t correctly obey connect or read timeouts set via the setConnectTimeout() or setReadTimeout() methods. The only way I’ve managed to get this to work, is to add the following arguments to the JVM.

-Dsun.net.client.defaultConnectTimeout=
-Dsun.net.client.defaultReadTimeout=

In future, I’d be more inclined to use something like the Apache HttpCommons Client which provides a full-featured HTTP client.

Excluding log4j dependencies

David — Mon, 02 Feb 2009 23:22:13 +0000

While it’s noted in a few other places that there can be issues with the small world of unnecessary transient Sun dependencies that log4j pulls in to a Maven 2 project, and that the easiest thing is to exclude them; I thought I’d get it down here too, as trouble has again come a knocking at my door with this particular hat on.


    log4j
    log4j
    1.2.15
    false
    
        
            com.sun.jdmk
            jmxtools
        
        
            com.sun.jmx
            jmxri
        
        
            javax.jms
            jms

Evaluating Feeds

David — Mon, 02 Feb 2009 21:05:29 +0000

A not so uncommon situation I’m finding is that a website will have more than one feed associated with it. This is sometimes just to point to alternative markup (e.g. different versions of RSS spec, or a site offering both RSS and Atom feeds, or combinations thereof), or to hook up with feed aggregation services (Feedburner easily being the most prevalent), but the content of the feed can also sometimes be quite different.

Initially, I had made the crude assumption that for me, RSS is more useful than Atom (as I had written a very lightweight RSS parser). Now that I’m incorporating the ROME Java API for feed processing, I’m not so bothered about the choice of tech, or the spec of that tech, but I am quite interested in hooking up with the best feed for my purposes. I also don’t want to have to approve a few hundred feeds manually.

So what’s the best feed for my purposes? Assuming that these feeds are concerning the same subjects (i.e. new posts to the blog), then the best purpose feed is most likely going to be the one with the most content.

A really simple algorithm for deriving the feed with the most content

The first task is to pre-process the content of each feed to determine a value for the content of each post of each feed, measured by the number of words in the description and the largest number of words in each representation of the post content, once all markup has been removed.

We’re then left with a representation of feeds to lists of word counts for relative posts, such as:

feed_1..n → { words_post1, words_post2, .. words_{post_x} }

Since the number of posts in each feed could vary (and the number of posts a feed covers shouldn’t be a discriminating factor), we take the minimum length of all the word count lists, and sum the word counts within that range for each feed. We can then select the feed which has the highest word count as the preferred feed to use.

This method assumes that the feed entries are in the same order and about the same posts in each feed, on the basis that each feed is most likely to originate from the same blog management system and therefore either dynamically produced, or published at a similar time.