Package org.nuxeo.ecm.core.blob

Class DefaultBlobDispatcher

java.lang.Object
org.nuxeo.ecm.core.blob.DefaultBlobDispatcher
All Implemented Interfaces:
BlobDispatcher
public class DefaultBlobDispatcher extends Object implements BlobDispatcher
Default blob dispatcher, that uses the repository name as the blob provider.

Alternatively, it can be configured through properties to dispatch to a blob provider based on document properties instead of the repository name.

The property name is a list of comma-separated clauses, with each clause consisting of a property, an operator and a value. The property can be a Document xpath, ecm:repositoryName, ecm:path, ecm:isRecord, ecm:isFlexibleRecord, ecm:mixinType, or, to match the current blob being dispatched, blob:name, blob:mime-type, blob:encoding, blob:digest, blob:length or blob:xpath.

Comma-separated clauses within a single rule are ANDed together. Multiple <property> entries form an ordered list of rules, and the first rule whose clauses all match wins. The special name default defines the default provider, and must be present.

Available operators between property and value are =, !=, <, <= ,>, >=, ~ and ^.

The operators =, !=, <, <=, > and >= work as numeric operators if the property is numeric, otherwise as string comparisons operators.

The operator ~ does glob matching using ? to match a single arbitrary character, and * to match any number of characters (including none). The operator ^ does full regexp matching.

The ecm:mixinType pseudo-property is multivalued (a document carries zero or more facets) and supports only the = and != operators, with element-level membership semantics: ecm:mixinType=Foo matches when the document carries facet Foo, and ecm:mixinType!=Foo matches when it does not. To dispatch on any of several facets, declare one rule per facet pointing to the same provider and rely on the first-matching-rule-wins evaluation order.

Note that re-dispatch is only triggered by blob/property writes and a few explicitly-wired events (lifecycle state / policy changes, makeRecord, copy). It is not triggered by changes to ecm:path (document moves) or to ecm:mixinType (facets added/removed): for those, blobs are re-evaluated only on the next blob write on the document.

For example, to dispatch to the "first" provider if dc:format is "video", to the "second" provider if the blob's MIME type is "video/mp4", to the "third" provider if the blob is stored as a secondary attached file, to the "fourth" provider if the lifecycle state is "approved", to the "fifth" provider if the blob's document is stored in under an "images" folder, and the document is in the default repository, to the "sixth" provider if the document carries the "Versionable" facet, to the "seventh" provider if the document carries either the "Commentable" or the "Auditable" facet, and otherwise to the "other" provider: 

 
 <property name="dc:format=video">first</property>
 <property name="blob:mime-type=video/mp4">second</property>
 <property name="blob:xpath~files/*&#47;file">third</property>
 <property name="ecm:repositoryName=default,ecm:lifeCycleState=approved">fourth</property>
 <property name="ecm:path^.*&#47;images&#47;.*">fifth</property>
 <property name="ecm:mixinType=Versionable">sixth</property>
 <property name="ecm:mixinType=Commentable">seventh</property>
 <property name="ecm:mixinType=Auditable">seventh</property>
 <property name="default">other</property>

You can make use of a record blob provider by using: 

 
 <property name="records">records</property>
 <property name="default">other</property>
Since:
7.3