0

我有两个使用 Maven 的春季项目。第一个是一些 api 的客户端，第二个是一个控制台程序，它部分地利用了该客户端。

我已将客户端打包到一个 jar 中，并在控制台程序的 pom 中引用它。

我已经设法让这个工作，但我对解决方案不是很满意：

1）我遇到的第一个问题是每个上下文 xml 文件都被命名为“applicationContext.xml”。因此，我无法找到任何方法来引用客户端中的上下文文件，而无需将其重命名为其他名称，例如 clientContext.xml。这可行，但还有其他方法可以明确引用它吗？

2）下一个问题是如何从控制台程序中调用clientContext.xml。为此，我添加<import resource="osrdClientContext.xml"/>到控制台程序的 applicationContext.xml 中，这似乎允许它正确找到所有已定义的 bean。我不确定这是否是最佳做法？

3）在clientContext.xml中，我需要引用一个属性文件，所以有行<context:property-placeholder location="classpath:api.properties" />。这在单独运行客户端时有效，但在运行控制台程序时似乎被忽略（或找不到文件）。api.properties 文件位于客户端打包 jar 的根目录中，jar 位于控制台程序的类路径中。我发现的唯一解决方法是将属性文件手动复制到控制台程序中，此时发现它没有任何问题。

4)两个项目都有一个资源目录，其中包含子目录“dev”、“beta”和“prod”。这允许我根据要运行的 Maven 配置文件定义不同的属性。这适用于单个项目，但是当我打包客户端时，它只包含我正在运行的配置文件的属性文件（这是有道理的）。但是，这意味着如果我针对配置文件“beta”运行控制台项目，它仍将针对打包它的任何配置文件运行客户端。能够打包所有属性文件并让客户端在与依赖它的任何配置文件相同的配置文件中运行会很方便。这是可能的/一个好主意吗？

4

1 回答 1

1

广告 1：放置基于 JAR 的 XML 上下文的常见位置是在META-INF/your/project/name文件夹内。您可以检查例如spring-batch-admin项目。现在也更常见的是命名上下文文件{name}-context.xml（例如central-context.xml）。

按照上面的建议，您应该不会遇到名称冲突的问题。但是，应该可以通过在导入定义中使用classpath*伪协议来克服此类问题：

<import resource="classpath*:do/not/put/in/root/this-can-be-duplicate.xml"/>

广告 2：这是完全合法的。您可以在上面链接的 Spring Batch Admin 示例中看到相同的做法。只需将classpath:or添加classpath*:到资源路径即可。

广告 3：这很奇怪，我不知道那里发生了什么。

广告 4：这可以通过Spring 配置文件（不是 Maven 配置文件）来实现：

<beans profile="dev">
    <context:property-placeholder location="classpath:META-INF/dev/my.properties"/>
</beans>

或通过新的SpEL支持：

<context:property-placeholder location="classpath:META-INF/#{systemProperties['my.jvm.property']}/my.properties"/>

但是我喜欢的是拥有一个默认属性，然后让主应用程序能够覆盖它们。这意味着，您的配置将在一个地方，而不是在 JAR 中。您可以通过属性层次结构实现此目的：

<context:property-placeholder location="classpath:META-INF/my-default.properties,classpath*:META-INF/my-optional-overrides.properties"/>

UPDATE刚刚发现SPeL<context:property-placeholder>有问题。PropertyPlaceholderConfigurer但是，在手动定义（即通过）时，您仍然可以使用 SPeL（甚至其他属性配置器<bean>）。

于 2013-10-04T18:27:11.927 回答