我目前正在设计应用程序配置。 应用程序将利用Spring,可以仅使用其XML bean上下文配置,但是需求设置为在其旁边具有一些分层XML配置。这将使用applicationContext中指定的bean。
例如,给出以下内容:
的applicationContext.xml:
<bean id="A" class="" init-method="">
<property name="namespace" value="${namespace}"/>
</bean>
<bean id="B" class="" init-method="">
<property name="restTemplate" ref="restTemplate"/>
</bean>
config.xml中:
<configuration>
<consumers-config>
<consumers>
<!--A consumer should be first defined in another configuration file-->
<consumer bean-name="A">
<name>A-1</name>
<namespace>...</namespace>
</consumer>
<consumer bean-name="B">
<name>B-1</name>
</consumer>
</consumers>
</consumers-config>
<works>
<work name="1">
<consumers>
<consumer>A-1</consumer>
<consumer>B-1</consumer>
</consumers>
</work>
</works>
<configuration>
从上面可以看出,config.xml引用了很多applicationContext,有效地使后者成为依赖。
需要进行分层配置是允许用户修改此类配置,而无需触及applicationContext。
这是一个理想的情况吗?是否有我应该考虑的最佳做法?换句话说,解决这个问题的最佳方法是什么?
答案 0 :(得分:2)
这是否是一个可用的解决方案在很大程度上取决于您的情况和您的用户。用户直接编辑applicationContext.xml会出什么问题?如果它仅用于文件中的组织,以便您知道哪个文件可以找到哪些设置,并且您自己的特殊XML语法更具可读性,那么您也可以简单地使用<import>
标记来包含另一个spring xml配置可由用户编辑的文件。您还可以create your own XML namespace,这样您就可以在此文件中使用自己的XML格式,从而可能使该文件更具可读性。
但是,如果您将这些文件分开的动机是文件可以独立维护,并且不了解applicationContext.xml的用户可以编辑该文件,或者如果用户可以编辑该文件则存在安全问题,那么这个解决方案就是个问题。您当然可以通过指定明确的bean列表来解决这个问题,这些bean类似于config.xml文件的编辑器可用的接口,并在XML文件上运行验证以确保仅使用您的命名空间(可能不包含标签可能存在安全风险)并且还验证只有bean名称是在API中发布的引用,但它会使维护更加困难并增加安全问题的风险。然而,在这种情况下提出更好的解决方案需要更深入地了解您的要求实际是什么以及您想要实现的目标。