Generate a Secure Random Password in Java

Recently I had to generate a random password that met the password security requirements of AWS – 32 characters in length with 1 special character and 1 digit.

Turned out to be a simple enough thing to do in java.

String characters = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789~`!@#$%^&*()-_=+[{]}\\|;:\'\",<.>/?";
String password = RandomStringUtils.random(32, characters);

Just make sure you include the Apache Commons Lang

Source: Generate a Secure Random Password in Java with Minimum Special Character Requirements

Spring Boot component scanning for test libraries

Recently I had an issue where I was trying to use a custom test library I had built in Spring Boot within an existing Spring Boot app. I ran into a weird issue where by using the test library I broke the main app.

The issue was that the main app was trying to initialise the test library before it was ready, it was attempting to autowire beans within it… turned out the issue was because the test library used the same base package naming convention as the main app.

For example, if the main app was com.alanfeekery.app and the test library was com.alanfeekery.test and my application-context.xml looked like this:


<context:component-scan base-package="com.alanfeekery"></context:component-scan>

Then Spring would just go ahead and try configure everything under the package com.alanfeekery, this is bad as the app shouldn’t be configuring the test library. The solution looks like this:


<context:component-scan base-package="com.alanfeekery">
	<context:include-filter type="regex" expression=".*app"/>
	<context:exclude-filter type="regex" expression=".*test"/>
</context:component-scan>

With these include & exclude filters my app no longer scanned into my test library automatically and everything worked as expected.

FYI

Another thing to be aware about, if are including a custom test library in your Spring Boot app, make sure you flag the dependency scope to test this means that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phase.

Here’s an example:


<dependency>
  <groupId>com.alanfeekery</groupId>
  <artifactId>test</artifactId>
  <version>0.0.35</version>
  <scope>test</scope>
</dependency>

Source:

Finding the right Mockito import

I really enjoy working with Mockito, it’s a fantastic mocking framework for Java. However it can be a pain sometimes to know which packages to import for the tests you are writing.

A quick tip is to import everything while writing your tests & mocks like this:

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

Then once you have completed writing your tests use the CTRL+SHIFT+O (it’s CMD+SHIFT+O on Mac) shortcut in Eclipse to breakdown your imported packages to what you actually used.

You’ll end up with something like this:

import static org.mockito.Mockito.doThrow;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;
import static org.mockito.Matchers.anyString;

Much easier yeah? 🙂

Source: Finding import static statements for Mockito constructs