This can happen in numerous circumstances where you’d like an application to maintain a degree of liveness. I’ve used it recently in an application that needed to run a number of external scripts; if the script does not complete, for whatever reason, the timeout ensures the the calling thread does not get blocked and the remaining scripts can be launched.

Here’s the basic idea:

public class TimeoutDemo {

    //maintains a thread for executing the doWork method
    private ExecutorService executor = Executors.newFixedThreadPool(1);

    public void doWork() {
        //perform some long running task here...
    }

    public void doWorkWithTimeout(int timeoutSecs) {

        //set the executor thread working
        final Future<?> future = executor.submit(new Runnable() {
            public void run() {
                try {
                    doWork();
                } catch (Exception e) {
                    throw new RuntimeException(e);
                }
            }
        });

        //check the outcome of the executor thread and limit the time allowed for it to complete
        try {
            future.get(timeoutSecs, TimeUnit.SECONDS);
        } catch (Exception e) {
            //ExecutionException: deliverer threw exception
            //TimeoutException: didn't complete within downloadTimeoutSecs
            //InterruptedException: the executor thread was interrupted

            //interrupts the worker thread if necessary
            future.cancel(true);

            log.warn("encountered problem while doing some work", e);
        }
    }
}

The doWork method is the one that will actually do some potentially long running work. The doWorkWithTimeout illustrates how the java.util.concurrent classes can be used to prevent the method from taking too long to complete. When calling the latter method, just specify the timeout period in minutes.

The trick here is that the actual work will be done by a dedicated worker thread. The calling thread will handle the timeout management and also handle any exceptions thrown by the worker.

Variations of this pattern can be used for methods that accept parameters (just make them final) and for ones that return values too (just return the value from the future.get(…) call).

The ‘/test’ in the URL will map to a servlet called test. The servlet will dispatch the request to a JSP for rendering that has the following scriplet code in it:

RequestURL: <%= request.getRequestURL() %> <br>
RequestURI: <%= request.getRequestURI() %> <br>
QueryString: <%= request.getQueryString() %> <br>
ServletPath: <%= request.getServletPath() %> <br>
PathInfo: <%= request.getPathInfo() %> <br>
PathTranslated: <%= request.getPathTranslated() %><br>
AuthType: <%= request.getAuthType() %> <br>
LocalAddress: <%= request.getLocalAddr() %> <br>
Method: <%= request.getMethod() %> <br>
RemoteUser: <%= request.getRemoteUser() %> <br>

this is the output generated:

RequestURL: https://localhost:8443/test/welcome
RequestURI: /test/welcome
QueryString: a=1&b=2
ServletPath: /test
PathInfo: /welcome
PathTranslated: C:\projects\testproj\out\artifacts\testapp_war_exploded\welcome
AuthType: CLIENT_CERT
LocalAddress: 127.0.0.1
Method: GET
RemoteUser: Steve

What is Flash Scope

Flash scope is a useful part of many web frameworks. It allows the use of the post/redirect/get design pattern to alleviate many of the problems associated with handling multiple submits or resubmission of data in browser requests to the server.

Flash scope is an additional scope to those provided in a standard Java Web application (page, request, session and application). Any attributes held in flash scope will be available for the duration of the current request, and the subsequent request too.

My Implementation

To implement flash scope in my application, I added a servlet filter that checks for request attribute names starting with ‘flash.‘. When it finds such an attribute, it ensures that it is made available in the subsequent request by temporarily storing it in the user’s session, and then reinstating it when the next request is received.

For example, to add a message to flash scope, just use the regular syntax for adding a request scoped attribute and let the fiter take care of it:

request.setAttribute("flash.message", "Here is the news...");

The above attribute can then be accessed in the redirect target JSP using EL or scriptlet syntax (omitting the ‘flash.‘ prefix):

${message}
or
<%= request.getAttribute("message")  %>

Here’s the code for the filter:

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;

/**
 * Ensures that any request parameters whose names start
 * with 'flash.' are available for the next request too.
 */
public class FlashScopeFilter implements Filter {

    private static final String FLASH_SESSION_KEY = "FLASH_SESSION_KEY";

    @SuppressWarnings("unchecked")
    public void doFilter(ServletRequest request, ServletResponse response,
					FilterChain chain) throws IOException, ServletException {

        //reinstate any flash scoped params from the users session
		//and clear the session
        if (request instanceof HttpServletRequest) {
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            HttpSession session = httpRequest.getSession(false);
            if (session != null) {
                Map<String, Object> flashParams = (Map<String, Object>)
									session.getAttribute(FLASH_SESSION_KEY);
                if (flashParams != null) {
                    for (Map.Entry<String, Object> flashEntry : flashParams.entrySet()) {
                        request.setAttribute(flashEntry.getKey(), flashEntry.getValue());
                    }
                    session.removeAttribute(FLASH_SESSION_KEY);
                }
            }
        }

        //process the chain
        chain.doFilter(request, response);

        //store any flash scoped params in the user's session for the
		//next request
        if (request instanceof HttpServletRequest) {
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            Map<String, Object> flashParams = new HashMap();
			Enumeration e = httpRequest.getAttributeNames();
            while (e.hasMoreElements()) {
                String paramName = (String) e.nextElement();
                if (paramName.startsWith("flash.")) {
                    Object value = request.getAttribute(paramName);
                    paramName = paramName.substring(6, paramName.length());
                    flashParams.put(paramName, value);
                }
            }
            if (flashParams.size() > 0) {
                HttpSession session = httpRequest.getSession(false);
                session.setAttribute(FLASH_SESSION_KEY, flashParams);
            }
        }
    }

    public void init(FilterConfig filterConfig) throws ServletException {
        //no-op
    }

    public void destroy() {
        //no-op
    }
}

You can see from the listing, that the filter stores the flash scoped parameters in a session scoped map called FLASH_SESSION_KEY. Before the request is processed by the filter chain, the flash attributes are retrieved from the session and added to request scope; after the chain has finished, any new flash scoped parameters are stored in a new session scoped map.

Note that the attributes have the ‘flash.‘ prefix removed when added to the session scoped map – this not only ensures that they can be accessed using their ’short name’, but that they are only kept in the session for one extra request.

This approach is not Spring specific and should work with and Java Web framework. I’ve omitted the configuration for the filter as there are loads of examples of how to do this on the Internet already.

I needed to do this recently and it took me a while to find out how to do it in the Log4J docs, so I though I’d make a note of how to do it here.

To specify a file that Log4J will use instead of the default, pass its details as a system property when starting the JVM as follows:

java -Dlog4j.configuration=resources/log4j_dev.properties

The above example will load the log4j_dev.properties file from within the resources folder in the classpath. A file URL may also be specified:

java -Dlog4j.configuration=file:/resources/log4j_dev.properties

This will cause the log4j_dev.properties file to be loaded from the resources folder at the root of the file system.

It turns out that this is a problem with the JDK’s plugin.jar file and can be fixed quite easily by removing it from IntelliJ’s JDK configuration page as follows:

1. In your project open the Project Structure dialog and click to edit the JDK you are working with
2. Remove the plugin.jar file from the JDK classpath

That should fix it.

What is Open Session in View?

The Java Persistence API (JPA) allows an object oriented model to be mapped to a relational database. JPA is a standard specification for Java based Object Relational Mapping frameworks – in order to use JPA an underlying implementation must be available; the most common choice being Hibernate.

Both JPA an Hibernate support lazy loading of data to restrict the number of queries fired off to the database. In general this means that data will be loaded on demand when methods are called, on a loaded object, that require more data to be loaded. In order for this to work, the object that the method is called on must have been loaded by JPA and be part of the current running transaction.

In a Spring application, calls to demarcate transactions are generally handled by the Spring interceptors.Transactions are normally started when a method call is made on a Spring managed object and committed once that method call ends. This means that if a JSP page requests data by calling a transactional method on a Spring managed bean, then it can only access the data in that bean that has already been loaded within that call. Any calls for data that might be loaded lazily will fail because the object is no longer attached to a JPA transaction after that method call has returned.

Hibernate developers solved this problem using the Open Session in View design, which associates the active session (and hence it’s transaction) with the thread that makes the call. In this design, the transaction will be committed when the thread completed processing the request, rather than when a method call completes. This allows lazily loaded data to be loaded within the JSP page not just within Spring managed objects.

Providing Request Scoped Transactions

A standard way to intercept requests in any Java Web application is to use a web filter. Spring provide an out-of-the-box Web filters that implement the Open Session in View design for both Hibernate and JPA. We will see the JPA version here, but the Hibernate one works in just the same way; just change the class name in the configuration file.

In web.xml:

<filter>
    <filter-name>oemInViewFilter</filter-name>
    <filter-class>
        org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter
    </filter-class>
    <init-param>
        <param-name>entityManagerFactoryBeanName</param-name>
        <param-value>reportsEntityManagerFactory</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>oemInViewFilter</filter-name>
    <url-pattern>*.jsp</url-pattern>
</filter-mapping>

The filter class is from the Spring framework libraries. The filter mapping, in this example, applies this filter to all URLs ending with ‘.jsp’; this means that all JSPs that retrieve a lazily loaded object form the service tier of the application are now free to read any data members from it – any unloaded data will be loaded from the database when calls are made to access it.

Be aware that the filter turns off the auto-flush behaviour of the standard entity manager. This means that any changes that are made to the data in the JSP will not be persisted. The filter can be configured to flush these if requested.

Finally, the init-param that’s provided to the filter is optional and can be used to explicitly name the entity manager factory that will be used. The example shows how to use an entity manager named ‘reportsEntityManagerFactory’ in the Spring configuration files; the default value for this is ‘entityManagerFactory’.

One common problem faced when unit testing is how to test one object when it is dependant on another object. You could create instances of both the object under test and the dependent object and test them both together, however testing aggregated objects is not what unit testing is about – unit tests should test individual objects for their correct behaviour, not aggregations of objects! Moreover, this approach just won’t work if the dependent object hasn’t even been implemented yet.

A common technique for handling dependencies in unit tests is to provide a surrogate, or “mock” object, for the dependent object instead of a real one. The mock object will implement a simplified version of the real objects methods that return predictable results and can be used for testing purposes.

The drawback of this approach is that in a complex application, you could find yourself creating a lot of mock objects. This is where frameworks like Mockito can save you a lot of time and effort.

A Test Scenario

To demonstrate what you can do with Mockito, we’ll examine how we might test an Account object that is dependant on a data access object (AccountDAO).  The account object can calculate the charges applicable in the current month by using the DAO to count the number of days overdrawn and then performing a simple calculation on the value obtained from that call. The method names on the classes we’ll use are self-explanatory:

To test this thoroughly, we should test two things:

1. that the account obtains the number of overdrawn days by calling the correct method on the DAO,
2. that the account calculates the correct fees based upon the value it gets back from the call.

Testing that the account calls the correct method on the DAO

Using JUnit to run the test case, we could write something like this:

import static org.mockito.Mockito.*;

public class TestAccount {
    @Test
    public void checkAccountCallsDaoMethods() {
        //create the object under test
        Account account = new Account();

        //create a mock DAO
        AccountDAO mockedDao = mock(AccountDAO.class);	

        //associate the mocked DAO with the object under test
        account.setDAO(dao);

        //call the method under test
        long charge = account.calculateCharges();

        //verify that the 'countOverdrawnDaysThisMonth' was called
        verify(mockedDao).countOverdrawnDaysThisMonth();
    }
}

Taking centre stage in all this is the Mockito class which has a bunch of static methods that are used within the unit test (note the static import on line 1).

The call to the ‘mock’ method (line 10) creates a mock object that can be used in place of a real AccountDAO. The call to ‘verify’ (line 19), will throw an exception if the ‘countOverdrawnDaysThisMonth’ method was not called on the mock object.

It is worth noting here that this is a simple example which just demonstrates the basic principle of verification, it is also possible to use the verify method to check for parameter values and ranges in the method call too.

Testing that the account performs its calculations correctly

In the above example, we mocked the DAO but didn’t specify what any of the mocked methods should do. In this case, all methods will return sensible default values of: null, zero or false. More commonly we need to specify something other than these defaults when writing our tests:

import static org.mockito.Mockito.*;
import static junit.framework.Assert.*;
import org.junit.*;

public class TestAccount {
    private Account account;

    @Before
    public void setup() {
        AccountDAO mockedDao = mock(AccountDAO.class);

    	//specify that this method on the mock object should return 8
        when(mockedDao.countOverdrawnDaysThisMonth()).thenReturn(8);

        account = new Account();
        account.setDAO(dao);
    }

    @Test
    public void checkChargesWhenOverdrawn() {
        //call the method under test
        long charge = account.calculateCharges();

        //assert that the charge was £2 per day overdrawn
        assertEquals(charge, 16);
    }
}

The statement on line 18 specifies that whenever the ‘countOverdrawnDaysThisMonth’ is called it should return a value of 8; overriding the default of zero.

Given that the correct charge is two pounds (or dollars) per day overdrawn, then the assertion on line 25 will pass if the account performed the correct calculation (8 x 2 = 16 right).

Comments

There’s loads more to Mockito than we’ve looked at here. It’s a neat testing tool that works great with JUnit or TestNG. I’ve found that it’s small enough to learn quickly and capable enough to be really useful. Give it a go and write a comment below to let me know what you think of it.

The assert keyword was introduced in Java 1.4 and has since been a sadly under-used language feature. Assertions offer developers a neat way to implement error detecting statements that are only active during development and can be turned off in production environments.

For example you might want to check that appropriate values are passed to a method during development to ensure that it is being called correctly:

private void onlyPositiveNumbersPlease(int i) {
    assert i > 0;

    //rest of method implementation...

}

If the assertion fails, then an AssertionError is thrown. If you have a lot of assertions in your code, then its useful to be able to specify a value that will be used in the error message:

private void onlyPositiveNumbersPlease(int i) {
    assert i > 0 : "only positive numbers are allowed";

    //rest of method implementation...

}

The value that is specified can also be any primitive type, for example:

File f = loadFile();
assert f != null : 404;

In all cases, the value is converted to a String and set as the detail message of the AssertionException.

When the Java source is compiled, assertions instructions are included in the bytecode that is generated. However, by default, the assertions are not executed at runtime.

In order to activate all of the assertions, a command line flag must be passed to the JVM:

$ java -ea co.uk.smartkey.ui.MainClass


it is also possible to specify that assertions should only be activated for classes within a certain package. For example to run the same application as before, but only activate assertions for classes in the util package of our application, you could use something like:

$ java -ea:co.uk.smartkey.util co.uk.smartkey.ui.MainClass


if you just wanted to turn on assertions for a single class, you can specify the class name instead of the package name. Finally, if you really feel the need to, you can turn on assertions in the Java system classes with this:

$ java -esa co.uk.smartkey.ui.MainClass


Personally, I like using assertions as they can help to iron out problems during development that are unlikely to need checking for in production. Language level support for them means that the statements are only used if the JVM is launched with them activated; this ensures that there is no performance overhead associated with them when they are not in use.

Some things in Java seem to be a whole lot trickier than they need be, and working with dates is a good example of this. The Date class’ primary purpose is storing date values. For date oriented calculations the Calendar class should be used. The calendars will handle tricky problems like leap years but the methods for doing this operate at a low level and in many cases you still need to do some of the calculations for yourself. In addition to the standard classes, there’s some great support for working with dates provided in the Apache commons libraries; these libraries don’t provide a method for counting days between two dates though.

Anyway, to cut to the chase, here’s the solution I came up with:

public class DateTools {
    private static final int MILLISECONDS_IN_DAY = 1000 * 60 * 60 * 24;

    /**
     * Calculates the number of days between start and end dates, taking
     * into consideration leap years, year boundaries etc.
     *
     * @param start the start date
     * @param end the end date, must be later than the start date
     * @return the number of days between the start and end dates
     */
    public static long countDaysBetween(Date start, Date end) {
        if (end.before(start)) {
            throw new IllegalArgumentException("The end date must be later than the start date");
        }

        //reset all hours mins and secs to zero on start date
        Calendar startCal = GregorianCalendar.getInstance();
        startCal.setTime(start);
        startCal.set(Calendar.HOUR_OF_DAY, 0);
        startCal.set(Calendar.MINUTE, 0);
        startCal.set(Calendar.SECOND, 0);
        long startTime = startCal.getTimeInMillis();

        //reset all hours mins and secs to zero on end date
        Calendar endCal = GregorianCalendar.getInstance();
        endCal.setTime(end);
        endCal.set(Calendar.HOUR_OF_DAY, 0);
        endCal.set(Calendar.MINUTE, 0);
        endCal.set(Calendar.SECOND, 0);
        long endTime = endCal.getTimeInMillis();

        return (endTime - startTime) / MILLISECONDS_IN_DAY;
    }
}

As you can see each of the dates passed to this method are converted into milliseconds and the number of days between them is calculated based upon the number of days this equates to.

In order to ensure that the times are not relevant in the dates, these are set to zero. This means that if the start date is at 11:00 PM, and the end date is at 1:00 AM the next day, you’ll still get one day returned from this method call, rather than zero.

The basics

To define an inner class, just define one class within another:

public class Outer {
    public class Inner {

    }
}

Generally, the outer class will be responsible for creating instances of the inner classes and this could be done in the methods of the outer class, for example here where the outerClassesMethod creates an inner class instance and calls its method (lines 7-8) :

public class Outer {

    private String message = "foo";

    public void outerClassesMethod() {
        //create an inner object to do the work
        Inner ii = new Inner();
        ii.innerClassesMethod();
    }

    private class Inner {
        private void innerClassesMethod() {
            System.out.println(message);
        }
    }
}

Note above that the inner classes method (line 12), although private, can still be called by the outer class. Also note that the private message field on the outer class (line 3) can be accessed from the inner class. A call to the outerClassesMethod will cause the innerClassesMethod to be called and the message ‘foo‘ to be printed to std out.

What about ‘this’ ?

Each object in a Java application can refer to itself using the ‘this’ reference. When an instance of an inner class is created, it is created within the instance that created it; so what effect does this have on ‘this’ reference?

In fact, inner class instances have more than one ‘this’ reference: one that refers to the instance of the inner instance, and one that refers to the outer instance. Consider this simple change to the example:

public class Outer {

    private String message = "foo";

    public void outerClassesMethod() {
        //create an inner object to do the work
        Inner ii = new Inner();
        ii.innerClassesMethod();
    }

    private class Inner {
        private String message = "bar";

        private void innerClassesMethod() {
            System.out.println(message);
        }
    }
}

Now that the inner class also has a field named message, the text ‘bar‘ will be printed out instead of ‘foo’.

The reason for this is that the inner classes message field has shadowed the outer classes one. The inner classes println call (line 15) would have the exact same behaviour if it were written as:

System.out.println(this.message);

if we want to access the message field on the outer class, then we need to use a ‘this’ reference for the outer instance; we do this by pre-pending the class name to ‘this’ as follows:

System.out.println(Outer.this.message);

substituting the println statement with the one shown above, will access the message field on the Outer class and cause ‘foo‘ to be printed out once again.

Creating inner instances from outside the outer class

As noted above, the inner instances will generally be created within the outer class. However, it is possible for inner instances to be created in other places too; for example, a factory class could be used to create the outer objects and also the inner objects that they will contain.

To demonstrate this scenario, we’ll use a slightly revised example where the inner class, and its method, have been made publicly visible. Note also that the outer class now has a constructor (lines 4-6) that will allow us to initialise its private message field (line 3) :

public class Outer {

    private String message;

    public Outer(String message) {
        this.message = message;
    }

    public class Inner {
        public void innerClassesMethod() {
            System.out.println(message);
        }
    }
}

If our factory class is to create the inner class instances, then it must associate them with an outer instance. In order to do this the new keyword must be scoped to a particular outer instance using this somewhat cumbersome syntax:

Outer o = new Outer("foo");
Outer.Inner i = o.new Inner();
i.innerClassesMethod();

Note the use of the new keyword (line 2) is prepended with the outer object reference (i.e. o.new). It is this outer reference that will be accessible within the inner object’s methods using the ‘this’ syntax explained above.

So, when the call to the inner classes method is made (on line 3), the private message field of the outer instance will be printed out – i.e. we’ll see ‘foo‘ appear in std out.

Static inner classes

The static modifier can be applied to member level classes in much the same was as it can with the fields and methods of that class. As with fields and methods, use of the static modifier pretty much turns off OO.

public class Outer {

    private String message;

    static class Inner {
        private String message;

        public void innerClassesMethod() {
            //can access the message field defined on this class:
            System.out.println(this.message);

            //can't access the one from the outer class though:
            System.out.println(Outer.this.message);
        }
    }
}

In much the same way as a static method is not associated with an object instance, objects created from static inner class definitions are not associated with an outer object instance either.

Static inner classes therefore do not have a second this reference, and cannot access the non-static fields of the outer class (line 13 in the above example would produce a compiler error). Effectively, inner classes are just regular classes defined within an outer classes name-space.