Documenting HttpServletRequest

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. Read the rest of this entry »

URL connection timeouts… not timing out

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. Read the rest of this entry »

Excluding log4j dependencies

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.

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.15</version>
    <optional>false</optional>
    <exclusions>
        <exclusion>
            <groupId>com.sun.jdmk</groupId>
            <artifactId>jmxtools</artifactId>
        </exclusion>
        <exclusion>
            <groupId>com.sun.jmx</groupId>
            <artifactId>jmxri</artifactId>
        </exclusion>
        <exclusion>
            <groupId>javax.jms</groupId>
            <artifactId>jms</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Evaluating Feeds

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_postx }

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.