Tejus’s Blog

A few months ago the power supply on my server totally tanked. The cost to replace it was somewhere around $99 and some elbow grease, but it got beyond the point where I wanted to maintain my own hardware. This would be the third hardware failure in as many years and I was frustrated.

I still wanted my own server with full access, so I got an account with Linode. Since I found it very difficult to upgrade between major versions of OpenSUSE, I installed Arch Linux based on the recommendation of the guys over at WeTheCitizens.

This blog, my private repositories and some other stuff sit on this server now, but the shared instance wasn’t going to work for photos.  I signed up for a Flickr pro account and started migrating my public code to GitHub.

When I started this site nearly 5 years ago, none of this would have been practical.  The hosting that you got for $20/mo was worthless.  Code and photosharing sites all sucked.  Now I’ve got a set of tools that work really well and I don’t have to maintain any of it.

A few months ago at work I got stuck with a rather daunting assignment: to make Spring Security work alongside our legacy security model.

The rationale was sound. We have a legacy UI and we want a smooth transition to the new one. Which means that as much of their information, including their credentials need to carry over. Furthermore, our application runs load-balanced in the production environment and we can’t make use of sticky sessions. Which means that the solution needs to integrate with our database-backed sessions. If that was not complicated enough, there was also a lot of hidden authorization code that relied on specific properties being set in ThreadLocal.

After a few months of trial and error, I think I finally have a solution that both works and doesn’t lock the database. There are quite a few steps and the process is somewhat lengthy. For that reason, the rest of this tutorial is under the fold.
(more…)

Sonali and I haven’t been to North Georgia in forever so we decided to brave the heat and head some place new. When we lived in Alpharetta, we frequented the Northeast side of our state a lot. Lately we’ve been trying to see what’s there on the Eastern parts.

Fort Mountain has a lot of trails, but most of them seem somewhat unused and infrequently traveled. We traveled on portions of the Guhati Trail, which is an 8.2 mile loop. The trail was well marked, but could have used a little more attention. There were lengthy sections that were nearly overgrown and more than a few trees blocking the path.

The trail also didn’t seem that popular, we didn’t see another soul while walking. We ended up taking the main road back instead of walking back down the trail to make up some time.

As soon as someone mentions Web 2.0, you know that you’re going to need a modal dialog. If a designer is involved, then you know that it’s going to have to look nothing like any of the standard lightbox clones.

The de-facto standard for modal dialogs with JQuery is Thickbox. However, if anything above sounds familiar, I recommend giving Colobox a try.

Colorbox is missing a few features of Thickbox. The Colorbox does not resize automatically and doesn’t change position on screen when the user-resizes their page. However, that wasn’t a big issue for my needs, since users probably couldn’t use the app unless they had maximized their browser anyway.

Where the developer of colorbox focused his time is allowing the developer using Colorbox to customize it however they want. Take a look at the css. Every element that you need to change has an ID and represented in the file.

One missing feature that would be nice to have is the ability to add custom buttons. In the app I’m building, I had to manually add them into the JS file. Which wasn’t hard, but it breaks the ability to upgrade.

However, the most important thing is the ability to make the product fit the design and colorbox does deliver on that.

Annotations and POJO controllers make dead simple to unit test the web layer and ensure that the logic within it is correct. What’s not as clear is how to quickly (and automatically) test the configurations of your controllers and ensure the correct controller method is called with the correct parameters on a request.

After looking through the Spring MVC tests, it becomes apparent that you want to create a DispatcherServlet and send it requests. If the DispatcherServlet is initialized with the correct context, it will then behave just as it does in your web container. It will look at the request, find the correct handler, and make the appropriate controller call. I created three classes to help set up the environment.

public class MockWebContextLoader extends AbstractContextLoader {
 
    public static final ServletContext SERVLET_CONTEXT = new MockServletContext("/WebContent", new FileSystemResourceLoader());
 
    private final static GenericWebApplicationContext webContext = new GenericWebApplicationContext();
 
    protected BeanDefinitionReader createBeanDefinitionReader(final GenericApplicationContext context) {
        return new XmlBeanDefinitionReader(context);
    }
 
    public final ConfigurableApplicationContext loadContext(final String... locations) throws Exception {
 
        SERVLET_CONTEXT.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, webContext);
        webContext.setServletContext(SERVLET_CONTEXT);
        createBeanDefinitionReader(webContext).loadBeanDefinitions(locations);
        AnnotationConfigUtils.registerAnnotationConfigProcessors(webContext);
        webContext.refresh();
        webContext.registerShutdownHook();
        return webContext;
    }
 
    public static WebApplicationContext getInstance() {
        return webContext;
    }
 
    protected String getResourceSuffix() {
        return "-context.xml";
    }
 
}

The MockWebContextLoader loads in the spring config locations and creates a WebContext . In order for this environment to mimic the one in your web container, you will need to pass in the same configs. I will show you how to do that later.

To help validate the success of a test, I’ve created another ViewResolver that just echoes the viewname into the response. You could have the ViewResolver return the correct view, but parsing that to gauge success seemed like too much of a headache.

public class TestViewResolver implements ViewResolver {
 
    public View resolveViewName(final String viewName, Locale locale) throws Exception {
        return new View() {
            public String getContentType() {
                return null;
            }
            @SuppressWarnings({"unchecked"})
            public void render(Map model, HttpServletRequest request, HttpServletResponse response) throws Exception {
                response.getWriter().write(viewName);
            }
        };
    }
 
}

Finally, I created an abstract class that would handle the creation of the DispatcherServlet for all tests that extend it. I’ve put my spring configuration files on the classpath that my test run it. If your configs are elsewhere, you will need to modify MockWebContextLoader to look in a different path.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(loader=MockWebContextLoader.class, locations={"/classes/spring.xml", "/springmvc-servlet.xml"})
public abstract class AbstractControllerTestSupport {
 
    private static DispatcherServlet dispatcherServlet;
 
 
    @SuppressWarnings("serial")
    public static DispatcherServlet getServletInstance() {
        try {
            if(null == dispatcherServlet) {
                dispatcherServlet = new DispatcherServlet() {
                    protected WebApplicationContext createWebApplicationContext(WebApplicationContext parent) {
                        GenericWebApplicationContext wac = new GenericWebApplicationContext();
                        wac.setParent(MockWebContextLoader.getInstance());
                        wac.registerBeanDefinition("viewResolver", new RootBeanDefinition(TestViewResolver.class));
                        wac.refresh();
                        return wac;
                    }
                };
 
                dispatcherServlet.init(new MockServletConfig());
            }
        } catch(Throwable t) {
            Assert.fail("Unable to create a dispatcher servlet: " + t.getMessage());
        }
        return dispatcherServlet;
    }
 
    protected MockHttpServletRequest mockRequest(String method, String uri, Map<string ,String> params) {
        MockHttpServletRequest req = new MockHttpServletRequest(method, uri);
        for(String key : params.keySet()) {
            req.addParameter(key, params.get(key));
        }
        return req;
    }
 
    protected MockHttpServletResponse mockResponse() {
        return new MockHttpServletResponse();
    }
}
</string>

With this harness, it’s trivial to automatically check the configuration of the web controllers. Since the functionality is tested separately from the configuration, the problems can be isolated quicker, leaving more time to fix them.

Since the time change, I’ve been having an issue with the clock on my Aspire One. Everytime it sleeps, the clock is exactly one hour in the past. It wasn’t a timezone problem, since running date correctly showed the time as EDT

The fix for this is to run the follow two commands:

$ sudo ntpdate us.pool.ntp.org
$ sudo hwclock --systohc

This will sync your hardware clock to the time from the network time service.

I’ve already posted about why I like Git better than Subversion. This motivated me to install the GIT-SVN bridge up to my work SVN repository.

Using the bridge is a bit confusing at first. This tweet by Calvin Yu pointed out is right on the money. Git’s interface isn’t great, but it is powerful. There are two major resources that I use to use the bridge effectively: this blog post and the git-svn man page which has a lot of examples. Between the two, I’ve been able to do almost everything I want.

So why go through the effort of cloning your SVN repository (which took a half day for me)? What follows are my reasons.

Local Branching

We’ve got a fairly large development team. If we let encourage every developer to create a branch for each whim, our branch space would be quickly polluted. Since most of the exploratory work is generally done by one person, there isn’t any real need for collaboration either. The end result is work that often just disappears as developers find it hard to maintain a lot of uncommitted changes.

Git allows you to create local branches. These branches exist within your repository. You can commit to them as often as you like.

Fast Branch Switching

Git is a clone of your whole repository. Most importantly, it’s an efficient clone of the whole repository. Which means you only have to download deltas when you change branches. If you need to work on a new branch in SVN, you need to check the whole thing out. On a sizable repository hosted off-site, this can take a while.

Recently, I was working on a local branch. I needed something from the head of another branch, so I checked that out and did what I needed to do. Then I got an email from my boss asking me to look at a bug. I checked out trunk. It was an easy fix and shortly thereafter, I got another email asking me to commit it to the release branch, a branch that I’ve never checked out. I checked it out and committed it there too. With git-svn, this whole process took 20 minutes, including the time to fix the bug. Given that each branch is nearly half a gig, and our outside line isn’t very fast, that’s pretty impressive.

Cherry Pick

Git has a command that pulls a single commit from one branch to any other branch. Sure you can do the same thing with SVN merge, but nobody remembers that syntax.

Local Commits

It’s really nice to be able to occasionally commit intermediary code without breaking the build. When I make a mistake or can’t figure out why something that was working isn’t anymore, having past versions to look at is helpful.

The Stash

Occasionally you have to switch gears. Git Stash lets you do that without losing work.

Being Trendy

Hey, style is important too Seriously, the benefits outlined above, though simple, can save a massive amount of time when things are breaking all over the place. That alone is causing the use of the bridge to slowly spread through the organization.