The tweetstore demo

Tweetstore is a simple web application that demonstrates jclouds’ cloud capabilities. It queries Twitter for mentions of the user’s account and creates a “backup” of this priceless record of your contemporary image in three cloud stores: Amazon S3, Microsoft’s Azure and Rackspace. Nothing less than double redundancy is good enough for your popularity!

The original tweetstore application uses Guice for dependency injection and request mapping. In order to make it as easy as possible to compare the Spring version to the original, I decided to try to similarly do as much in Java code as possible. A perfect opportunity for me to get my hands dirty with Spring 3.0′s support for Java configuration.

Bootstrapping Spring’s Java Configuration

The first, relatively straight-forward step was to convert the Guice servlet module into an equivalent Spring @Configuration:

@Configuration
public class SpringServletConfig extends LoggingConfig implements ServletConfigAware {
    private ServletConfig servletConfig;
    ...

    @PostConstruct
    public void initialize() {
        ...
    }

    @Bean
    public StoreTweetsController storeTweetsController() {
        StoreTweetsController controller = new StoreTweetsController(providerTypeToBlobStoreMap,
                container, twitterClient);
        injectServletConfig(controller);
        return controller;
    }

    @Bean
    public AddTweetsController addTweetsController() {
        AddTweetsController controller = new AddTweetsController(providerTypeToBlobStoreMap,
                serviceToStoredTweetStatuses());
        injectServletConfig(controller);
        return controller;
    }

    private void injectServletConfig(Servlet servlet) {
        try {
            servlet.init(checkNotNull(servletConfig));
        } catch (ServletException exception) {
            throw new BeanCreationException("Unable to instantiate " + servlet, exception);
        }
    }

    @Bean
    ServiceToStoredTweetStatuses serviceToStoredTweetStatuses() {
        return new ServiceToStoredTweetStatuses(providerTypeToBlobStoreMap, container);
    }

    @Bean
    public HandlerMapping handlerMapping() {
        SimpleUrlHandlerMapping mapping = new SimpleUrlHandlerMapping();
        Map<String, Object> urlMap = Maps.newHashMapWithExpectedSize(2);
        urlMap.put("/store/*", storeTweetsController());
        urlMap.put("/tweets/*", addTweetsController());
        mapping.setUrlMap(urlMap);
        /*
         * "/store" and "/tweets" are part of the servlet mapping and thus stripped
         * by the mapping if using default settings.
         */
        mapping.setAlwaysUseFullPath(true);
        return mapping;
    }

    @Bean
    public HandlerAdapter servletHandlerAdapter() {
        return new SimpleServletHandlerAdapter();
    }

    ...
}

Being ServletConfigAware isn’t exactly Spring best practice but then the chosen aim was to stay as close as possible to the original set-up rather than building a Spring reference application.

Hooking Spring into the GAE startup was the next step. The Spring reference example was my first attempt:

<web-app>
    <servlet>
        <servlet-name>dispatcher</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <!-- Configure DispatcherServlet to use JavaConfigWebApplicationContext
             instead of the default XmlWebApplicationContext -->
        <init-param>
            <param-name>contextClass</param-name>
            <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
        </init-param>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>org.jclouds.demo.tweetstore.config.SpringServletConfig</param-value>
        </init-param>
    </servlet>

    <servlet-mapping>
    ...
</web-app>

Unfortunately, this unceremonially blew up in my face with a security violation: AnnotationConfigWebApplicationContext (and all Spring contexts that register a CommonAnnotationBeanPostProcessor) attempts to load javax.annotation.Resource to determine support for JSR-250, and that class, unlike others in the javax.annotation package, happens to be missing from the GAE whitelist.

It ain’t over until the App Engine sings

Moving back to a standard -servlet.xml file gets rid of the @Resource problem, but I was still left with an exception caused by Guice, which jclouds uses internally for dependency injection. I later discovered that the exception is relatively harmless and can be ignored². But of course no developer likes exceptions – however harmless – in the boot logs, so I wondered whether executing this call earlier in the boot sequence might resolve the problem.

So I moved the offending call from the servlet to the application context, guessing that the ContextLoaderListener might have more permissions than a servlet:

<web-app>
    <!-- can't use Java sconfiguration due to GAE's security restrictions -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/tweetstoreContext.xml</param-value>
    </context-param>

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

    <servlet>
    ...

And it worked! Or rather, it worked on the Java Development Server, the App Engine “simulator” provided with the SDK which is intended for development testing. But it didn’t work on App Engine itself³.
A word of caution, therefore: test on the “real” App Engine before concluding that something works, especially if it’s related to security restrictions!

Salvaging some @AnnotationConfig

By this time I knew that I wasn’t going to get away without writing at least a bit of Spring XML, but I was still trying to stick to Java as much as possible. After plenty of digging around in the Spring sources and a bit of experimentation, I discovered that, of the bean post processors currently registered by <context:annotation-config/>⁴ that I was interested in, only the CommonAnnotationBeanPostProcessor actually causes a problem. In fact, you can even use its immediate superclass, InitDestroyAnnotationBeanPostProcessor, which provides the @PostConstruct and @PreDestroy support I was looking for:

<beans xmlns="...>
    <!-- the usual <context:annotation-config/> can't be used because the
      CommonAnnotationBeanPostProcessor causes a security exception in GAE when it
      tries to load javax.annotation.Resource -->
    <bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />
    <bean class="org.springframework.context.annotation.ConfigurationClassPostProcessor" />
    <bean class="org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor">
        <property name="initAnnotationType" value="javax.annotation.PostConstruct" />
        <property name="destroyAnnotationType" value="javax.annotation.PreDestroy" />
    </bean>
    <bean class="org.jclouds.demo.tweetstore.config.SpringServletConfig" />
</beans>

So if you can live without @Resource, it seems that you can get away with most of Spring’s annotation-driven configuration on the GAE.