Lambdaj FinalClassArgumentCreators的应用程序级配置。在哪里以及如何进行配置？

Question

我们在配置lambdaj与Joda Time一起工作时遇到了问题。由于LocalDate是一个final类，Lambdaj需要这样初始化：(请参见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());

由于我们需要在几乎所有地方应用这个配置，实现方式有限。我们的应用程序是基于Spring和Wicket的Web应用程序。

我想出了三种不同的选项：

1. 核心Maven模块中的静态初始化块

由于核心模块包含在每个其他模块中，所有模块都将包含该类。剩下的问题是：即使没有对目标类的引用，静态块是否始终被初始化？

示例

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

2.在applicationContext.xml中的初始化bean

缺点：对于非Spring测试永远不会被初始化。

示例：在applicationContext-core.xml中（包含在每个模块中）

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

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

3. Wicket应用程序类中初始化方法的调用

缺点：永远不会在Web模块之外初始化

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

我的问题是：哪种方法更好地实现了这个目标？

- RJo

---

你没有理解问题的关键点... - Atropo

是的，不小心发布得太早了。 - RJo

Answer 1

1. 我建议避免使用 static 初始化，因为你未来可能会有（虽然很少）不需要这种类型初始化的模块。我不太喜欢 static 初始化。
2. 这是一个合理的方法，你可以将初始化放在非 Spring 单元测试的 @Before 部分。
3. 像2.一样，你可以在 @Before 部分初始化代码。

选项4. 你可以创建一个仅用于测试的Spring配置类/文件，并使用@ContextConfiguration将其传递给你的测试。

- Alessandro Santini

---

我并不担心测试，而是担心生产代码。如果初始化没有在测试中完成，测试只会失败，这种情况下使用Lambdaj对LocalDate进行操作。问题是，单元测试可能无法发现问题，因为它在某种程度上取决于执行顺序（在我们的生产环境集群中，其中一个服务器失败而另一个服务器没有失败）。 - RJo

Answer 2

我们得出了以下结论：

1. 对于应用程序的运行时，我们在Wicket应用程序类的init()方法中初始化Lambdaj的FinalClassArgumentCreator。这样，它们几乎肯定会在任何Lambdaj使用之前被初始化。
2. 对于Wicket组件和页面的测试，我们创建了自己的TestApplication类，该类使用与生产应用程序相同的初始化代码。
3. 对于我们的独立批处理作业，我们决定不使用Lambdaj。如果以后决定使用它，我们可能会将初始化提取到Spring实例化的类中。

- RJo