我有两个使用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”运行控制台项目,它仍将针对打包的任何配置文件运行客户端。能够打包所有属性文件并让客户端在相同的配置文件中运行它将是非常方便的。这可能/一个好主意吗?
答案 0 :(得分:1)
广告1:放置基于JAR的XML上下文的常见位置在META-INF/your/project/name
文件夹中。您可以查看示例spring-batch-admin项目。此外,现在命名上下文文件 {name} -context.xml (例如 central-context.xml )更为常见。
通过遵循上述建议,您不应该遇到名称冲突问题。但是,应该可以通过在 import 定义中使用classpath*
伪协议来克服此类问题:
<import resource="classpath*:do/not/put/in/root/this-can-be-duplicate.xml"/>
广告2:这完全合法。您可以在上面链接的Spring Batch Admin示例中看到相同的实践。只需将classpath:
或classpath*:
添加到资源路径。
广告3:这很奇怪,我不知道那里发生了什么。
广告4 :可以通过Spring profiles(不是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"/>
更新刚刚发现<context:property-placeholder>
有problems with SPeL。但是,在手动定义PropertyPlaceholderConfigurer
时(例如,通过<bean>
),您仍然可以使用SPeL(甚至其他属性配置程序)。