humandoing software

…sure aren’t what they used to be.

I can’t remember exactly when it was that these photos of Bill Gates (Teen Beat magazine, circa 1983) started popping up online, I think it was early last year. They’re certainly a far cry from the latest shots of David Heinemeier Hansson in Wired magazine.

I guess in 2006, it’s chic to be geek (well, maybe it has been for the past couple years). Who’d a thunk?

Take a peak in this file:

/etc/ssh/sshd_config

and change the port number to whatever seems reasonable to you (and probably a port that’s not currently in use is a good idea).

After that, restart sshd:

/etc/init.d/ssh restart

You should now be able to log in using the new port number.

Note: There is an updated version of this article for Ubuntu 6.10 here

Wanting to finally put these stupid SATA disks to good use, I managed to get them thrown into a RAID-1 configuration on my happy Ubuntu install.

Just thought I’d share how I did it, and the resources I used. Standard disclaimer applies: If you follow these instructions, and you lose all your data, or the world explodes, or the sky starts falling, or you die, I’m not liable.
Here are the resources I used.

Go to Disks Manager to figure out the Devices that you want to actually make into a RAID, for me that was /dev/sda and /dev/sdb. These are 2×160GB Seagate SATA disks attached to a Promise FastTrak 378 controller on an Asus A8V Deluxe motherboard.

So now you need to create the partitions that you want to use as a RAID.

daniel@ubuntu:~$ sudo cfdisk /dev/sda
daniel@ubuntu:~$ sudo cfdisk /dev/sdb

I made mine Primary Partitions (not sure if this is good, bad, or if it matters at all), and you NEED to make the filesystems of type Linux Raid Autodetect (FD).

After that, i loaded the RAID module for RAID-1 (Mirror) because that’s the type of RAID I wanted to build:

daniel@ubuntu:~$ sudo modprobe raid1

After this, I restarted the Disks Manager to see what the partitions had been called on my disks. I selected the disk on the left, and took a look at the partition tab on the right, noticing that one of my disk partitions was /dev/sda1 and the other was /dev/sdb1.

Now we can run mdadm:

daniel@ubuntu:~$ sudo mdadm —create /dev/md0 —level=1 —raid-devices=2 /dev/sda1 /dev/sdb1

Now let’s take a look at the status of the disks as they are rebuilding the RAID:

daniel@ubuntu:~$ sudo cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      156288256 blocks [2/2] [UU]
      [>....................]  resync =  0.9% (1459904/156288256) finish=54.7min speed=47093K/sec
unused devices: 
daniel@ubuntu:~$

So, 54.7 minutes left for the disks to finish the sync [start twiddling thumbs].

You can get some information about the partition by going like so:

daniel@ubuntu:~$ sudo mdadm —misc —detail /dev/md0

So, once it finished, let’s make a file system. I’m going to use ext3, but you go ahead and use whatever you like, so we go:

daniel@ubuntu:~$ sudo mkfs.ext3 /dev/md0

And once it finished, we should (technically) have a nice pretty file system. But now we have to mount it. I want to mount mine in a /backup directory, because I’m going to be using this RAID for backups.

So here we go:

daniel@ubuntu:~$ sudo mkdir /backup
daniel@ubuntu:~$ sudo mount /dev/md0 /backup

Now, technically, we should have nearly 160GB of yummy RAID1 love available to us in the /backup directory. Let’s run df and see what it tells us:

daniel@ubuntu:/backup$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2             35064712   5173932  28109576  16% /
tmpfs                  1026508         0   1026508   0% /dev/shm
tmpfs                  1026508     13536   1012972   2% /lib/modules/2.6.12-10-amd64-generic/volatile
/dev/sdc1            199093056 136388704  62704352  69% /media/EXTERNAL
/dev/md0             153834788    131228 145889148   1% /backup

Excellent, /dev/md0 is mounted at /backup, and we’ve got lots of backup space.

In order to get this thing to mount each time we boot, we’ll want to put it into our /etc/fstab file. Let’s do that now.

I added a line like this to my /etc/fstab:

/dev/md0        /backup         ext3    defaults,errors=remount-ro      0       2

I’m not a super-linux-ninja, but I was able to figure out what I wanted to do here by reading the man page for fstab, and by looking at the other entries in the file. So run “man fstab” and then you can edit the fstab file (by using something like “sudo vi /etc/fstab” once you’re feeling like you’re comfortable with what to add there).

Ok, that’s going to be the last entry for a while, I’m heading to New Zealand tomorrow, and won’t be back for three weeks. I also haven’t rebooted my machine yet to see if that /etc/fstab change worked, so lets hope I didn’t mess something up.

After migrating some of my old blog entries and site content from the ‘old’ humandoing.net over to this happy new TextPattern install, I’ve moved my site from RimuHosting to my new TextDrive account.

That’s not to say I’m finished with RimuHosting, on the contrary, I hope to avail myself of their services for many years to come. In all my days I have never seen better support than that which comes from this small company in New Zealand.

Hopefully I’ll remain happy with TextPattern for a while, as I’m a bit tired of constantly moving my stuff around. As it stands, I’m losing about a hundred or so blog entries from my old Blojsom install that I just couldn’t be bothered to (nor did I have the time) migrate. I think I’ll be able to much better manage my stuff here, and hopefully come up with some at least vaguely interesting articles, blog entries and the like that will hopefully be read by at least 5 or so people.

Also maybe called OpenSessionInView, or more specifically: “that hibernate stuff so that lazy loading doesn’t die in your views when you’re using Spring”, or a bunch of other things.

I’ve jumped headlong back into the Java world and am mucking with Java 5 annotations at at long last, only because I really wanted to play with Hibernate Annotations. I think that the only reason I’ve stayed away from Hibernate for so long (as in, years) is because of the arrogance of certain Hibernate / JBossian types (names not need be mentioned, you know who I’m talking about). But alas, I’ve come to the point where I don’t really care about their arrogance anymore, I just want to be more productive. I could try the TopLink community edition associated with the GlassFish project instead, but that’ll have to wait.

But back to the whole point of this post. I was having a pain in the neck of a time dealing with getting my Hibernate objects to Lazy Load in views and unit tests – because using the HibernateTemplate in Spring (depending on how you set up your transactions, etc.) basically closes the Hibernate session before your view or your unit tests get a chance to access and analyze the data, leaving you with nothing but big fat Lazy Loading Exceptions.

What you want to do if you’re having these kinds of problems is take a look at org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor (or there is a Filter alternative that you can toss in your web.xml).

This should get you started at least:

  <bean id="openSessionInView" class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">
    <property name="sessionFactory"><ref bean="sessionFactory"/></property>
  </bean>

Then you need to tell your URL handler mapping to be intercepted:

  <bean id="urlMappings" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="interceptors">
      <list>
        <ref bean="openSessionInView"/>
      </list>
    </property>
    <property name="mappings">
      <props>
        <prop key="/public/**/*">publicController</prop>
        <prop key="/login">loginController</prop>
    ...
      </props>
    </property>
  </bean>

Now – there is a different strategy for getting the session to remain open in unit tests (I’m using TestNG, but maybe you’re using JUnit, either way it doesn’t matter). I was able to find a great blog entry courtesy of Karl Baum about how to get that set up here.

It’s been a really long time since I’ve blogged anything, I’ve been so busy working, coding and doing, um, ‘stuff’. Hopefully this is the start of my foray back into more regular entries.

…and (why || how) they can be your friend.

Useless Preamble

As previously mentioned, I’ve been using Spring a whole lot in the ‘latest project’, and in addition am using Acegi Security to provide authentication and authorization services.

Scenario

Now that all that is out of the way, I, like most other people who write webapps, wanted a way to display the currently logged in users information on the screen for them. You know, username, maybe a “Hello, $USERNAME! Thanks for coming out!” type nonsense. So in Acegi, the code used to get the currently logged in user looks like this:

Authentication auth = SecurityContextHolder.getContext().getAuthentication();

Once you’ve got the Authentication object, you need to get the Principal, which will at last be castable into whatever your User object implementation happens to be. So basically for me, I had a getUser() method that looks like this:

    protected User getUser(){
        Authentication auth = SecurityContextHolder.getContext().getAuthentication();
        if ( auth != null && auth.getPrincipal() instanceof User ){
            return (User) auth.getPrincipal();
        } else {
            return null;
        }

The Problem

Now, this is all well and good, and in Spring, chances are you want to add this code to a Controller implementation somewhere. But which Controller? I’ve got a ton of them. I thought of extracting it to some superclass, but based on the Spring controller hierarchy, whereby sometimes you might extend AbstractController, or SimpleFormController, or implement the Controller interface directly, it didn’t seem like this was going to cut the cake, so to speak. We don’t have multiple inheritance in Java (duh!), so I couldn’t do that, and I certainly didn’t feel like putting the code in some separate bean that I would have to inject into every single one of my controllers. Oh what to do?

The Solution

Enter interceptors. Oh how we love thee (when they’re the appropriate tool for the job).

So, an interceptor basically does exactly what it says it does. It “intercepts” method calls to an object. For all the details, go read something about AOP, this is just going to be an example in somewhat plain English.

In my particular case, I wanted to “intercept” all calls to the handleRequest(...) methods of the org.springframework.web.servlet.mvc.Controller interface (which all Spring controllers implement). If I could do that, then any time a method was intercepted, I could simply call my neat little getUser() method and dump the user into the current HttpServletRequest as an attribute. Spot on!1

So um, how the heck to we actually do it? Ok, first of all, let’s write the actual interceptor class. This is the class that we want to be automagically called any time the handleRequest(...) method of a Controller is executed (I’ve gotten rid of comments and imports).

public class AddUserToModelInterceptor implements MethodInterceptor {    public Object invoke( MethodInvocation methodInvocation ) throws Throwable {
        ModelAndView model = (ModelAndView) methodInvocation.proceed();
        if ( model != null && getUser() != null ){
            model.addObject( "user", getUser() );
        }
        return model;
    }    protected User getUser(){
        Authentication auth = SecurityContextHolder.getContext().getAuthentication();
        if ( auth != null && auth.getPrincipal() instanceof User ){
            return (User) auth.getPrincipal();
        } else {
            return null;
        }
    }
}

Note that the fully qualified class name (in case you’re curious) of MethodInterceptor is org.aopalliance.intercept.MethodInterceptor

Great, so we have an interceptor, now what? Lets go define some beans!

  <bean id="addUserToModelInterceptor" 
        class="com.example.AddUserToModelInterceptor"/>  <bean id="controllerClassFilter" class="com.example.ControllerClassFilter"/>  <bean id="controllerPointCutAdvisor" class="org.springframework.aop.support.NameMatchMethodPointcutAdvisor">
    <property name="classFilter" ref="controllerClassFilter"/>
    <property name="advice" ref="addUserToModelInterceptor"/>
    <property name="mappedName" value="handleRequest"/>
  </bean>  <bean id="autoProxyCreator" class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>

Alright, the first bean definition is just an instance of the AddUserToModelInterceptor that we just finished showing in the above example. After that, we have a class filter (which we’ll look at in a second). Thirdly there is the bean controllerPointCutAdvisors. Joins, Pointcuts and Advice are fancy AOP terminology that you should really read about, but I won’t cover here. We pass three simple properties to this bean. The first is just the class filter, the second is the “Advice” which is a reference to our interceptor bean, and lastly, we pass “mappedName” – which is simply the method name that we would like to intercept calls to, in our case, “handleRequest”. Lastly, we define a proxy creator bean, which in this case is an instance of Spring’s DefaultAdvisorAutoProxyCreator. Basically, what this bean does is once all of the bean definitions have been loaded, it scours all loaded beans applying advice to matching pointcuts. In our case, it will apply our “addUserToModelInterceptor” advice to all bean instances that match our “classFilter” that have the method name “handleRequest”.

Briefly, the class filter is just a dead simple interface that Spring offers. In essence, we don’t want our advice to be applied to any classes that ‘accidentally’ define a method called handleRequest. We only want the advice applied to classes that implement Spring’s Controller interface. So here is what our ControllerClassFilter looks like:

public class ControllerClassFilter implements ClassFilter {
    public boolean matches( Class aClass ) {
        return Controller.class.isAssignableFrom( aClass );
    }
}

Fewf! Something easy to end off with!

I hope that this has managed to help shed a little light on how interceptors can be useful, and hopefully some of it actually made sense.

UPDATE: 1-Feb-2008 – This has changed as of Mac OS X 10.5 Leopard

For pre-Mac OS X 10.5, open a terminal and run:

sudo lookupd -flushcache

For Mac OS X 10.5:

sudo dscacheutil -flushcache

That should do it. You’ll need to type in your administrator password.

I have found the most fabulous set of free icons for use in web/desktop applications.

Check out this collection created and provided by Mark James.

http://www.famfamfam.com

This will let you know how to determine free disk space on a *nix box (Linux, FreeBSD, Mac OS X, Solaris, etc.) The man page for df says this:

df - report filesystem disk space usage

When I type df -k on one of my Linux machines, it tells me how much free space (in Kilobytes) I have on each of my mounted filesystems. Here is the output:

[daniel@localhost daniel]$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2             76541056  31788324  40864604  44% /
/dev/hda1               101089      9272     86598  10% /boot
none                    188248         0    188248   0% /dev/shm

This tells me that I have about 56% free space on my main /dev/hda2 partition, which is mounted at /. This translates into roughly 40864604 Kilobytes, or 40GB.

Your output will vary depending on the number of filesystems you have, and where they are.

I ran into a fabulous (and open source!) database tool the other day for interacting with various databases via JDBC.

It’s called Execute Query and the web site is here: http://executequery.org/.

It has a ton of features I’m sure I haven’t even used yet, but it reverse engineered my schema into an ERD for me, which made me smile.