CoreMedia applications are based on Spring Boot and as such support Spring Java configuration, Spring Boot auto-configuration, and Spring Boot configuration properties.

The recommended way to develop, extend, and configure CoreMedia applications is to follow the Spring Boot conventions. However, for backward-compatibility reasons, the CoreMedia component loader may still be used to activate component XML bean definitions and to load component properties files.

Note

The rest of this section describes the component loader and related topics. This is mostly relevant for projects migrating from an old CoreMedia version to a recent one.

To activate the component loader, add the following dependency to your component or web application module pom.xml file:

<dependency>
 <groupId>com.coremedia.cms</groupId>
 <artifactId>base-component</artifactId>
 <scope>runtime</scope>
</dependency>

CoreMedia applications are hierarchically assembled from artifacts:

Library Artifacts

Library artifacts contain JAR artifacts with Java classes, resources and Spring bean declarations.

An example is the artifact cae-base-lib.jar that contains CAE code as well as the XML files which provide Spring beans.

Component Artifacts

Component artifacts provide a piece of business (or other high level) functionality by bundling a set of services that are defined in library artifacts. Components follow the naming scheme <componentKey>-component.jar. The component artifact cae-component.jar for example, bundles all services that are typically required by a CAE web application based project.

Component artifacts are automatically activated on application startup, in contrast to library artifacts. That is, Spring beans and properties are loaded into the application context and servlets and so on will be instantiated. Therefore, you can add a component by simply adding a Maven dependency. No additional steps (such as adding an import to a Spring file) are necessary.

The following files allow you to declare services for a component which are automatically activated:

Redundant Spring Imports

Note

This section is about Spring XML configuration files. The recommended way to configure Spring bean definitions is to use Spring Java configuration.

Due to the design of the Spring Framework and the CoreMedia component loader, it may often be necessary to declare many <import/> elements in Spring XML configuration files, often pointing to the same resource. This slows down the startup of the ApplicationContext.

Unfortunately, org.springframework.beans.factory.xml.XmlBeanDefinitionReader does not track imported XML files, so redundant <import/> elements will lead to Spring parsing the same XML files over and over again (in most cases, those XML files will contain more <import/> elements leading to even more parsing, ...) After moving to Servlet 3.0 resources, for each <import/>, the JAR file containing the XML file has to be unpacked. Also, every time that an XML file is completely parsed, Spring reads all Bean declarations, creates new org.springframework.beans.factory.config.BeanDefinition instances, overwriting any existing bean definitions for the same bean ID.

The optional Spring Environment property skip.redundant.spring.imports controls handling of redundant imports. If set to true, the first <import/> element will be used and all following, duplicate <import/> elements pointing to the same resource will be ignored. The property is true by default. The time saved depends on the number of duplicated <import/> elements.

Caution

Even though this setting is recommended, it may change which bean definitions are loaded. (As explained above, normally, bean definitions may be overwritten by subsequent imports, depending on how <import/> elements are used in a web application).