CoreMedia DXP Release Notes, Version 7.5.44-17
2.2. Improvements and Changes | 2.2.9. Release 7.5.36

As introduced in CMS-2929 CoreMedia CMS speeds up XML parsing via Spring's org.springframework.beans.factory.xml.XmlBeanDefinitionReader, which optionally can be disabled via the flag skip.redundant.spring.imports.

The corresponding replacement for the XmlBeanDefinitionReader is now available as public API:

Having this you can now also use this reader in your Spring configuration as for example during tests based on SpringJUnit4ClassRunner:

    
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = MyTest.LocalConfig.class)
public class MyTest {
  @Configuration
  @ImportResource(
      value = "my-test-context.xml",
      reader = ResourceAwareXmlBeanDefinitionReader.class)
  public static class LocalConfig { }
}


  

As an example a test which previously took 60 seconds is now done within 15 seconds.

The Blueprint Content Feeder for the corporate extension sets parent categories of CMCategory documents in the Solr index fields directProductCategories and allProductCategories now. In previous releases these fields were only set for CMProduct documents. This change makes it possible to search for product categories in the internal product catalog in Studio after they have been reindexed.

The command line tool "cm publishall" now offers a new option "-a" which publishes the entire contents of the content management server to an empty master live server. Exclusions can be defined through a content query using the new "-cq" option. This feature is intended for use in CI pipelines or for initial project setup.

The tooltip of a content tab is dynamically enriched with site and locale information.

The Studio document tab is now showing document type icons for all document tabs. For own doctypes two additional CSS classes need to be added, please refer to Studio Developer Manual chapter "Defining Content Type Icons" for details.

Extensions can now provide content zips via the content extension point. In order to be copied and merged into one content-users.zip by the boxes module, content zips must be marked using content as Maven classifier.

The blueprint studio plugin "contentchooser" has been moved to blueprint-base.

You can configure additional base paths in your CAE Feeder extension module by adding a customizer to the module's Spring configuration:

    
<customize:append id="productBasePathListCustomizer" bean="basePathList">
  <list>
    <value>/Products</value>
  </list>
</customize:append>


  

The method PathAndTypeContentSelector#setBasePath(String basePath) has been deprecated and will be completely replaced by PathAndTypeContentSelector#setBasePath(List<String> basePaths) in the future.

XLIFF Import - Handling of Empty Trans-Units

A new property translate.xliff.import.emptyTransUnitMode has been introduced to configure the handling of empty trans-unit targets on XLIFF import. Possible values are:

Configuration of LiveContext Environment has moved from web.xml to coremedia-connector.properties. This is the default way to configure the Connector from now on, but it is up to you if you want to configure via web.xml or coremedia-connector.properties.

CMS-4624: CAE Feeder: error creating database schema on MySQL

Database schema creation has been fixed for MySQL by setting the utf8 character set on indexed varchar columns.

CMS-4446: TestInfrastructureBuilder Replacement

The TestInfrastructureBuilder, used for XML backed content repository tests is deprecated since some time now recommending to use SpringJUnit4Runner instead to set up a custom application context.

Now some convenience API is public to easily migrate your TestInfrastructureBuilder based tests. It contains especially a configuration class which reads your content.xml just as the TestInfrastructureBuilder did before.

Required Dependency:

To use the convenience API you require a dependency on cap-client-xml:

    
<dependency>
  <groupId>com.coremedia.cms</groupId>
  <artifactId>cap-client-xml</artifactId>
  <scope>test</scope>
</dependency>


  

Most Basic Usage:

    
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = MyTest.LocalConfig.class)
public class MyTest {
  @Inject
  private CapConnection connection;
  @Configuration
  @Import(XmlRepoConfiguration.class)
  public static class LocalConfig {
  }
}


  

If your tests deals with requests and responses you have to annotate your test in addition with @WebAppConfiguration to use Spring MVC Test Framework (also known as MockMvc).

Deal With Component Scan Conflicts:

If you happen to have a component scan on your test package you might need to restrict LocalConfig lookup to your test class exclusivly using profiles as follows:

    
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = MyTest.LocalConfig.class)
@ActiveProfiles(MyTest.LocalConfig.PROFILE)
public class MyTest {
  @Inject
  private CapConnection connection;
  @Configuration
  @Import(XmlRepoConfiguration.class)
  @Profiles(LocalConfig.PROFILE)
  public static class LocalConfig {
    public static final String PROFILE = "MyTest";
  }
}


  

Usage With Custom content.xml:

Just the LocalConfig here, everything else stays the same:

    
@Configuration
@Import(XmlRepoConfiguration.class)
public static class LocalConfig {
  @Bean
  @Scope(BeanDefinition.SCOPE_SINGLETON)
  public XmlUapiConfig xmlUapiConfig() {
    return new XmlUapiConfig("classpath:/MyTest-content.xml");
  }
}


  

For more information consult the JavaDoc of XmlRepoConfiguration and the related classes.

The chapter Unit Testing a CAE Application in the CAE Developer Manual got updated accordingly.

Migrating Existing Tests:

Migrating tests based on the TestInfrastructureBuilder especially means to replace existing calls to the TestInfrastructureBuilder with appropriate Spring configuration. The following pattern for ImportResource shows mappings for the various methods like withLinkFormatter:

    
@ImportResource(
  value = {
    // withCache
    XmlRepoResources.CACHE,
    // withContentBeanFactory
    XmlRepoResources.CONTENT_BEAN_FACTORY,
    // withDataViewFactory
    XmlRepoResources.DATA_VIEW_FACTORY,
    // withHandlers
    XmlRepoResources.HANDLERS,
    // withIdProvider
    XmlRepoResources.ID_PROVIDER,
    // withLinkFormatter
    XmlRepoResources.LINK_FORMATTER,
    // withViewResolver
    XmlRepoResources.VIEW_RESOLVER, 
    // withSites (7.1)
    "classpath:framework/spring/multisite-services.xml",
    // withSites (7.5)
    "classpath:/com/coremedia/blueprint/base/" +
      "multisite/bpbase-multisite-services.xml", 
    // withBeans
    "classpath:myConfig.xml",
  },
  reader = ResourceAwareXmlBeanDefinitionReader.class
)


  

In contrast to this withContentRepository gets replaced by the XmlUapiConfig bean described above, just providing the same path to the content.xml as you used for the TestInfrastructureBuilder.

To register custom beans, i. e. to replace TestInfrastructureBuilder.withBean() you just add an additional bean to your LocalConfig.

One special case to deal with is asWebEnvironment: To migrate tests using asWebEnvironment you first have to add the annotation @WebAppConfiguration to your test (not to your LocalConfig). Having this you will automatically have some beans available like MockHttpServletRequest, MockHttpServletResponse and especially WebApplicationContext. To send request you typically use Spring's MockMvc. You could provide it as bean in your LocalConfig:

    
@Bean
@Scope(SINGLETON)
public MockMvc mockMvc(WebApplicationContext wac) {
  return MockMvcBuilders.webAppContextSetup(wac).build();
}


  

and perform a handler test like this:

    
@Test
public void testHandleMergedLink() throws Exception {
  MvcResult mvcResult =
    mockMvc
      .perform(
        MockMvcRequestBuilders
          .get(LINK_TO_MERGED_CONTENT_RESOURCE)
          .requestAttr("key", "value")
      )
      .andExpect(MockMvcResultMatchers.status().isOk())
      .andReturn();
  ModelAndView mav = mvcResult.getModelAndView();
  // further assertions
}


  

CMS-514: Content Feeder Taxonomy Feeding

The Blueprint Content Feeder now correctly reindexes documents with taxonomies after changes to the taxonomy tree when they happen while the Content Feeder is running. Reindexing is done by a background thread with lower priority and does not block feeding of editorial changes.

Changes to the taxonomy tree that happen while the Content Feeder is down are not yet reflected in the index. This is another bug, known as CMS-4565.