Deft Code

Regex Coach

Well, this is just cool: The Regex Coach - interactive regular expressions. For bonus geek points, it’s written in Lisp.

Bash Line Wrapping

One of the “nice” things about being any sort of unix weenie is the constant opportunity to learn one line config file entries that could have saved many months or years of irritation. Today’s case in point: fixing bash line wrapping in console windows, a very handy tip posted to a gentoo mailing list.

Also handy is this document, on working more productively with bash.

It’s funny, basically I’ve come to the conclusion I just want all the shells I have to deal with on a regular basis (bash, tcsh, and zsh mostly) to work exactly the same for things I do a lot. Things like the advanced completion ability available in bash and zsh are nice, but not necessary.

unix weenies unite!

In an otherwise excellent-as-usual article on craftsmanship, Joel indulges in a bit of unix-weenie bashing:

And of course, a certain type of programmer will argue that my new child-process architecture is inferior to the original. It’s “bloated” (because of all the extra lines of code). It has more potential for bugs, because of all the extra lines of code. It’s overkill. It’s somehow emblematic of why Windows is an inferior operating system, they will say. What’s all this about progress indicators? they sneer. Just hit Ctrl+Z and then “ls -l” repeatedly and watch to see if the file size is growing!

I’m sure there is a ‘certain type of programmer’ that would say such things about an end-user GUI program. They’re idiots, and they ‘program’ on all platforms. I guess there’s also a certain type of software pundit that finds imaginary strawman counter-arguments a good way to make their arguments more persuasive.

tomcat reloads

Consider this entry a bit of a bitch session about tomcat; I may update it later if I can get clarification about the complaint herein. On with the bitchin’:

For a while now, I’ve been trying to track down a problem with Tomcat reloading applications in production. Even though we have everything explicitly set to false in terms of reloads, whenever applications are live deployed, they are reloaded. When you’re making major changes to an application, this basically breaks the application until tomcat restarts or is reloaded via the manager.

Now, part of the problem is that we’re actually unpacking the application, not just putting a war file live; this is probably Not The Way To Do It, but there are good reasons for doing it this way. (That I can’t recall what they are at the moment in no way means they don’t exist.) What’s also weird is that there is nothing in the logs as to why the application was being reloaded (with the regular tomcat class reloading, you get a log entry saying foo.class was modified, etc.). Today while working on this, I finally noticed the crucial problem: reloads only happen when web.xml is modified. This gave me enough information to dig through the tomcat source and find the culprit, which is the method checkWebXmlLastModified() in the class HostConfig. (source here.)

Now, a few things about this:

1. there is, as far as I can tell, no way to turn it off via the config


2. the method is hideously named, as it doesn’t just check, it has the minor side effect of reloading the entire application


3. it completely swallows any errors


4. it does absolutely no logging

Other than that, I don’t have any problems with it.

Anyway, I’m going to dig through the changes in CVS; the original changelog for this indicates that it should respect the reload attribute, but the current source doesn’t.

Further updates as events warrant.

UPDATE: Ok, I think I’ve cracked this, looking through the cvs messages we see this:

- Do web.xml tracking on all contexts if liveDeploy is true (as it has an extremely
small performance impact).

We didn’t have liveDeploy in our server config, and it defaults to true, so… we get the unintuitive (to me) result that all our applications are reloaded when web.xml changes, even if reloadable is set to false. Personally, I think this behavior is somewhat confusing and is not well documented (or, at least, I didn’t come across the right documentation). I’ll read through the documentation this evening and perhaps submit a bug suggesting either a documentation change or a code change.

Further Update: response on tomcat-user:

Historically, only reloadable was being done. This caused a lot of questions as to why changes in web.xml were not being picked up. As some refactorings came, it became easier to perform a stop, then start on the webapp instead of classloader reload.

So that, I guess, is that. I think I’ve managed to volunteer myself for making the documentation match the code, too.