HOWTO: Define a Runtime XMap Object

Updated: April 15, 2021

Watch the related courses on Nuxeo University:
Course on Handling Service Extension Points

Runtime contributions follow a XML format defined by a Java POJO, sometimes referred to as a "descriptor". This Java class is referenced on the extension point declaration, using specific Java annotations that will allow performing deserialization when parsing XML contributions.

Here is a sample XML fragment to be resolved:

<sample id="myid">
  <title>My title</title>

If this fragment should be contributed to the extension point name myPoint for component org.mycompany.myproject.MyService, the extension point declaration will need to reference a Java class using the <object> element:

<?xml version="1.0"?>
<component name="org.mycompany.myproject.MyService">
  <!-- previous configuration here... -->

  <extension-point name="myPoint">
      This extension point can be documented here. HTML tags are accepted.
    <object class="org.mycompany.myproject.api.SampleDescriptor" />


The corresponding class needs to be annotated with the @XObject annotation. Additional @XNode annotations are needed to specify node or attribute retrieval.

Here is the sample annotated class for the given XML format:

package org.mycompany.myproject.api;

public class SampleDescriptor {

    protected String id;

    protected String title;

    protected Integer order;

    protected Boolean displayed;


Note the usage of the @ character for the id attribute retrieval, compared to the title node content retrieval.

Java reflection is used to convert the value to the desired type. Specific factories can also be added to the XMap resolution class for custom conversions.

Here is a reference of supported built-in types:

  • String
  • Integer
  • Long
  • Double
  • Float
  • Boolean
  • Date
  • File
  • URL
  • Duration
  • Enum

Note that primitive types can also be used (boolean instead of Boolean for instance) but a default value will automatically be resolved in that case, and it will not be possible to check whether the XML held the corresponding mapping or not (and this can be important for contribution merging logics).

More complex structure like lists and maps are also supported:

<sample id="myid">
    <property name="MyPropName1">MyPropValue1</property>
    <property name="MyPropName2">MyPropValue2</property>

These can be mapped using the XNodeMap and XNodeList annotations:

package org.mycompany.myproject.api;

public class SampleDescriptor {

    // ...

    @XNodeList(value = "display/on", type = ArrayList.class, componentType = String.class)
    protected List<String> displays; // will resolve to ["MyDisplay1", "MyDisplay2"]

    @XNodeMap(value = "properties/property", key = "@name", type = HashMap.class, componentType = String.class)
    protected Map<String, String> properties; // will resolve to {"MyPropName1": "MyPropValue1", "MyPropName2": "MyPropValue2"}

    @XNodeList(value = "properties/[email protected]", type = ArrayList.class, componentType = String.class)
    protected List<String> propertyKeys; // will resolve to ["MyPropName1", "MyPropName2"]


Note that the resulting lists and maps will not be null by default, unless the annotation attribute "nullByDefault" is set to "true".

It is also possible to define sub objects, also annotated, to be referenced within the original object. Here is a sample map of annotated objects:

package org.mycompany.myproject.api;

public class SampleDescriptor {

    // ...

    @XNodeMap(value = "persons/person", key = "firstName", type = HashMap.class, componentType = Name.class)
    protected Map<String, Name> persons;

package org.mycompany.myproject.api;

public class Name {

    protected String firstName;

    protected String lastName;


This will resolve the corresponding sample format:

<sample id="myid">
      <firstName>First Name 1</firstName>
      <lastName>Last Name 1</lastName>
      <firstName>First Name 2</firstName>
      <lastName>Last Name 2</lastName>

If you'd like to properly handle hot-reload on the target component, or handle merging of descriptors, it can be useful to make the descriptor implement the org.nuxeo.runtime.model.Descriptor interface, that comes with needed #getId and #merge methods.

The string marker Descriptor#UNIQUE_DESCRIPTOR_ID can be used as an id, when handling only one single instance of the contribution on the component, instead of multiple contributions (to hold simple configuration for instance).

We'd love to hear your thoughts!

All fields required