The Blueprint Base Modules not only defines the interface of how to evaluate settings but also provides an implementation and a Spring bean.

<beans>
  <bean id="settingsService"
        class="c.c.b.base.settings.impl.SettingsServiceImpl">
    <property name="settingsFinders" ref="settingsFinders"/>
  </bean>

  <util:map id="settingsFinders">
  </util:map>
</beans>

The plain SettingsService has no lookup logic for settings at all, but it must be configured with SettingsFinders. A SettingsFinder implements a strategy how to determine settings of a particular type of bean. CoreMedia Content Cloud provides some preconfigured SettingsFinders for popular beans like content objects. It can be modified and enhanced with custom SettingsFinders for arbitrary bean types. As you can see, the default settings service only needs one property, which is a map named settingsFinders. The keys of that map must be fully qualified Java class names and its values are references to concrete SettingsFinder beans.

          
<util:map id="settingsFinders">
  <entry key="com.coremedia.cap.content.Content"
         value-ref="cmlinkableSettingsFinder"/>
  <entry key="com.coremedia.cap.multisite.Site"
         value-ref="siteSettingsFinder"/>
</util:map>

<bean id="cmlinkableSettingsFinder"
      class="c.c.b.base.settings.CMLinkableSettingsFinder">
  <property name="cache" ref="cache"/>
  <property name="hierarchy" ref="navigationTreeRelation"/>
</bean>

<bean id="siteSettingsFinder"
      class="c.c.b.base.settings.SiteSettingsFinder"/>
        

The example above shows a map with two settings finders. One is supposed to be used for target beans of type com.coremedia.cap.content.Content and the other for targets of type com.coremedia.cap.multisite.Site.

In order to determine the appropriate settings finder for a given target bean the settings service calculates the most specific classes among the keys of the settings finders map which match the target bean. For the above example this is trivial, since Content and Site are disjointed. The lookup gets more interesting with content beans which usually constitute a deeply nested class structure. Assume, you configured settings finders for CMLinkable and CMTaxonomy. If you invoke the settings service with a CMTaxonomyImpl bean, only the settings finder for CMTaxonomy is effective. There is no automatic fallback to the CMLinkable finder. If you need such a fallback, let your special settings finder extend the intended fallback finder and call its setting method explicitly.

The easiest way to provide a custom way of fetching settings for certain documents or even for objects that do not represent a CoreMedia document, is, to add a corresponding settings finder, that does the trick. Therefore, you should use CoreMedia's Spring bean customizer, that you can use anywhere within your Spring application context as follows:

          
<beans>
  <customize:append id="mySettingsFinders" bean="settingsFinders">
    <map>
      <entry key="example.org.MyClass" value-ref="mySettingsFinder"/>
    </map>
  </customize:append>
</beans>
        

Via Spring you can configure one settings finder per class. This is a tradeoff between flexibility and simplicity which is sufficient for most use cases. However, on the Java level the SettingsServiceImpl provides the method addSettingsFinder(Class<?>, SettingsFinder) which allows you to add multiple settings finders for a class.