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.

For example using style code 112:

select convert(char(8), birthday, 112) from People

will format the birthday column (with value 19th Feb 1984) as:

19840231

For quick reference, these formatting codes are listed below:

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.

Another common conflicts is a Tree Conflict. Tree conflicts arise when the directory layout of the project changes, and can arise when folders and files are moved, deleted or created. Such conflics will cause a capital ‘C’ to appear in the svn status commands output – these must be resolved before your merge can take place so that svn knows what it should do with the files that will be merged. Note that you should treat these conflicts carefully and ensure that anyone else who may be affected by the changes is happy with the resolution you are about to apply.

Once you’ve agreed on how the conflicts will be fixed, you can use the svn resolve command to determine what action should be taken suring the merge.

For example:

svn resolve --accept mine-full /path/to/folder

indicates that the local changes should be used.

In contrast, if the changes from the server are to be used, then use this:

svn resolve --accept theirs-full /path/to/folder

Be aware that the above instruction will cause the local changes to be lost.

There are a number of different options to select (in addition to mine-full and theirs-full) that give you more control over resolving, or postponing, the conflict. See the excellent SVN manual for deails of these.

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.

It’s not often that changes to MySQL configuration need to be made. This post is, therefore, more a reminder to myself than anything else.

First locate the configuration file. On my Mac I found this empty configuration file had been created as part of the installation process:

/etc/my.cnf

You’ll need super-user privileges to update it. I used:

sudo vi /etc/my.cnf

Enter the configuration settings you require. I wanted to update the maximum packet size so I entered:

[mysqld]
max_allowed_packet=16000000


Then you should be able to stop MySql with:

mysqladmin -u root -p shutdown


Restart it using whatever start script you prefer. To make sure that your changes have taken effect you can print the server variables to the console with:

mysqladmin -u root -p variables


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.