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.

javax.net.ssl.SSLHandshakeException: renegotiation is not allowed

This rather unhelpful error message can be raised on either the server or the client and indicates that the SSL libraries in Java cannot determine whether the CA that signed the server’s certificate is to be trusted or not. The solution is pretty straight-forward but will differ between client and server.

Error appears in a Java client application

A quick fix to this problem is to add the server’s certificate to the local trust store.  Here’s how to do this:

1. Visit the server using a web browser and click on the navigation bar to see the server’s certificate details.
2. Export/save the X509 certificate to a local .cer file
3. Import the certificate into the local CA trust store using the JDK keytool.

For step 3, given a certificate file called tomcat.cer and assuming that you are using JDK 1.5.0, you could use the following command line instruction:

keytool -import -keystore C:\jdk1.5.0_22\jre\lib\security\cacerts -alias tomcat -file tomcat.cer

For other JDK versions you’ll just need to adjust the above command a little.

Error appears in a Java server application

This is less common but something that I encountered recently when trying to access a Tomcat server that relied on client certificate (client-cert) based authentication. The fix to this is much the same as above except that the certificate for the client should be trusted by the server.

In this scenario the client is sending the certificate to prove their identity and the server needs reassuring that the certificate was issued by a trusted authority. To fix this scenario, repeat the command shown above substituting the CA certificate that is used t0 sign the client-certs.

Note that this change should only be made if you are certain that the CA that signed the clients certificate is trusted!

Different results discovered when using different versions of Java

Note that this exception is only raised by versions of Java 1.6.0_19 or later (SSL renegotiation was disabled in this version). Version 1.6.0_07, for example, just fails quietly and drops the socket connection. Version 1.5.0_20 (on Windows) seemed to work just fine for me.

This took me a while to find a work-around for so I hope this post helps someone.

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.

First you’ll need to find out your network’s HTTP proxy settings. You could ask a network administrator, or just look in your Internet browser settings and figure it out for yourself.

Once you’ve got the details of the proxy, edit Maven’s conf/settings.xml file and enter the proxy details in the proxy element:

<proxy>
    <id>optional</id>
    <active>true</active>
    <protocol>http</protocol>
    <username>proxyuser</username>
    <password>proxypassword</password>
    <host>webproxy.smartkey.co.uk</host>
    <port>8080</port>
    <nonProxyHosts></nonProxyHosts>
</proxy>

Save the changes in this file and try launching Maven again. If it still doesn’t play ball, check the settings with your network admin, make sure that the above XML is uncommented (it’ll be commented in the file that ships with Maven) and try again.

The problem is encountered when the JVM is launched in debug mode and is reported as:

FATAL ERROR in native method: No transports initialized
Transport dt_socket failed to initialize, rc = 509.

Apparently, from looking at reports of this on the Web, this can happen on any operating system. I encountered it on a Windows XP machine and found that the simplest fix was to copy the following two files from the JAVA_HOME/jre/bin folder, to my c:/windows/system32 folder:

dt_socket.dll
dt_shmem.dll

You can also fix this by putting the JRE bin folder at the start of your PATH environment variable. For a more detailed discussion of the problem take a look at this thread on the Sun forums web site.

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.