broadleaf电商文档翻译 Merge Configuration 合并配置

Merge configuration is handled through your web.xml file. The merge facility in Broadleaf primarily operates by intelligently mixing one or more Spring application context files. The final merged version of the application context is then passed to Spring for
processing.

There are two different types of applicationContext files that exist in a typical Broadleaf application: core Spring files listed in the

patchConfigLocation

 context param in web.xml, and Spring MVC files listed in the 

contextConfigLocation

 servlet
init param in web.xml. The merge behavior of these two types of files is slightly different.

Merging Core Spring Application Contexts

Broadleaf is capable of intelligently merging beans by providing a specialized 

MergeContextLoader

, which is invoked as a listener by the following configuration in web.xml:
合并配置通过web.xml文件处理。合并设施在阔叶主要经营智能混合一个或一个以上的Spring应用程序上下文文件。最后的合并版本的应用程序上下文通过弹簧进行处理。有一个典型的阔叶应用不同的文件类型：应用存在核心弹簧文件在web.xml thepatchconfiglocation上下文参数列出，和Spring MVC文件在contextconfiglocation servlet初始化参数在web.xml上市。这两种类型的文件的合并行为是略有不同的。

合并核心弹簧应用程序上下文

阔叶能够智能合并豆提供了一个专门的mergecontextloader，调用在web.xml通过以下配置监听器：

<listener>
<listener-class>org.broadleafcommerce.common.web.extensibility.MergeContextLoaderListener</listener-class>
</listener>

This ContextLoader will analyze the contents of all applicationContexts specified in the 

patchConfigLocation

 and do its best to merge properties using two strategies.

Strategy 1: Set/List/Map FactoryBeans

This is the newer of the two strategies used in Broadleaf, and all new configurations are written in this pattern. The easiest way to show this strategy is by example. Let's take a look at some of the configuration that lives in a Broadleaf applicationContext
file:

这contextloader将分析在patchconfiglocation指定所有ApplicationContexts的内容，尽量合并使用性能的两种策略。

策略1：设置/列表/地图FactoryBeans

这是两种策略用于阔叶树种更新，所有新的配置都写在这个模式。最简单的方法来显示这一战略是通过例子。让我们看看一些配置，生活在阔叶ApplicationContext文件看一看：

<bean id="blDialectProcessors" class="org.springframework.beans.factory.config.SetFactoryBean">
<property name="sourceSet">
<set>
<ref bean="blAddSortLinkProcessor" />
<ref bean="blCategoriesProcessor" />
... other bean references ...
</set>
</property>
</bean>
<bean id="blDialect" class="org.broadleafcommerce.common.web.dialect.BLCDialect">
<property name="processors" ref="blDialectProcessors" />
</bean>

What we have here is a bean called 

blDialect

 that has a property in it called 

processors

 which takes a Set of beans that implement the Thymeleaf 

IProcessor

.
This applicationContext file also defines another bean called 

blDialectProcessors

 of type

SetFactoryBean

. This means that Spring will do some processing for this SetFactoryBean,
and when it is injected into the 

processors

property, it will be transformed into a Set.

We are able to contribute an additional processor to this Set without copy-pasting the entire 

blDialectProcessors

 bean. We do so with the following configuration:

我们在这里是一个bean bldialect，叫做处理器以一系列实施的百里香叶iprocessor豆有一个属性。该文件还定义了另一个bean ApplicationContext的typesetfactorybean bldialectprocessors。这意味着春天将这setfactorybean做一些处理，当它被注入processorsproperty，它将变成一个集，我们可以提供一个额外的处理器这套没有复制粘贴整个bldialectprocessors豆。我们这样做与以下配置：

<bean id="blDialectAdditionalProcessors" class="org.springframework.beans.factory.config.SetFactoryBean">
<property name="sourceSet">
<set>
<ref bean="blAdditionalProcessorOne"/>
<ref bean="blAdditionalProcessorTwo"/>
</set>
</property>
</bean>
<bean class="org.broadleafcommerce.common.extensibility.context.merge.LateStageMergeBeanPostProcessor">
<property name="collectionRef" value="blDialectAdditionalProcessors" />
<property name="targetRef" value="blDialectProcessors" />
</bean>

Firstly, this additional configuration triggers the creation of a new bean, 

blDialectAdditionalProcessors

 that then defines two extra processors that we want to add to the 

blDialect
processors

 property. Secondly, we define a 

LateStageMergeBeanPostProcessor

 that will merge our new bean into the existing bean. Lastly, when the existing bean is injected into 

blDialect

,
it will contain our extra entries.

This strategy is applicable for adding entries into any pre-defined Broadleaf beans.

Strategy 2: XPath based merging

This is the older merge strategy and is still used in parts of the system that have not been migrated to the new style. It leverages various XPath based merge strategies defined in default.properties.
This approach actually modifies the XML structure of the merged applicationContexts before it reaches Spring. Let's take a look at an example of registering multiple dialects in the 

blWebTemplateEngine

:

首先，这个额外的配置触发新豆的创作，bldialectadditionalprocessors，然后定义了两个额外的处理器，我们要加入到bldialect处理器性能。其次，我们定义了一个latestagemergebeanpostprocessor将合并到现有的新豆豆。最后，当现有的bean注入bldialect，它包含额外的条目。这种策略适用于任何预先定义的阔叶豆添加条目。

策略2：基于XPath的合并

这是旧的合并策略，仍然在没有迁移到新样式的系统中使用的部分。它利用各种基于XPath的合并在default.properties策略定义。这种方法实际上修改合并ApplicationContexts XML结构达到春天之前。让我们看看在blwebtemplateengine注册多个方言看一个例子：

<bean id="blWebTemplateEngine" class="org.thymeleaf.spring3.SpringTemplateEngine">
<property name="dialects">
<set>
<ref bean="thymeleafSpringStandardDialect" />
<ref bean="blDialect" />
</set>
</property>
</bean>

If we wanted to add our own custom dialect, we could simply place the following bean definition in our applicationContext file:

如果我们想把我们自己定制的话，我们可以简单地将以下文件在我们的ApplicationContext bean定义：

<bean id="blWebTemplateEngine" class="org.thymeleaf.spring3.SpringTemplateEngine">
<property name="dialects">
<set>
<ref bean="myCustomDialect" />
</set>
</property>
</bean>

Because of t
his chunk in default.properties:
因为这一块在default.properties：

handler.14=org.broadleafcommerce.common.extensibility.context.merge.handlers.NodeReplaceInsert
priority.14=14
xpath.14=/beans/bean[@id='blWebTemplateEngine']/*
handler.14.1=org.broadleafcommerce.common.extensibility.context.merge.handlers.InsertItems
priority.14.1=1
xpath.14.1=/beans/bean[@id='blWebTemplateEngine']/property[@name='dialects']/set/ref

the XML that is produced would be:

生成的XML将是：

<bean id="blWebTemplateEngine" class="org.thymeleaf.spring3.SpringTemplateEngine">
<property name="dialects">
<set>
<ref bean="thymeleafSpringStandardDialect" />
<ref bean="blDialect" />
<ref bean="myCustomDialect" />
</set>
</property>
</bean>

Which strategy should I use?

When possible, you want to use Strategy 1. Whenever the goal is to merge into an existing 

ListFactoryBean

, 

SetFactoryBean

,
or

MapFactoryBean

, this is the right approach.

If you want to contribute an entry to a collection that is not handled by one of those three classes, the next step is to check if an entry in 

default.properties

 exists. If it does, you are able to use the second merge
strategy.

Disabling the second strategy

On occassion, you may need to override the Broadleaf merging process.

This can be done by adding a file named 

broadleaf-commerce/skipMergeComponents.txt

 to your classpath. For example, in the DemoSite, put this file in the 

core/src/main/resources

 directory.

The file should contain a list of component names for which you do not want the Broadleaf Commerce merge process to be used. The example below would not perform merging on the 

blAddItemWorkflow

 and 

blUpdateItemWorkflow

 components.

我应该使用哪一种策略？

在可能的情况下，您希望使用策略1。当目标是合并到现有的listfactorybean，setfactorybean，ormapfactorybean，这是正确的做法。如果你想进入一个行业贡献不是由一人三类处理，下一步就是检查default.properties条目存在。如果是的话，你可以使用第二个合并策略。

禁用第二策略

对，你可能需要重写阔叶合并的过程。这可以通过添加一个名为阔叶商务/ skipmergecomponents.txt你的classpath文件完成。例如，在demosite，把这个文件的核心/ src/main/resources目录。文件应该包含一系列的组件名称，你不想阔叶商务合并过程被使用。下面的例子将不会执行合并在bladditemworkflow和blupdateitemworkflow组件。

blAddItemWorkflow
blUpdateItemWorkflow

By adding a component to this list, the default Spring merging process will be used.

Merging Spring MVC Application Contexts

For servlet-level application context files, Strategy 2 described above is not applicable, as there is no special ContextLoader to process the XML. However, the first strategy is still applicable for
any beans that utilize the new FactoryBean approach.

通过将一个组件添加到这个列表中，将使用默认的春季合并过程。

合并Spring MVC应用程序上下文

Servlet应用上下文文件策略2以上是不适用的，由于没有专门的contextloader处理XML。然而，第一个策略仍然适用于任何豆类，运用新的方式方法。