Dynamic Content Beans

Info: Dynamic content bean generation is available in brXM 13.2.0 and later.

Overview

Dynamic content bean generation creates Java classes for your document types at runtime. This allows you to use new or modified document types immediately in your templates, without rebuilding or restarting your application.

How Dynamic Content Bean Generation Works

When you create document types using the Document Type Editor or configure image sets with the Gallery Manager, Bloomreach Content generates content bean classes dynamically at runtime. These classes become available immediately, for example in Freemarker templates, eliminating the need for a manual build or restart during development.

Note: Dynamic bean generation is enabled by default. It runs for all content types, regardless of whether Java content bean classes already exist in your project.

Supported Content Types

Dynamic bean generation supports:

Document types
Compound types
Image set types

All standard and compound fields configured in the Document Type Editor are supported.

Dynamic bean generation does not support value list items. If your content types use value list items, mark the related content bean classes as not modifiable.

Bean Generation Details

At runtime, when a bean is needed, Bloomreach Content uses Byte Buddy to generate a Java class. This class includes getter methods for all fields defined in the node type. The generation occurs once per bean, or after a document type changes, and does not impact runtime performance.

If no existing Java content bean class is found for a document type (as determined by automatic scanning for content bean annotated classes), the generated bean extends BaseDocument. You can add shared methods to your BaseDocument class if needed.

The generated bean class is based on the JCR node definitions. For example, for the document type myproject:mydocumentype, the generated class might look like:

...
public BaseDocument$Mydocumenttype$8btLfpVF extends BaseDocument {
  public String getStringTypeField() {
    return (String) super.getProperty("myproject:stringTypeField");
  }
  public Calendar getDateTypeField() {
    return (Calendar) super.getProperty("myproject:dateTypeField");
  }
  public HippoHtml getRichTextEditorCompoundType() {
    return super.getHippoHtml("myproject:richTextEditorCompoundType");
  }
  public HippoGalleryImageSet getImagelinkCompoundType() {
    return (HippoGalleryImageSet) super.getLinkedBean("myproject:imagelinkCompoundType", HippoGalleryImageSet.class);
  }
  ...
  ...
}

If your project does not define a BaseDocument class (no class with @Node(jcrType="myproject:basedocument")), generated beans extend HippoDocument.

For compound types, generated beans extend HippoCompound.

Enhancing Existing Content Bean Classes

If your project includes custom content bean classes, Bloomreach Content can generate a subclass at runtime that adds any missing getter methods.

For example, if you have an existing bean class:

@Node(jcrType = "myproject:mydocumentype")
public class Mydocumenttype extends BaseDocument {

}

The dynamically generated subclass will add missing getters:

public Mydocumenttype$Mydocumenttype$8btLfpVF extends Mydocumenttype { 
  public String getMissingfield() { 
    return (String) super.getProperty("myproject:missingfield"); 
  }
}

A new subclass is generated only if the existing class does not have the @HippoEssentialsGenerated annotation, or if the annotation is present but does not specify allowModifications=false. If the existing bean class already includes getter methods for all fields, no subclass is generated and the existing class is used.

Mark Existing Bean Classes as Not Modifiable

To prevent runtime modification of your bean classes, set the allowModifications parameter of the @HippoEssentialsGenerated annotation to false:

@HippoEssentialsGenerated(internalName = "myproject:mydocumentype", allowModifications = false)
@Node(jcrType = "myproject:mydocumentype")
public class Mydocumenttype extends BaseDocument {
  ...
  ...
}

Custom Bean Class Hierarchies

If your bean classes use a custom inheritance hierarchy (for example, a document type or compound type extends another custom type instead of BaseDocument), the dynamic bean generation process preserves this hierarchy.

For example, if Childdocument extends Parentdocument, the generated classes will reflect this structure:

public class BaseDocument$Parentdocument$IB2IXnoT extends BaseDocument {
  ...
  ...
}

public class BaseDocument$Parentdocument$IB2IXnoT$Childdocument$2E9PXydT extends IB2IXnoT {
  ...
  ...
}

Handling Custom Image Sets

When you create custom image sets using the Gallery Manager tool, the gallerytype property on the /content/gallery node is set to the custom image set name. During bean generation, this property determines the image set type for the generated bean.

Info:

If the gallerytype property contains multiple values, the default image set type (hippogallery:imageset) is used.

When deploying, ensure that any changes to the /content/gallery/hippostd:gallerytype property are included in all environments.

Disabling Dynamic Bean Generation

Dynamic bean generation is enabled by default. To disable it, set the system property dynamic.bean.generation to false when starting the JVM:

-Ddynamic.bean.generation=false

Using Dynamic Content Beans with the Content REST API

Dynamic content bean generation is compatible with the Content REST API.

Custom REST resources are not currently supported. If your project uses custom REST resources, mark the related content bean classes as not modifiable.