Past, present and future

August 17th, 2014 3 comments

Dear readers,

This week won’t be a detailed technical article: last week’s was the 250th post on this blog, time for a little introspection, and thinking about the past and future. Speaking about the past, my first post was written on this blog on April 7th 2008 – more than 6 years ago, to announce I had successfully passed the Sun Certified Java Developer 5 :-) At that time, I didn’t really know what a blog was for, I just wanted to have one and I used it sometimes like Twitter today.

The first real technical article was written about the Display taglib on May 23rd of the same year. I guess it was the first that really counted, and I haven’t stopped writing from this point. I love my job – though I’ve changed employers since that time, and all my positions have given me material to blog about. I also try to dabble into unknown territory when I want to understand how software I do not use is working. If you’re a regular visitor, you might have noticed I try to write once per week, though I sometimes cannot hold the rhythm. However, some of you might know I’m currently also writing Integration Testing from the Trenches, which sometimes puts me in a quandary: should I write a new article or write another chapter of the book? So if you want to help me there, don’t forget to get your own copy ;-)

And for the future, well, it looks extremely interesting.

  • At JavaZone (Oslo – Norway), on September 11th, I’ll be holding a workshop on Vaadin. I’ll also use the occasion to give a lightning talk on Mutation Testing
  • I’ll be at JavaDay Kiev (Ukrain), on October 17th-18th for a workshop on Vaadin and a talk about Integration Testing
  • Going to Joker conference (St Petersburg – Russia) on October 20th-21st? Let’s meet there, my exact contributions are to be announced in the near future
  • Finally, I’ll finish October at Agile Tour London on the 24th for a talk about Integration Testing

If you happen to attend any of these events, don’t hesitate to say hello!

 

Categories: Technical Tags:

Sanitizing webapp outputs as an an afterthought

August 10th, 2014 No comments

For sure, software security should be part of every developer’s requirements: they should be explained and detailed before development. Unfortunately, it happens in real life that this is not always the case. Alternatively, even when it is, developers make mistakes and/or have to make with tight (read impossible) plannings. In the absence of security checks automated tools, sooner or later, an issue will appear.

I’ve been thinking about a way to sanitize the output of a large-scale legacy Spring MVC application in a reliable way (i.e. not go on each page to fix issues). Basically, there are 4 ways output is displayed in the HTML page.

# Name Sample snippet Description
1 Form taglib <form:input path=”firstName”> Outputs a bean attribute
2 Spring taglib <spring:message code=”label.name.first”> Outputs a message from a properties file
3 Java Standard Taglib Library <c:out value=”${pageContext.request.requestURI}” /> Outputs a value
4 Expression Language <span>${pageContext.request.requestURI}</span> Outputs a value

Spring taglibs

Spring taglibs are a breeze to work with. Basically, Spring offers multiple ways to sanitize the output, each scope parameter having a possibility to be overridden by a narrower one:

  1. Application scoped, with the boolean defaultHtmlEscape context parameter
    <context-param>
      <param-name>defaultHtmlEscape</param-name>
      <param-value>true</param-value>
    </context-param>
  2. Page scoped (i.e. all forms on page), with the <spring:defaultHtmlEscape> tag
  3. Tag scoped, with the htmlEscape attribute of the tag

There’s only one catch; the <spring:message> tag can take not only a code (the key in the property file) but also arguments - however, those are not escaped :

Hello, ${0} ${1}

A possible sanitization technique consists of the following steps:

  1. Create a new SanitizeMessageTag:
    • Inherit from Spring’s MessageTag
    • Override the relevant revolveArguments(Object) method
    • Use the desired sanitization technique (Spring uses its own HtmlUtils.htmlEscape(String))
  2. Copy the existing Spring TagLib Descriptor and create a new one out of it
  3. Update it to bind the message tag to the newly created SanitizeMessageTag class
  4. Last but not least, override the configuration of the taglib in the web deployment descriptor:
    <jsp-config>
      <taglib>
        <taglib-uri>http://www.springframework.org/tags</taglib-uri>
        <taglib-location>/WEB-INF/tld/sanitized-spring-form.tld</taglib-location>
      </taglib>
    </jsp-config>

    By default, the JavaEE specifications mandates for the container to look for TLDs insides JARs located under the WEB-INF/lib directory. It is also possible to configure them in the web deployment descriptor. However, the configuration takes precedence over automatic scanning.

This way, existing JSP using the Spring taglib will automatically benefit from the new tag with no page-to-page update necessary.

JSTL

The <c:out> tag works the same way as the <spring:message> one, the only difference being there’s no global configuration parameter, only a escapeXml tag attribute which defaults to false.

The same technique as above can be used to default to true instead.

EL

The EL syntax enables output outside any taglib so that the previous TLD override technique cannot be used to solve this.

Not known to many developers, EL snippets are governed by so-called EL resolvers. Standard application servers (including servlet containers like Tomcat) provide standard EL resolvers, but it is also possible to add others at runtime.

Note: though only a single EL resolver can be set in the JSP context, the resolver hierarchy implements the Composite pattern, so it’s not an issue.

Steps required to sanitize EL syntax by default are:

  1. Subclasses relevant necessary EL resolvers – those are ScopedAttributeELResolver, ImplicitObjectELResolver and BeanELResolver, since they may return strings
  2. For each, override the getValue() method:
    • Call super.getValue()
    • Check the return value
    • If it is a string, sanitize the value before returning it, otherwise, leave it as it is
  3. Create a ServletContextListener to register these new EL resolvers
    public class SanitizeELResolverListener implements ServletContextListener {
        public void contextInitialized(ServletContextEvent event) {
            ServletContext context = event.getServletContext();
            JspFactory jspFactory = JspFactory.getDefaultFactory();
            JspApplicationContext jspApplicationContext = jspFactory.getJspApplicationContext(context);
            ELResolver sber = new SanitizeBeanELResolver();
            jspApplicationContext.addELResolver(sber);
            // Register other EL resolvers
        }
    }

Summary

Trying to sanitize the output of an application after it has been developed is not the good way to raise developers concerns about security. However, dire situations require dire solutions. When the application has already been developed, the above approaches - one for taglibs, one for EL, show how to achieve this in a way that does not impact existing code and get the job done.

Categories: JavaEE Tags: , ,

Session Fixation and how to fix it

August 3rd, 2014 3 comments

These last few weeks, I’ve been tasked to fix a number of security holes in our software. Since I’m not a security expert, I’ve been extremely interested in this, and have learned quite a few things. Among them is the Session Fixation attack.

The context is an online Java application. One part is avalailable through simple HTTP, where you can do simple browsing;  when you enter credentials and successfully log in, you’re switched to HTTPS. This is a very common setup found online. For example, Amazon works this way: you browse the product catalog and put products in your basket in HTTP, but as soon as you login to checkout, you’re switched to HTTPS.

Now, the attack scenario is the following:

  1. Alice visits this online application and gets the value of the JSESSIONID cookie returned by the server
  2. Alice crafts a link to the application, including the previous JSESSIONID
  3. Alice sends the link to Bob
  4. Bob clicks on the link sent (rather stupidly, I’d say) or copies the link to his browser (the result is the same)
  5. In the same session, Bob enters his credentials to enter the secured part of the application. He’s now authentified within the session referenced by the JSESSIONID sent by Alice
  6. Using the JSESSIONID sent in her own browser, Alice is able to operate the application with the same credentials as Bob

Wow! If the site is an online banking site, this is extremely serious, giving potential attackers access to your bank account. This issue is known as Session Fixation and is referenced by OWASP.

Though we can require users not to click on links sent by emails, that’s a request for “aware” users, not everyone’s grandmother. We definitely need a more robust solution. The proposed remediation is quite easy to design: when the user switches from HTTP to HTTPS, he’s sent another JSESSIONID. Basically, his old session is destroyed, and a new one is created with all attributes of his former session.

It is possible to implement this behavior. However, if one is using Spring Security, it’s available out of the box through the SessionFixationProtectionStrategy class. Just plug it into the UserNamePasswordAuthenticationFilter.

<beans ...>
  <bean id="authFilter" class="org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">
    <property name="sessionAuthenticationStrategy">
      <bean class="org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy">
    </property>
  </bean>
</beans>

Beware, most examples available on the Web only show usage of the strategy for session management!

Better yet, using JavaConfig and the WebSecurityConfigurerAdapter, it is configured out-of-the-box. Here’s an example of such configuration, with the strategy already configured:

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    protected void configure(AuthenticationManagerBuilder amb) throws Exception {
        // Creates a simple principal in memory
        amb.inMemoryAuthentication().withUser("frankel").password("").roles("USER");
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
             // Requires user to have USER role
            .antMatchers("/hello").hasRole("USER")
            .and().requiresChannel()
            // Requires channel to be HTTPS
            .antMatchers("/hello").requiresSecure()
            // Dont forget a simple form login!
            .and().formLogin();
    }
}

Get the sample project - it is also a good template project for Spring MVC & Spring Security with JavaConfig, and check the JSESSIONID cookie value changed.

Note: you’ll need a SSL-enabled servlet container.

Categories: Java Tags: ,

Spring configuration modularization for Integration Testing

July 27th, 2014 1 comment

Object-Oriented Programming advocates for modularization in order to build small and reusable components. There are however other reasons for this. In the case of the Spring framework, modularization enables Integration Testing, the ability to test the system or parts of it, including assembly configuration.

Why is it so important to test the system assembled with the final configuration? Let’s take a simple example, the making of a car. Unit Testing the car would be akin to testing every nuts and bolts of the car separately, while Integration Testing the car would be like driving it on a circuit. By testing only the car’s components separately, selling the assembled car is a huge risk as nothing guarantees it will behave correctly in real-life conditions.

Now that we have asserted Integration Testing is necessary to guarantee the adequate level of internal quality, it’s time to enable Integration Testing with the Spring framework. Integration Testing is based on the notion of SUT. Defining the SUT is to define the boundaries between what is tested and its dependencies. In nearly all cases, test setup will require to provide some kind of test double for each required dependency. Configuring those test doubles can only be achieved by modularizing Spring configuration, so that they can replace dependent beans located outside the SUT.

Sample bean dependency diagram

Fig. 1 – Sample bean dependency diagram

Spring’s DI configuration comes in 3 different flavors: XML – the legacy way, autowiring and the newest JavaConfig. We’ll have a look at how modularization can be achieved for each flavor. Mixed DI modularization can be deduced from each separate entry.

Autowiring

Autowiring is an easy way to assemble Spring applications. It is achieved through the use of either @Autowiring or @Inject. Let’s cover quickly autowiring: as injection is implicit, there’s no easy way to modularize configuration. Applications using autowiring will just have to migrate to another DI flavor to allow for Integration Testing.

XML

XML is the legacy way to inject dependencies, but is still in use. Consider the following monolithic XML configuration file:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
     xmlns:jee="http://www.springframework.org/schema/jee"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
      http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee.xsd">
  <jee:jndi-lookup id="dataSource" jndi-name="jdbc/MyDataSource" />
  <bean id="productRepository" class="ProductRepository">
    <constructor-arg ref="dataSource" />
  </bean>
  <bean id="customerRepository" class="CustomerRepository">
    <constructor-arg ref="dataSource" />
  </bean>
  <bean id="orderRepository" class="OrderRepository">
    <constructor-arg ref="dataSource" />
  </bean>
  <bean id="orderService" class="OrderService">
    <constructor-arg ref="productRepository" index="0" />
    <constructor-arg ref="customerRepository" index="1" />
    <constructor-arg ref="orderRepository" index="2" />
  </bean>
</beans>

At this point, Integration Testing orderService is not easy as it should be. In particular, we need to:

  • Download the application server
  • Configure the server for the jdbc/MyDataSource data source
  • Deploy all classes to the server
  • Start the server
  • Stop the server After the test(s)

Of course, all previous tasks have to be automated! Though not impossible thanks to tools such as Arquillian, it’s contrary to the KISS principle. To overcome this problem and make our life (as well as test maintenance) easier in the process requires tooling and design. On the tooling part, we’ll be using a local database. Usually, such a database is of the in-memory kind e.g. H2. On the design part, his requires separating our beans by creating two different configuration fragments, one solely dedicated to the data source to be faked and the other one for the beans constituting the SUT.

Then, we’ll use a Maven classpath trick: Maven puts the test classpath in front of the main classpath when executing tests. This way, files found in the test classpath will “override” similarly-named files in the main classpath. Let’s create two configuration files fragments:

  • The “real” JNDI datasource as in the monolithic configuration
    <beans ...>
      <jee:jndi-lookup id="dataSource" jndi-name="jdbc/MyDataSource" />
    </beans>
  • The Fake datasource
    <beans...>
      <bean id="dataSource" class="org.apache.tomcat.jdbc.pool.DataSource">
          <property name="driverClassName" value="org.h2.Driver" />
          <property name="url" value="jdbc:h2:~/test" />
          <property name="username" value="sa" />
          <property name="maxActive" value="1" />
      </bean>
    </beans>

    Note we are using a Tomcat datasource object, this requires the org.apache.tomcat:tomcat-jdbc:jar library on the test classpath. Also note the maxActive property. This reflects the maximum number of connections to the database. It is advised to always set it to 1 for test scenarios so that connections pool exhaustion bugs can be checked as early as possible.

The final layout is the following:

Fig. 2 – Project structure for Spring XML configuration Integration Testing

  1. JNDI datasource
  2. Other beans
  3. Fake datasource

The final main-config.xml file looks like:

<?xml version="1.0" encoding="UTF-8"?>
<beans...>
  <import resource="classpath:datasource-config.xml" />
  <!-- other beans go here -->
</beans>

Such a structure is the basics to enable Integration Testing.

JavaConfig

JavaConfig is the most recent way to configure Spring applications, bringing both compile-time (as autowiring) and explicit configuration (as XML) safety.

The above datasources fragments can be “translated” in Java as follows:

  • The “real” JNDI datasource as in the monolithic configuration
    @Configuration
    public class DataSourceConfig {
    
        @Bean
        public DataSource dataSource() throws Exception {
            Context ctx = new InitialContext();
            return (DataSource) ctx.lookup("jdbc/MyDataSource");
        }
    }
  • The Fake datasource
    public class FakeDataSourceConfig {
    
        public DataSource dataSource() {
            org.apache.tomcat.jdbc.pool.DataSource dataSource = new org.apache.tomcat.jdbc.pool.DataSource();
            dataSource.setDriverClassName("org.h2.Driver");
            dataSource.setUrl("jdbc:h2:~/test");
            dataSource.setUsername("sa");
            dataSource.setMaxActive(1);
            return dataSource;
        }
    }

However, there are two problems that appear when using JavaConfig.

  1. It’s not possible to use the same classpath trick with an import as with XML previously, as Java forbids to have 2 (or more) classes with the same qualified name loaded by the same classloader (which is the case with Maven). Therefore, JavaConfig configuration fragments shouldn’t explicitly import other fragments but should leave the fragment assembly responsibility to their users (application or tests) so that names can be different, e.g.:
    @ContextConfiguration(classes = {MainConfig.class, FakeDataSource.class})
    public class SimpleDataSourceIntegrationTest extends AbstractTestNGSpringContextTests {
    
        @Test
        public void should_check_something_useful() {
            // Test goes there
        }
    }
  2. The main configuration fragment uses the datasource bean from the other configuration fragment. This mandates for the former to have a reference on the latter. This is obtained by using the @Autowired annotation (one of the few relevant usage of it).
    @Configuration
    public class MainConfig {
    
        @Autowired
        private DataSource dataSource;
    
        // Other beans go there. They can use dataSource!
    }

Summary

In this article, I showed how Integration Testing to a Fake data source could be achieved by modularizing the monolithic Spring configuration into different configuration fragments, either XML or JavaConfig.

However, the realm of Integration Testing – with Spring or without, is vast. Should you want to go further, I’ll hold a talk on Integration Testing at Agile Tour London on Oct. 24th and at Java Days Kiev on Oct. 17th-18th.

This article is an abridged version of a part of the Spring chapter of Integration Testing from the Trenches. Have a look at it, there’s even a sample free chapter!

Integration Testing from the Trenches

Categories: Java Tags: ,

Choosing a password manager

July 20th, 2014 2 comments

I’ve been thinking about having a more secure password management since ages. At first, my only concern was to share my bookmarks and history between my different computers (at that time, phones were conveniently left out of my scope). Since Firefox was my browser of choice, I decided to go for Foxmarks (now called XMarks and available for more browsers).

However, it soon became apparent that my natural lazyness came back and I synchronized my passwords too… in the cloud. After Firefox brought out-of-the-box synchronization through Sync, I continued to use the feature, not listening to the little voice in my head telling me it was a big security problem. I mean, Mozilla could secure the storage the way it wanted, I still felt not really safe… but lazyness prevailed. It was not until I had to change the way I synchronized stuff thanks to Firefox new Sync feature that I decided it was more than enough: I searched for a better way for my passwords to be available on all my devices.

The heart of the matter of choosing a good password is the following: I want my passwords to be easy to remember and easy to type while at the same time I want them to be impossible to either guess or crack. Usability versus security. This is somewhat summarized in this xkcd comis:

Password Strength

Some online service providers (such as Google and Dropbox) offer an interesting feature to defeat the natural tendency of users to choose easy-to-guess passwords, 2-steps authentication. This means you not only have to enter the password, you also have to provide another mean of authentication. Both previous providers use a code generated from some parameters known by both parties (provider and customer) but also time, so that guessing the code is only possible during a short amount of time (generally a minute). Another form of 2nd step is offered by banks as they send a code on your phone while you make an online transaction with your credit card, and then you have to enter it on the site to prove you’re the cardholder.

Some other providers even delegate authentication to third-party providers such as Google (always it) or Github. A well known process to do that is OAuth2. OAuth2 could solve the many passwords problem if all service providers would offer delegation. Unfortunately, most of them prefer to do authentication on their own (as well as keep identities their own, but that’s a story for another day). Even more unfortunate is the fact that they only offer traditional login/password authentication challenges. Back to square one…

Of course, I could make an effort to create a single hard-to-crack password… but with so many applications around, this is completely out of the question (or even impossible) to craft such a password for each one. None will advise to use the same password for all applications – as a hacker discovering the password on a site will be able to access all of them, but some advocate to prepend or append the domain name to the password. Alas, any simple automatic rule can easily be defeated by the means of automation cracking on the other side, so this should never ever been done – if you value the security of your accounts.

The answer is very simple: for each application, create a dedicated hard-to-crack and impossible-to-remember password and store them somewhere safe. This place of safety can then be secured with a a-little-easier-to-crack and possible-to-remember master password – the key to the Holy Grail. In essence, this describes a solution known as a password manager. I had a couple of requirements for such a software:

  • Open Source: I prefer having an Open Source solution when possible as I think that qualified people can (at least in theory) perform a security audit on it. A closed source solution means security through obfuscation and this just doesn’t work against real threats.
  • Multi-devices: yes, I’m one of those people that not only have multiple computers (office, desktop, laptop) with different Operating Systems (Windows and OSX) but also 2 phones and a tablet. So I want a solution that is compatible with all of those.
  • Configurable authentication: this requirement is very important as it not only let me choose how to authenticate into the store (e.g. password or key) but also increases the security of the solution.
  • Best practices: last but not least, I require security best practices to be implemented, such as hashing, salting, a slow hashing algorithm, etc.

Having chosen my password manager, now comes the hard part: should I keep my password store on a USB key I always keep by me (and a copy in a secure location, just to be sure), on my laptop I carry everywhere or in the cloud? This amounts to the same problem as before, security or usability? I’ve decided to store it the cloud, on a provider infrastructure secured by 2-steps authentication. I’ve also ensured that this store is made avalaible on my different devices, though I’m not unaware that a chain is as strong as its weakest link. With my current setup, I’m not sure I’m completely free of any prying effort by 3 letters agencies, or more precisely I’m sure I’m not. However, I believe I’ve increased my robustness to online intrusion by several degrees of magnitude and that should prevent script kiddies to play some nasty tricks on me. Your turn, now…

Categories: Technical Tags:

Easier Spring version management

July 6th, 2014 No comments

Earlier on, Spring migrated from a monolithic approach – the whole framework, to a modular one – bean, context, test, etc. so that one could decide to use only the required modules. This modularity came at a cost, however: in the Maven build configuration (or the Gradle one for that matter), one had to specify the version for each used module.

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
    ...
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>4.0.5.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-jdbc</artifactId>
            <version>4.0.5.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>4.0.5.RELEASE</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Of course, professional Maven users would improve this POM with the following:

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
    ...
   <properties>
        <spring.version>4.0.5.RELEASE</spring.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>${spring.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-jdbc</artifactId>
            <version>${spring.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>${spring.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

There’s an more concise way to achieve the same through a BOM-typed POM (see section on scope import) since version 3.2.6 though.

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
    ...
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-framework-bom</artifactId>
                <type>pom</type>
                <version>4.0.5.RELEASE</version>
                <scope>import</scope>
            </dependency>
        <dependencies>
    </dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Note that Spring’s BOM only sets version but not scope, this has to be done in each user POM.

Spring released very recently the Spring IO platform which also includes a BOM. This BOM not only includes Spring dependencies but also other third-party libraries.

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
    ...
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>io.spring.platform</groupId>
                <artifactId>platform-bom</artifactId>
                <type>pom</type>
                <version>1.0.0.RELEASE</version>
                <scope>import</scope>
            </dependency>
        <dependencies>
    </dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

There’s one single problem with Spring IO platform’s BOM, there’s no simple mapping from the BOM version to declared dependencies versions. For example, the BOM’s 1.0.0.RELEASE maps to Spring 4.0.5.RELEASE.

To go further:

Categories: Java Tags: ,

First release of Integration Testing from the Trenches

June 29th, 2014 5 comments

My job as a software architect is to make sure the builds I provide have the best possible quality, and more specifically internal quality. While Unit Testing sure helps creating less regressions, relying only on it is akin to testing a car by testing its nuts and bolts. Integration Testing is about getting the car on a circuit.

Last week, I finally released the fist version of Integration Testing from the Trenches. As its name implies, this book is about Integration Testing. It is organized in the following chapters:

Chapter 1 – Foundations of testing
This is an introductory chapter, laying out the foundations for the rest of the book. It describes Unit Testing, Integration Testing and Functional Testing, as well as their associated notions.
Chapter 2 – Developer testing tools
This chapter covers both the JUnit and TestNG testing frameworks. Tips and tricks on how to use them for Integration Testing are also included.
Chapter 3 – Test-Friendly Design
This chapter details Dependency Injection, DI-compatible design and which objects should be set as dependencies during tests execution. This includes definitions of Test Doubles, such as Dummy,  Fake and Mock along with an explanation of Mockito, a Mocking framework and Spring Test and Mockrunner, two OpenSource available Fake libraries.
Chapter 4 – Automated testing
It covers how to get our carefully crafted Integration Tests to run through automated build tools, like Maven and Gradle.
Chapter 5 – Infrastructure Resources Integration
This chapter concerns itself about Integration Testing applied to infrastructure resources such as databases, mail servers, ftp servers and others. Tools and techniques about each resource type will be explained.
Chapter 6 – Web Services Integration
This chapter is solely dedicated to Integration Testing with Web Services, either in SOAP or REST flavor.
Chapter 7 – Spring in-container testing
In this chapter, testing recipes for Spring and Spring MVC applications are described. It also includes coverage of the Spring Test library.
Chapter 8 – JavaEE testing
Last but not least, this chapter covers testing of Java EE applications, including the Arquillian testing framework.

There’s a free sample chapter for you kind reader if you want to go further. Here’s a 10% discount valid for the whole week to have something to read on the beach during vacations!

In all cases, I’ll take excerpts from the book and publish them on this blog in the following week.

Categories: Java Tags:

The right bean at the right place

June 22nd, 2014 No comments

Among the different customers I worked for, I noticed a widespread misunderstanding regarding the use of Spring contexts in Spring MVC.

Basically, you have contexts, in a parent-child relationship:

  • The main context is where service beans are hosted. By convention, it is spawned from the /WEB-INF/applicationContext.xml file
    but this location can be changed by using the contextConfigLocation context parameter. Alternatively, one can use the AbstractAnnotationConfigDispatcherServletInitializer and in this case, configuration classes should be parts of the array returned by the getRootConfigClasses() method.
  • Web context(s) is where Spring MVC dispatcher servlet configuration beans and controllers can be found. It is spawned from <servlet-name>-servlet.xml or, if using the JavaConfig above, comes from classes returned by the getServletConfigClasses() method

As in every parent-child relationship, there’s a catch:

Beans from the child contexts can access beans from the parent context, but not the opposite.

That makes sense if you picture this: I want my controllers to be injected with services, but not the other way around (it would be a funny idea to inject controllers in services). Besides, you could have multiple Spring servlets with its own web context, each sharing the same main context for parent. When it goes beyond controllers and services, one should decide in which context a bean should go. For some, that’s pretty evident: view resolvers, message sources and such go into the web context; for others, one would have to spend some time thinking about it.

A good rule of thumb to decide in which context which bean should go is the following: IF you had multiple servlets (even if you do not), what would you like to share and what not.

Note: this way of thinking should not be tied to your application itself, as otherwise you’d probably end up sharing message sources in the main application context, which is a (really) bad idea.

This modularization let you put the right bean at the right place, promoting bean reusability.

Categories: JavaEE Tags: , ,

Back to basics: encapsulating collections

June 15th, 2014 4 comments

Younger, I learned there were 3 properties of the Object-Oriented paradigm:

  • Encapsulation
  • Inheritance
  • Polymorphism

In Java, encapsulation is implemented through usage of private attributes with accessors methods commonly known as getters and setters. Whether this is proper encapsulation is subject to debate and is outside the scope of this article. However, using this method to attain encapsulation when the attribute is a collection (of types java.util.Collection, java.util.Map and their subtypes) is just plain wrong.

The code I see most of the times is the following:

public class MyBean {
    private Collection collection;

    public Collection getCollection() {
        return collection;
    }

    public void setCollection(Collection collection) {
        this.collection = collection;
    }
}

This is the most common code I see: this design has been popularized by ORM frameworks such as Hibernate. Many times when I raise this point, the next proposal is an immutable one.

public class MyBean {
    private Collection collection;

    public MyBean(Collection collection) {
        this.collection = collection;
    }

    public Collection getCollection() {
        return collection;
    }
}

No proper encapsulation

However, in the case of collections, this changes nothing as Java collections are mutable themselves. Obviously, both passing a reference to the collection in the constructor and returning a reference to it is no encapsulation at all. Real encapsulation is only possible if no reference to the collection is kept nor returned.

List list = new ArrayList();
MyBean mybean = new MyBean(list);
list.add(new Object()); // We just modified the collection outside my bean

Not possible to use a specific subtype

Besides, my bean could require a more specific collection of its own, such as List or Set. With the following code snippet, passing a Set is simply not possible.

public class MyBean {
    private List collection;

    public List getCollection() {
        return collection;
    }

    public void setCollection(List collection) {
        this.collection = collection;
    }
}

No choice of the concrete implementation

As a corollary from the last point, using the provided reference prevents us from using our own (perhaps more efficient) type e.g. a Apache Commons FastArrayList.

An implementation proposal

The starting point of any true encapsulation is the following:

public class MyBean {
    private List collection = new ArrayList();

    public MyBean(Collection collection) {
        this.collection.addAll(collection);
    }

    public Collection getCollection() {
        return Collections.unmodifiableList(collection);
    }
}

This fixes the aforementioned cons:

  1. No reference to the collection is passed in the constructor, thus preventing any subsequent changes from outside the object
  2. Freedom to use the chosen collection implementation, with complete isolation – leaving room for change
  3. No reference to the wrapped collection is passed in the collection returned by the getter

Note: previous snippets do not use generics for easier readability, please do use them

Categories: Java Tags:

A single simple rule for easier Exception hierarchy design

June 9th, 2014 6 comments

Each new project usually requires setting up an Exception hierarchy, usually always the same.

I will not go into details whether we should extend RuntimeException or directly Exception, or whether the hierarchy roots should be FunctionalException/TechnicalException or TransientException/PersistentException. Those will be rants for another time as my current problem is completely unrelated.

The situation is the following: when something bad happens deep in the call layer (i.e. an authentication failure from the authentication provider), a new FunctionalException is created with a known error code, say 123.

public class FunctionalException extends RuntimeException {
    private long errorCode;
    public FunctionalException(long errorCode) {
        this.errorCode = errorCode;
    }
    // Other constructors
}

At this point, there are some nice advantages to this approach: the error code can be both logged and shown to the user with an adequate error message.

The downside is in order to analyze where the authentication failure exception is effectively used in the code is completely impossible. As I’m stuck with the task of adding new features on this codebase, I must say this sucks big time. Dear readers, when you design an Exception hierarchy, please add the following:

public class AuthenticationFailureException extends FunctionalException {
    public AuthenticationFailureException() {
       super(123L);
 }
 // Other constructors
}

This is slightly more verbose, of course, but you’ll keep all aforementioned advantages as well as letting poor maintainers like me analyze code much less painlessly. Many thanks in advance!

Categories: Java Tags: ,