Bloomreach Experience Manager and Spring Framework

Introduction

Many core features of Spring Framework such as Dependency Injection and Aspect-Oriented Programming are used in Bloomreach Experience Manager's delivery framework (HST) to manage its internal components.

This page describes the version compatibilities of Spring Framework and Bloomreach Experience Manager, and explains how Bloomreach Experience Manager's delivery framework maintains its ApplicationContexts for internal components.

Version Compatibility

Bloomreach Experience Manager 14 supports Spring Framework 5.3.

Bloomreach Experience Manager Spring Framework
14.x.y 5.3.x
13.x.y 5.2.x
11.x.y, 12.x.y 4.3.x
10.1.x, 10.2.x 4.1.x

Spring Framework in Bloomreach Experience Manager's Delivery Framework

Bloomreach Experience Manager's delivery framework manages all the internal container components through Spring Framework ApplicationContexts, leveraging the basic Dependency Injection feature.

Internal Container Component Management

In Bloomreach Experience Manager's delivery framework there are many components to be maintained. For example, it should have JCR Session Pool components, Request Processing Pipeline components, Hosts, Site and Channel Configuration Management components, Observation Event Listener components, Cache Management components, Security components, etc. in order to serve web application developments as a generic Context/Content-oriented Hierarchical MVC framework.

The first challenge here is to choose a reliable enterprise-ready Dependency Injection container like what Spring Framework provides. The second challenge is that because Spring Framework is widely used in many web applications, the internal ApplicationContexts of the Container of the delivery framework must not interfere with those of the existing web applications, but should be isolated from normal WebApplicationContexts.

Therefore Bloomreach Experience Manager's delivery framework initializes its own ApplicationContexts in a programmatic way by loading bean configurations from some specific classpath resources, allowing bean overriding from specific locations. This way it effectively organizes its internal components with isolating from normal WebApplicationContexts of a web application which depends on Bloomreach Experience Manager's delivery framework.

More specificially Bloomreach Experience Manager's delivery framework loads all the bean configurations through org.hippoecm.hst.site.container.HstContextLoaderListener (configured in web.xml) from the classpath resources (distributed in hst-core-x.x.x.jar) as follows:

  • classpath:org/hippoecm/hst/site/container/SpringComponentManager.xml
  • classpath:org/hippoecm/hst/site/container/SpringComponentManager-*.xml

Also the default configuration properties are read for the bean configurations from classpath:org/hippoecm/hst/site/container/SpringComponentManager.properties and the default configuration properties can be overriden in hst-properties file(s). See HST-2 Container Configuration for more details.

Overriding Internal Container Components or Adding Custom Components

Bloomreach Experience Manager's delivery framework allows to either override existing container components or add new custom components in a web application. See HST Core Spring Extension Points for a list of Spring beans that are deemed SPIs and are safe to override. Overriding beans not explicitly listed as SPI should be avoided as they may not be stable across releases.

By default any overriding component bean definitions or any new custom bean definitions should be added in the following locations:

  • classpath:META-INF/hst-assembly/overrides/*.xml
Those overriding bean definition XML files should be located in the source folder at src/main/resources/META-INF/hst-assembly/overrides/ in a typical Maven-based project's site/components module.

Accessing Internal Container Component

Internal container components of Bloomreach Experience Manager's delivery framework can be accessed through org.hippoecm.hst.core.container.ComponentManager.

For example, there exists an internal component with an ID, "javax.jcr.Repository", which is actually a javax.jcr.Repository implementation with providing JCR session pooling internally. Also there exists another internal component with an ID, "javax.jcr.Credentials.default", which is actually a javax.jcr.Credentials implementation and used in normal request processing for a live web site. (Please see classpath:org/hippoecm/hst/site/container/SpringComponentManager-jcr.xml if you want to see the exact bean definitions.)

So if you want to get a JCR session from the internal JCR session pooling repository component for instance, you can do the following:

import javax.jcr.Repository;
import javax.jcr.Session;
import javax.jcr.Credentials;
import org.hippoecm.hst.site.HstServices;
import org.hippoecm.hst.core.container.ComponentManager;

public class Example {
    public void doIt() throws Exception {
        Session session = null;

        try {
            // Get ComponentManager using HstServices which returns the internal ComponentManager initialized by the delivery framework.
            ComponentManager componentManager = HstServices.getComponentManager();

            // You can get internal components of the delivery framework through #getComponent(beanName).
            Credentials liveSiteCreds = componentManager.getComponent("javax.jcr.Credentials.default");
            // You're getting the internal JCR session pooling repository component which implements Repository interface but works as JCR session pools.
            Repository repository = componentManager.getComponent("javax.jcr.Repository");

            // Borrow a JCR session from the pooling repository component. #login() returns a pooled session internally.
            session = repository.login(liveSiteCreds);

            // do something (e.g, query) here with session.
            // ...
        } finally {
            if (session != null) {
                // Return the JCR session to the pool. #logout() was implemented to return to the pool where it lives.
                session.logout();
            }
        }
    }
}

See HST Core Spring Extension Points for a list of Spring beans that are deemed APIs and are safe to use. Using beans not explicitly listed as API should be avoided as they may not be stable across releases.

Publish-Subscribe Style Event Communication through ComponentManager

ComponentManager also provides a simple publish-subscribe style event communication mechanism between components. Please see HST Spring ComponentManager event publishing for more detail.

Summary

Bloomreach Experience Manager's delivery framework leverages many core features of Spring Framework such as Dependency Injection and Aspect-Oriented Programming in order to manage its internal components.

It initializes its own ApplicationContexts in a programmatic way by loading bean configurations from some specific classpath resources, allowing bean overriding from specific locations. This way it effectively organizes its internal components with isolating from normal WebApplicationContexts of a web application which depends on the delivery framework.

Also, it provides many useful features for web applications depending on the delivery framework, a Context/Content-oriented Hierarchical MVC framework. For example, it allows to override container components, add custom components, publish-subscribe style communication mechanism between components, and much more.

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?