Application-wide configuration of Lambdaj FinalClassArgumentCreators. Where and how to do it?

Question

We have a problem with configuring lambdaj to work with Joda Time. Since LocalDate is a final class, Lambdaj needs to be initialized like following: (see bug 70)

public class LocalDateArgumentCreator implements FinalClassArgumentCreator<LocalDate> {
    private final long MSECS_IN_DAY = 1000L * 60L * 60L * 24L;
    public LocalDate createArgumentPlaceHolder(int seed) {
        return new LocalDate((long)seed * MSECS_IN_DAY);
    }
}
ArgumentsFactory.registerFinalClassArgumentCreator(LocalDate.class, new LocalDateArgumentCreator());

Since we need this configuration to be applied virtually everywhere, we are short of options on how to implement this. Our application is a web application based on Spring and Wicket.

I have come up with three different options:

1. Static initialization block in the core maven module

Since the core module is included in every other module, all modules would include the class. The remaining question is that do static blocks always get initialized even if there are no references to the target class?

Example

public final class LambdajInitializer {
    static {
        // initialize like above
    }
}

2. An initializing bean in applicationContext.xml

Downside: never gets initialized for non-Spring tests

Example: In applicationContext-core.xml (included in every module)

<bean class="...LambdajInitializer" />

public class LambdajInitializer {
    @PostConstruct
    public void init() {
        // Lambdaj initialization
    }
}

3. A call to a initializing method in the Wicket application class

Downside: never gets initialized outside the web module

public class MyApplication extends WebApplication {
    @Override
    public void init() {
        ...
        // Lambdaj initialization
        ...
    }
}

My question is: which is the preferable way to achieve this?

Answer 1

1. I would avoid static initialization as you may have (how unlikely is your call) modules in future which won't need this kind of initialization. I do not fancy static inits.
2. It is a reasonable approach, you can place this initialization in a @Before section of your non-spring unit tests
3. Like for 2., you can initialize the code in your @Before sections.

Option 4. you could create a test-only Spring configuration class/file and pass it on to your tests using @ContextConfiguration