close

Filter

loading table of contents...

Blueprint Developer Manual / Version 2307

Table Of Contents

4.1.3 Application Architecture

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

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>

Example 4.2. Adding the Base Component


CoreMedia applications are hierarchically assembled from artifacts:

  • Library artifacts are used by

  • Component artifacts which are used by

  • Application 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:

  • /META-INF/coremedia/component-<componentname>.xml:

    An entry point for all component Spring beans. Either declared directly or imported from library artifacts.

  • /META-INF/coremedia/component-<componentname>.properties:

    All configuration options of the component as key/value pairs. These properties might be overridden by the concrete application.

Redundant Spring Imports
Note

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

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).

Search Results

Table Of Contents
warning

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.