Cosmin Cremarenco – Cosmin's Blog

Activate logging in Hibernate

Logging is extremely well done in hibernate and can be quite useful in case of problems.

Hibernate uses slf4j to perform logging. Slf4j is just a facade for logging and uses an underlying system to actually perform logging. One can use whatever logging system wishes, it basically depends on personal preferences and whatever you’re more familiar configuring.

For this example I choose log4j 1.2, but log4j 2, logback etc are also possible.

In order to enable logging through log4j1.2 you should have the following dependency in your pom.xml:

<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-log4j12</artifactId>
   <version>1.7.25</version>
</dependency>

</dependency>

Above I use version 1.7.25 which is the latest at this time, but older versions should work as well.

Log4j is configured through a log4j.properties file that you should put in your resources folder (that can be under either src/main or test/main depending if you wish to use it for production logging or only in a test setting).

Here’s a sample of a log4j.properties that activates sets the rootLogger to INFO level only, but activates the DEBUG level for hibernate. Warning! it’s not exactly the TRACE level, but it can still yield a lot of output.

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%c] - %m%n

log4j.rootLogger=info, stdout

log4j.logger.org.hibernate=debug

log4j.appender.stdout=org.apache.log4j.ConsoleAppender

log4j.appender.stdout.Target=System.out

log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

log4j.appender.stdout.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%c] - %m%n

log4j.rootLogger=info, stdout

log4j.logger.org.hibernate=debug

The correct JPA provider for hibernate

While working with hibernate you will sometimes have an error message like the following:

javax.persistence.PersistenceException: No Persistence provider for EntityManager named <YOUR PERSISTENT UNIT NAME>

One of the possible causes for this is that the provider for hibernate in your persistence.xml is wrong. In various places on the web it is suggested that it should be: org.hibernate.ejb.HibernatePersistence

Putting the one above results in the obscure exception above.

To fix this enter the correct provider for hibernate: org.hibernate.jpa.HibernatePersistenceProvider

SecureRandom gotcha

If you need a random number you are usually advised to use SecureRandom because it gives a cryptographically secure random number.

Typical way of calling SecureRandom would be:

SecureRandom secureRandom = new SecureRandom();
byte bytes[] = new byte[16];
secureRandom.nextBytes(bytes);

SecureRandom secureRandom = new SecureRandom();

byte bytes[] = new byte[16];

secureRandom.nextBytes(bytes);

From a random generator seeding perspective this is also the correct way. You might be tempted to call the setSeed in order to seed with some long that you provide. Resist that temptation unless you can prove that the seed obeys the constraints of your application (like that it is different between different instantiations and invocations of SecureRandom). And no, seeding with the System.currentTimeMillis() will not work: multiple threads can get the same value.

Here’s an excerpt from the setSeed documentation:

/**
 * Reseeds this random object, using the eight bytes contained
 * in the given {@code long seed}. <strong>The given seed supplements</strong>,
 * rather than replaces, the existing seed. Thus, repeated calls
 * are guaranteed never to reduce randomness.
 *
 * &lt;p&gt;This method is defined for compatibility with
 * {@code java.util.Random}.
 *
 * @param seed the seed.
 *
 * @see #getSeed
 */

/**

* Reseeds this random object, using the eight bytes contained

* in the given {@code long seed}. <strong>The given seed supplements</strong>,

* rather than replaces, the existing seed. Thus, repeated calls

* are guaranteed never to reduce randomness.

* <p>This method is defined for compatibility with

* {@code java.util.Random}.

* @param seed the seed.

* @see #getSeed

The interesting part here is that it says that the seed “supplements” the internal seed. This is not what I found. The given seed will completely replace the internal seed. This means that when seeded the same way two SecureRandom will return the same value. Probably not what you would expect.

SecureRandom secureRandom1 = new SecureRandom();
secureRandom1.setSeed(1L);
byte[] bytes1 = new byte[16];
secureRandom1.nextBytes(bytes1);

SecureRandom secureRandom2 = new SecureRandom();
secureRandom2.setSeed(1L); // Same seed here.
byte[] bytes2 = new byte[16];
secureRandom2.nextBytes(bytes2);

assertTrue(Arrays.equals(bytes1, bytes2)); // This assertion is correct.

SecureRandom secureRandom1 = new SecureRandom();

secureRandom1.setSeed(1L);

byte[] bytes1 = new byte[16];

secureRandom1.nextBytes(bytes1);

SecureRandom secureRandom2 = new SecureRandom();

secureRandom2.setSeed(1L); // Same seed here.

byte[] bytes2 = new byte[16];

secureRandom2.nextBytes(bytes2);

assertTrue(Arrays.equals(bytes1, bytes2)); // This assertion is correct.

Emacs is awesome!

Here’s an elisp function that will just underline your current text. It’s simple, awesome and I use it all the time for my titles. You can put it in the *scratch* and do a C-x C-e and then call it with M-x add-underlining.

(defun add-underlining ()
  "Underline titles with an equal sign"
  (interactive (save-excursion
                 (let* ((initial-line (line-number-at-pos))
                        (end-of-line)
                        (end-col (current-column))
                        (s (make-string end-col ?=)))
                   (interactive)
                   (forward-line 1)
                   (if (= initial-line (line-number-at-pos))
                       (progn (newline)
                              (insert s))
                     (insert s))))))

(defun add-underlining ()

"Underline titles with an equal sign"

(interactive (save-excursion

(let* ((initial-line (line-number-at-pos))

(end-of-line)

(end-col (current-column))

(s (make-string end-col ?=)))

(interactive)

(forward-line 1)

(if (= initial-line (line-number-at-pos))

(progn (newline)

(insert s))

(insert s))))))

JUnit Argument Captor — enhance your mock testing

When writing mock tests it is, sometimes, more convenient to assert the values with which the methods were called using the ArgumentCaptor
class instead of the more usual mock verify.
Let’s see both in action.

We’ll take as sample a mock of the List interface.

List<String> myList = mock(List.class);

List<String> myList = new MyList<String> ();
myList.add ("one");
myList.add ("two");
myList.add ("three");

List<String> myList = mock(List.class);

List<String> myList = new MyList<String> ();

myList.add ("one");

myList.add ("two");

myList.add ("three");

Let’s see how verify-ing would work:

verify (myList).add ("one");
verify (myList).add ("two");
verify (myList).add ("three");

verify (myList).add ("one");

verify (myList).add ("two");

verify (myList).add ("three");

Or since we expect those to be called in that same exact order we could also:

InOrder order = Mockito.inOrder (myList);
order.verify (myList).add ("one");
order.verify (myList).add ("two");
order.verify (myList).add ("three");

InOrder order = Mockito.inOrder (myList);

order.verify (myList).add ("one");

order.verify (myList).add ("two");

order.verify (myList).add ("three");

Now let’s use ArgumentCaptor instead:

ArgumentCaptor<String> argumentCaptor = ArgumentCaptor.forClass (String.class);
verify (myList).add (argumentCaptor.capture ());
assertEquals (Arrays.asList ("one", "two", "three"), argumentCaptor.getAllValues ());

ArgumentCaptor<String> argumentCaptor = ArgumentCaptor.forClass (String.class);

verify (myList).add (argumentCaptor.capture ());

assertEquals (Arrays.asList ("one", "two", "three"), argumentCaptor.getAllValues ());

That seems more streamlined and readable IMO. As you can see the ArgumentCaptor will catch all arguments with which it was called.

If you expect a single value to be captured or if you’re only interested in the last value with which your method was called you can also call:

argumentCaptor.getValue();

1	argumentCaptor.getValue();

In our case that call will return “three”.

JUnit Categories

Hey there, this is my second post on JUnit and its lesser known features. To read the first one go here.

JUnit Categories allow tagging tests thus dividing the tests into separate buckets. This, in turn, becomes important in order to choose which tests run at a later time.

I find categories in combination with maven quite useful in splitting tests into unitary and integration tests. This is probably better understood with an example.

package com.cremarenco.junit.categories;

// Marker interface for integration tests.
public interface IntegrationTest {
}

public class DownloaderTest {
    @Test
    @Category(IntegrationTest.class)
    public void download_file() {
        // Slow integration tests.
    }
}

package com.cremarenco.junit.categories;

// Marker interface for integration tests.

public interface IntegrationTest {

}

public class DownloaderTest {

@Test

@Category(IntegrationTest.class)

public void download_file() {

// Slow integration tests.

}

Following maven config will split the tests into unitary tests and integration tests. Note how we’re using surefire for the unitary tests and failsafe for the integration tests. We could have used surefire all the way and by all means do if you only have unitary tests. However, failsafe makes sure that failing tests are torn down correctly and that the post-integration-test phase (that comes after the integration-test) is called. The surefire plugin would just stop everything during the integration-test phase. But, anyways, this is maybe an article for another time. Here’s the example:

<build>
    <plugins>
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <excludedGroups>com.cremarenco.junit.categories.IntegrationTest</excludedGroups>
            </configuration>
        </plugin>
        <plugin>
            <artifactId>maven-failsafe-plugin</artifactId>
            <configuration>
                <groups>com.cremarenco.junit.categories.IntegrationTest</groups>
            </configuration>
        </plugin>
    </plugins>
</build>

<build>

<artifactId>maven-surefire-plugin</artifactId>

<excludedGroups>com.cremarenco.junit.categories.IntegrationTest</excludedGroups>

</configuration>

</plugin>

<artifactId>maven-failsafe-plugin</artifactId>

<groups>com.cremarenco.junit.categories.IntegrationTest</groups>

</configuration>

</plugin>

</plugins>

</build>

In order to skip the integration tests you can add -DskipITs command line parameter to the maven invocation.

JUnit Rules

We all know testing is good for our health right? “Testing rocks, debugging sucks”, I think the good guys at google said it.

When in Java when writing unitary tests, we use JUnit most of the time. JUnit is a *wealth* of features which are mostly unexplored and that can truly make test writing easier and more enjoyable.

I’m planning to write a series on the hidden or the lesser known JUnit.

And the first one today is: Rules.

What Rules allow is, in a word, to run code that wraps the test code under execution. In many cases that’s just code that
initializes and destroys some helper objects that you need in the testing code. So why wouldn’t you put that in methods annotated with @Before/@After? The answer is convenience.

An example is worth 1000 words. Let’s see how @Rule TemporaryFolder is used.

public class FileDownloaderTest {
	@Rule
	public TemporaryFolder temporaryFolder = new TemporaryFolder();

	@Test
	public void testWeCanDownloadFiles() {
		File targetFile = temporaryFolder.newFile("download.zip");
		
		// Exercise an imaginary FileDownloader class.
		FileDownloader fileDownloader = new FileDownloader(targetFile);
		fileDownloader.download("url-to-download");
		
		// Here assert that targetFile contains the correct contents.
		
		// At the end of the test targetFile is automatically removed.
	}
}

public class FileDownloaderTest {

@Rule

public TemporaryFolder temporaryFolder = new TemporaryFolder();

@Test

public void testWeCanDownloadFiles() {

File targetFile = temporaryFolder.newFile("download.zip");

// Exercise an imaginary FileDownloader class.

FileDownloader fileDownloader = new FileDownloader(targetFile);

fileDownloader.download("url-to-download");

// Here assert that targetFile contains the correct contents.

// At the end of the test targetFile is automatically removed.

}

What’s nice about the @Rule in the example above is how the TemporaryFolder functionality is encapsulated, brought up and torn down for each test.

Rules classes like the TemporaryFolder that we just saw need to inherit interface TestRule which only contains the method below:

public interface TestRule {
    Statement apply(Statement base, Description description);
}

public interface TestRule {

Statement apply(Statement base, Description description);

}

In the above, the base parameter represents the actual test code. Calling base.evaluate() will trigger the test.

However implementing the TestRule directly is awkward. A more useful class is ExternalResource (which TemporaryFolder also inherits and specializes for temporary files). This allows using in the test code a resource which is initialized/destroyed. As example, say we wanted to use in our test an http client.

public class HttpClientResource extend ExternalResource {
    private final HttpClient httpClient;
	
    public HttpClientResource(String address) {
	this.httpClient = new HttpClient(address);
    }

    public Statement apply(Statement base, Description description) {
        return statement(base);
    }

    private Statement statement(final Statement base) {
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
				httpClient.connect();
                try {
                    base.evaluate();
                } finally {
                    httpClient.close();
                }
            }
        };
    }
}

public class HttpClientResource extend ExternalResource {

private final HttpClient httpClient;

public HttpClientResource(String address) {

this.httpClient = new HttpClient(address);

}

public Statement apply(Statement base, Description description) {

return statement(base);

}

private Statement statement(final Statement base) {

return new Statement() {

@Override

public void evaluate() throws Throwable {

httpClient.connect();

try {

base.evaluate();

} finally {

httpClient.close();

}

};

}

And to use this rule in an actual test:

public class HttpClientTest {
	@Rule
	HttpClientResource httpClientResource = new HttpClientResource("localhost:8080");
	
	@Test
	public void can_download_index_html() {
		File file = httpClientResource.download();
	}
}

public class HttpClientTest {

@Rule

HttpClientResource httpClientResource = new HttpClientResource("localhost:8080");

@Test

public void can_download_index_html() {

File file = httpClientResource.download();

}

There are a bunch of other @Rule that ship with JUnit which be tremendously useful:

TemporaryFolder – as described above, makes dealing with temporary files pretty painless
ExternalResource – generalizes resource set up and tear down
ErrorCollector – allows test to continue even after the first problem occurs; the purpose here is to collect all problems in one go
Verifier – do checks *after* the test has run and was successful
TestWatcher – offers hooks into tests passing or failing; can, for instance, be used in order to make a log of tests that passed/failed
TestName – makes possible to have the current test name accessible inside the test itself
TimeoutRule – enforce a timeout for the whole test execution
ExpectedException – allows specifying exceptions that are allowed to be thrown from the test body. This can also be implemented using the “expect” parameter of the @Test annotation, but I find the ExpectedException easier to use than writing an annotation array
ClassRule – applies the same lifecycle as the standard @Rule, but this time to the whole fixture
RuleChain – used to order rules

I hope this was a good introduction to rules and that you will put them to good use in your tests.

My Swift strings cheatsheet

The Swift strings support representing Unicode strings natively. As such it is no longer possible to have random access inside the string because some characters might be represented on more than one byte.

I always forget how to do basic things so I put together a cheatsheet that might be useful to others too.

Counting characters

print("abc".characters.count) // 3
print("abc".utf8.count) // 3
print("abc".utf16.count) // 3

print("abc".characters.count) // 3

print("abc".utf8.count) // 3

print("abc".utf16.count) // 3

Lowercasing/uppercasing

print("ABC".lowercaseString) // abc
print("aBC".uppercaseString) // ABC

1 2	print("ABC".lowercaseString) // abc print("aBC".uppercaseString) // ABC

Iterating through the string characters

// Prints a b c
for c in "abc".characters {
print(c)
}

// Prints 0 1 2
for i in "abc".characters.indices {
print(i)
}

// Prints a b c

for c in "abc".characters {

print(c)

}

// Prints 0 1 2

for i in "abc".characters.indices {

print(i)

}

Indexes inside the string

print("abc".endIndex) // 3
print("abc".startIndex) // 0</code>

print("abc".startIndex.successor()) // 1
print("abc".endIndex.predecessor()) // 2
print("abc".startIndex.advancedBy(2)) // 2

"abc".startIndex.predecessor() // Runtime error
"abc".endIndex.successor() // Runtime error

print("abc".endIndex) // 3

print("abc".startIndex) // 0</code>

print("abc".startIndex.successor()) // 1

print("abc".endIndex.predecessor()) // 2

print("abc".startIndex.advancedBy(2)) // 2

"abc".startIndex.predecessor() // Runtime error

"abc".endIndex.successor() // Runtime error

Is string contained in another string

print("abc".rangeOfString("bc")) // Optional(Range(1..<3))</code>

// Or make an extension to String
extension String {
func contains(find: String) -> Bool {
return self.rangeOfString(find) != nil
}
}

print("abc".rangeOfString("bc")) // Optional(Range(1..<3))</code>

// Or make an extension to String

extension String {

func contains(find: String) -> Bool {

return self.rangeOfString(find) != nil

}

Split a string by separator, iteratively

let testStr = "www.microsoft.com"
func split1(str: String, _ withSep: Character) -> [String] {
    var result = [String]()
    var pos = str.startIndex
    for i in str.characters.indices {
        if str[i] == withSep {
            result.append(str[pos..<i])
            pos = i.successor()
        }
    }
    result.append(str[pos..<str.endIndex])
    return result
}

print(split1(testStr, ".")) // ["www", "microsoft", "com"]
print(split1(".", ".")) // ["", ""]

let testStr = "www.microsoft.com"

func split1(str: String, _ withSep: Character) -> [String] {

var result = [String]()

var pos = str.startIndex

for i in str.characters.indices {

if str[i] == withSep {

result.append(str[pos..<i])

pos = i.successor()

}

result.append(str[pos..<str.endIndex])

return result

}

print(split1(testStr, ".")) // ["www", "microsoft", "com"]

print(split1(".", ".")) // ["", ""]

Split a string by separator, recursively

let testStr = "www.microsoft.com"

func splitRecurse(str: String, _ sep: String, var _ result: [String]) -> [String] {
    if str.characters.count == 0 {
        result.append("")
        return result
    }
    if let pos = str.rangeOfString(sep) {
        result.append(str[str.startIndex..<pos.startIndex])
        return splitRecurse(str.substringFromIndex(pos.endIndex), sep, result)
    } else {
        result.append(str)
        return result
    }
}

func split2(str: String, _ sep: String) -> [String] {
    let ret = [String]()
    return splitRecurse(str, sep, ret)
}

print(split2(testStr, ".")) // ["www", "microsoft", "com"]
print(split2(".", ".")) // ["", ""]
print(split2("..", ".")) // ["", "", ""]

let testStr = "www.microsoft.com"

func splitRecurse(str: String, _ sep: String, var _ result: [String]) -> [String] {

if str.characters.count == 0 {

result.append("")

return result

}

if let pos = str.rangeOfString(sep) {

result.append(str[str.startIndex..<pos.startIndex])

return splitRecurse(str.substringFromIndex(pos.endIndex), sep, result)

} else {

result.append(str)

return result

}

func split2(str: String, _ sep: String) -> [String] {

let ret = [String]()

return splitRecurse(str, sep, ret)

}

print(split2(testStr, ".")) // ["www", "microsoft", "com"]

print(split2(".", ".")) // ["", ""]

print(split2("..", ".")) // ["", "", ""]

Fix UITabBar icon images as alpha-channel

Apple asks that your UITabBar icons be pure alpha-channel images with added anti-alias. That means that usual RGB channel images will just show as a blue square.

So how to go from a normal RGB channel image to a pure alpha-channel. I use Photoshop and there is probably more than one way, but what works best for me is creating a “Gradient map” adjustment layer.

To create a gradient map adjustment layer go to the “Layers” tab and click “Create fill or adjustment layer…” like below.

Afterwards save your image and all should be fine.

Fix putty garbled text after window resize

So you resized your putty window. When going through history, if there are lines which are longer than 80 chars, the default putty window, then just going through the will show the text garbled.

The fix is simple: tell the terminal the new window size. Arguably this should be automatically done by putty, but hey, there’s a workaround. Checkout the stty command.

Pass the cols parameter to specify the new width of the window in columns.

stty cols <width-in-cols>

1	stty cols <width-in-cols>