Blueprint Developer Manual / 4.3 Build and Run the Applications

Blueprint Developer Manual / Version 2404

4.3 Build and Run the Applications

The Blueprint workspace provides Maven modules to build Spring Boot applications for Blueprint applications.

Prerequisites

Before you can run the applications, you have to build the CoreMedia Blueprint Workspace in advance:

mvn clean install -Pdefault-image
cd apps/studio-client
pnpm install
pnpm -r run build
cd ../..

See Section 3.2.1, “Building the Workspace” for more details.

Workspace Structure

apps/<app-name>/spring-boot - below this folder there is a Maven module for each service application. Each of these modules will build a single Spring Boot application packaged as a JAR file.
shared/common/spring-boot/blueprint-spring-boot-autoconfigure, this module encapsulates common configuration aspects for all Spring Boot service modules.

See Section 4.1.4, “Structure of the Workspace” for more details.

Application Structure

Each Spring Boot application module is structured the same way:

A source folder containing at least the application starter class. It could also contain other classes implementing Spring configuration classes.
A resources folder containing the properties files and the logging configuration file.

Spring Configuration

Each application can define properties in multiple Spring Boot profiles:

The default profiles with properties defined in application.properties.
The development profiles defined in application-dev*.properties.
The local profiles with properties defined in application-.*-local.properties. These properties can contain paths only available on a local workstation. The default local profile is named local and should be used when starting the application using either IDEA or Maven.
Commerce specific settings:
- application-dev-wcs.properties
Development profiles activating development features for local and CI environments.
- The default development profile is named dev and should be used when starting the application using either IDEA or Maven.

Logging

Logging is configured using the standard Spring-Boot logging properties. If you want to modify the logback configuration, you need to place a logback-spring.xml inside your classpath root directory i.e. src/main/resources in the application modules.

By default, the logging is configured with different logging patterns depending on the output and the active Spring Boot profile:

No active profile: Only console logging without timestamps or coloring. Timestamps are added by all container runtimes. If file logging is activated by setting the logging.file.name property, the log file will contain timestamps but no coloring.
dev profiles: File and console logging are active without coloring. Only file logging will contain a timestamp. The log file is created at /coremedia/log/application.log in the container file system. For excessive logging, the directory should be mounted to a container volume.
local profiles: File and console logging are active with timestamps. The console logging will contain coloring. The log file is created in the project.build.directory of the module. The name of the application or an abbreviation will be used as the filename to differentiate two disctinct applications, started with different local profiles.

To gather logs from the command-line using docker or kubectl, please use the --timestamp or -t flag. This is especially important, if you collect logs to be included in a support request:

Docker.

docker logs --timestamp <container>

Kubernetes.

kubectl logs --timestamp <pod>

For Kubernetes there is also a timestamp flag for the kubectl command-line utility:

Developing with CoreMedia Blueprint applications

Currently there are two different approaches to start the Spring Boot apps you want to develop locally:

Using the spring-boot-maven-plugin
Using IntelliJ IDEA run configurations together with the Run Dashboard

The apps you don’t want to alter, can be provided using the local Docker development deployment.

Application Configuration Facade

To configure the locally started applications, Spring Boot profiles are being used:

dev - this profile activates development features like actuators, monitoring etc. and should not add filesystem or localhost features. This profile will be active by default if you include the development.yml in the docker compose setup included with this workspace.
local - this profile configures local paths within the workspace like paths to licenses or source folders of other modules. This profile should only be activated for locally started apps using Maven or IDEA but not the docker compose setup.

To configure which application should be used from a remote system, there is a list of convenience host properties, forming a simple configuration facade. The intent of these properties is to use them only in private Spring profiles, on the command-line or in IDEA run configurations when you are developing locally. Do not use these properties outside of the application-local.properties files except for the cases mentioned above.

The main property is installation.host which when set implicates all other services / endpoints are running remotely. By default, all other convenience host properties derive their default from installation.host. If you start more than one service locally, lets say studio-server and preview, then you need to tell studio-server to use the locally started preview instead of a remote one and you have to set cae-preview.host to localhost.

- installation.host
    |- db.host
    |- mongodb.host
    |- solr.host
    |- content-management-server.host
    |- master-live-server.host
    |- workflow-server.host
    |- cae-preview.host
    `- cae-live.host

Search Results

Table Of Contents

Filter