Apache

Rich Bowen – We’ve Always Done It That Way:

Principle 13 in the Toyota Way says that one should make decisions slowly, by consensus, thoroughly considering all options, and then implement those decisions rapidly. We believe a similar thing at the ASF. So to people who have only been around for a short time, it looks like we never change anything. But the truth is that we change things slowly, because what we’re doing works, and we need to be sure that change is warranted, and is a good idea.

I was quite pleased to see Odi’s post this morning stating that the NTLM code in HttpClient (now HttpComponents) has finally been replaced with a more robust and compatible version that supports the more modern NTLM variants. Many years ago that NTLM code was my first contribution to someone else’s open source project and it lead on to me writing a bunch of documentation and becoming an Apache committer. In turn, that’s put me in touch with a whole heap of incredibly smart people.

The conversation that has sprung up around how the use of distributed version control, Github in particular, affects community is a refreshing change in the blogosphere1. It’s people collectively thinking things through rather than just reacting in uproar or following the latest meme.

The latest installment is from Ben Hyde, git: Balene for Knowledge2. It’s definitely worth reading in its entirety, but let me pull out a couple of key points:

After my amazingly successful use of mod_proxy to provide clean URLs in an IWWCM instance, it’s been added to my bag of useful tricks to know about.  When you realize you can proxy differently based on the current virtual host it’s a very powerful solution.

My latest use for it was to add name based virtual host support to two completely separate virtual machines.  One machine runs IBM WCM and the other runs Quickr. Both use the same port, and in the future there will be more VMs with different versions as well, so while it would be possible to assign different port numbers, I’d prefer to not have to remember which VM is using which port etc.  The firewall however can only forward connections on a given port to one VM.

If you’re using the scp or ssh tasks with ant, you may run into a problem where part way during the upload or never disconnecting after the command completes for the ssh task. There are a couple of possible causes:

1. The scp problem is almost certainly caused by using ant 1.7.0 or below and jsch 0.1.30 or above. You could upgrade to the latest nightly of ant1 but it’s probably easier to just drop back to jsch 0.1.29 which is what ant was developed against and works nicely. Bug 41090 contains the gory details.
2. If the command you’re executing with the ssh task starts a background service or otherwise leaves a process running, that may be the cause of the problem. You can add ‘shopt -s huponexit’ to your /etc/profile, .bashrc or somewhere like that. I must admit, I’m somewhat vague on the exact details of what that does but the basic idea seems to be to signal any background processes that bash is exiting and then not wait for them to complete (which allows your ssh connection to close). If you’re starting a server they’ll probably ignore the hup signal it sends and if not, use the nohup command.

Hopefully that will be the last I’ll see of that issue.

I’ve struggled with Lucene before and failed to configure it properly resulting in absolutely horrendous search results so a recent need to implement search functionality wasn’t something I particularly wanted to take on. In fact, I was prepared to do almost anything to avoid delving back into Lucene filters and parsers and tokenizers and “stuff”. This tends to be problematic given that Lucene is the dominate search library – so popular in fact that it’s been ported to other languages.

I’ve just spent the past three or four hours setting up Apache, Subversion, all my browsers etc etc to use SSL connections and client certificates for authentication with my Debian stable server. I’m sure the mod_ssl devs already know what’s coming here and are either chuckling gleefully or ripping their hair out right now. Anyway, the joke for all those who are mod_ssl devs, is that you can’t get subversion to use client certificates with a Debian stable server because Debian stable has Apache 2.0.54, complete with everybody’s favorite mod_ssl bug. It’s fixed in Apache 2.2, but not in 2.0.

(I wrote this Thursday night but didn’t have net access on the train to post it) I finally managed to catch up with a number of Apache people tonight at the Thirsty Bear (rest assured the bear is not quite as thirsty after our beer drinking efforts). Afterwards we picked up the two new IBM servers that have been sitting at Collab.Net and deposited them into the cage at the colo facility. Since I’m not a server guy at all this is one of very few times I’ve been in a server room and the first chance I’ve had to see the Apache server setup (there’s now another colo in Europe somewhere I believe). It’s pretty small and simple but seems to do the job quite well which is what really matters. Apparently the Technorati servers are in the same colo and they look a heck of a lot more impressive with a few racks full of servers and cables going everywhere. Either way it was great to finally meet a few Apache developers and put some faces to names. My description of myself as “the tall redhead” seemed to be effective as people walked straight in the door and introduced themselves to me. Sometimes it pays to stand out a bit I guess.

It appears that my back to back rants pretty much completely took over Planet Apache the other day. er, sorry about that… I’ll try to use my “extended entry” box a little more in future…

Apparently, the ASF took delivery of a few new machines today. I just can’t get the image of Sam Ruby sitting around ASF head office and suddenly there’s a knock on the door and he finds a pile of orphaned servers wrapped in a blanket. Then again, I always was weird…

The vote to start the motion of HttpClient out of jakarta-commons to become a fully fledged Jakarta sub-project has been declared passed. I’ve just done up an initial draft of the proposal that will need to be put to the Jakarta PMC to approve the move (they noted that it was coming and that it was most likely to pass at the meeting they just recently had). This is the first bit of Apache “politics” I’ve been involved in so I’ll be interested in the feedback. I’m just not sure if it’s considered politics when everyone agrees as they seem to do so often on the HttpClient list. It’s good to have a team that’s working so well together.

At long last, HttpClient 2.0 has been released. It’s been a lot of hard work from a few almost completely distinct teams of developers (with only small contributions from myself if you’re wondering). I was originally hoping that HttpClient 2.0 would make it out in time to be used in EditLive! for Java 2.0 we actually released EditLive! for Java 3.0 a couple of weeks ago and it’s too late even to make it into the upcoming EditLive! for XML release. On the plus side, the CVS snapshot version we’ve been using for the past year or so has been running perfectly without any customers running into problems. There is to be a toast raised to HttpClient 2.0 at the Nelson in Zurich and at P J O’Briens in Brisbane Australia. Company at the Australian toast is particularly required since I believe I’m the only HttpClient developer from Brisbane.