Overview
BRUT boots an in-memory brXM delivery tier stack for tests. It builds a repository, loads HCM
configuration and content, initializes the HST model, then executes the same pipelines used in
production (component rendering, JAX-RS, Page Model API).
Module Overview
| Module |
Purpose |
| brut-common |
In-memory repository, YAML import, JUnit 5 extensions, auto-detection utilities |
| brut-resources |
HST container startup, HCM module loading, request pipelines, PageModel API |
| brut-components |
Component test utilities, HST request/response mocks |
brut-common
- In-memory repository and YAML import utilities
- Repository configuration from
repository.xml on classpath
- Test authentication via in-memory login module
Key Classes
| Class |
Purpose |
BrutTestConfigurationException |
Unified error handling with factory methods |
TestConfigurationLogger |
Consistent configuration logging |
TestInstanceInjector |
JUnit 5 field injection |
AbstractBrutRepository |
Shared CND/namespace handling |
brut-resources
- Loads HCM modules (config + content) via Config Service APIs
- Initializes the HST container and request pipelines
Bootstrap Components
| Class |
Purpose |
ConfigServiceBootstrapStrategy |
Orchestrates HCM-based bootstrap |
RuntimeTypeStubber |
Stubs missing namespaces/node types |
JcrNodeSynchronizer |
Syncs JCR nodes between trees |
ConfigServiceReflectionBridge |
Reflection access to ConfigService |
Request Utilities
| Class |
Purpose |
MockHstRequest |
Extended mock with HTTP session support |
RequestBuilder |
Fluent API for request setup |
PageModelResponse |
Navigation utility for Page Model API responses |
brut-components
Component-test utilities and mocks for HST components:
@BrxmComponentTest annotation
DynamicComponentTest test harness
- Request/response mocking
- Component parameter injection
Bootstrap Flow
- Register CND node types from configured patterns
- Load HCM modules from descriptors or explicit module paths
- Build the configuration model and apply namespaces/node types
- Import content definitions into the repository
- Build the HST model from the repository
Request Flow (Page Model API)
Test -> DynamicPageModelTest -> HST Container -> HST Model/Cache
| | | |
| | | +--> Resolve sitemap item
| | | +--> Resolve channel (preview/live)
| | | +--> Resolve component tree
| | | |
| | | +--> Resolve container refs
| | | (hst:workspace/hst:containers)
| | | +--> Build container items
| | |
| | +--> Build Page Model JSON
| |
+--> Response JSON (root + page map with $ref links)
Request Flow (Component/JAX-RS)
Test -> DynamicComponentTest/DynamicJaxrsTest -> HST Container -> HST Model/Cache
| | | |
| | | +--> Resolve mount + sitemap item
| | | +--> Resolve component tree
| | | +--> Build request context
| | |
| | +--> Execute pipeline (component/jaxrs)
| |
+--> Response (rendered output or JAX-RS payload)
HST Configuration Resolution
Composite Configuration
HST loads a composite configuration: base config overlaid by workspace nodes. This is how
workspace containers, sitemenus, and channel info become visible to the model.
Container References
hst:containercomponentreference resolves against hst:workspace/hst:containers
- Container items are
hst:containeritemcomponent children
- If the referenced workspace path is missing, the reference is ignored
Sitemenus and Channel Info
- Sitemenus can live under both
hst:sitemenus and hst:workspace/hst:sitemenus
- Channel info is resolved from the mount
- Preview mounts use the preview configuration and its workspace overlays
Caching and Refresh
HST model caches are built during initialization. If configuration/content is imported after
the model is built, caches must be invalidated or the model rebuilt for changes to take effect.
Customization Points
| What |
How |
| Repository behavior/auth |
Custom repository.xml on classpath |
| Module loading |
Explicit module descriptors in tests |
| CND/YAML patterns |
Spring configuration or annotation parameters |