org.nuxeo.ecm.platform.actions.ActionService
An action is defined by the following properties:
- id: string identifying the action
- label: the action name
- link: string representing the command the action will trigger
- category: a string useful to group actions that will be rendered in the
same area of a page. An action can define several categories.
- filter-ids: id of a filter that will be used to control the action
visibility. An action can have several filters: it is visible if all its
filters grant the access.
- filter: a filter definition can be done directly within the action
definition. It is a filter like others and can be referred by other
actions.
- icon: the optional icon path for this action
- confirm: an optional javascript confirmation string that can be
triggered when executing the command.
- enabled: boolean indicating whether the action is currently active. This
can be used to hide existing actions when customizing the site behaviour.
- order: an optional integer used to sort actions within the same
category. This attribute may be depracated in the future.
It is important to understand that an action does *not* define the way it
will be rendered: this is left to pages, templates and other components
displaying it. Most of the time, actions will be rendered as command links
or command buttons.
Examples:
<action enabled="true" icon="/icons/file.gif" id="TAB_RIGHTS" label="action.view.rights" link="/incl/tabs/document_rights.xhtml">
<category>VIEW_ACTION_LIST</category>
<filter-id>rights</filter-id>
</action>
<action enabled="true" icon="/icons/action_add_file.gif" id="newFile" label="action.new.file" link="create_file">
<category>SUBVIEW_UPPER_LIST</category>
<filter-id>create</filter-id>
</action>
<action enabled="true" icon="/icons/action_add.gif" id="newSection" label="command.create.section" link="#{documentActions.createDocument('Section')}">
<category>SUBVIEW_UPPER_LIST</category>
<filter id="newSection">
<rule grant="true">
<permission>AddChildren</permission>
<type>SectionRoot</type>
</rule>
</filter>
</action>
Actions extension point provides mergeing features: you can change an
existing action definition in your custom extension point provided you use
the same identifier.
org.nuxeo.ecm.core.api.DocumentAdapterService
Extension Point for registering new document adapters
XML extensions may contain any number of 'adapter' elements of the form:
This means any document having the facet 'facet' can be adapted to a 'class' object using the factory 'factory'
The facet attribute is optional and serve to restrict the aplicability of the adapter.
If no facet is specified the adapter will be aapplicable on any document.
org.nuxeo.ecm.platform.io.IOManager
org.nuxeo.ecm.platform.ec.placeful.PlacefulService
This extension is used to register annotations (fully qualified entity classes)
under unit name 'nxplacefulservice'
org.nuxeo.theme.services.ThemeService
org.nuxeo.ecm.platform.archive.service.NXArchiveFactoryService
This service is used to generate the needed archive record implementation.
org.nuxeo.ecm.platform.ui.web.auth.service.PluggableAuthenticationService
Registry for Authentication Plugins.
Authentication plugins are responsible for :
- generating the authentication prompt (if needed)
- get the user identity
- set the LoginModule that will be used for Login
Authentication plugin must implement the NuxeoAuthenticationPlugin interface.
Default implementation of Authentication Plugins are :
- Form based authentication
- HTTP Basic Authentication
org.nuxeo.ecm.core.search.service.SearchServiceImpl
Extension point allowing the contributions of full text blob
extractors.
org.nuxeo.ecm.platform.ui.web.auth.service.PluggableAuthenticationService
Defines the chain of AuthenticationPlugin to use when trying to authenticate.
= The authentication Plugins are tried in the chain order.
org.nuxeo.ecm.platform.url.service.DocumentViewCodecService
Codecs perform the translation between a url and a document view that
holds information about the document context as well as other parameters
(current tab for instance).
org.nuxeo.ecm.platform.comment.service.CommentService
This extension can be used to configure the Comment Service
org.nuxeo.ecm.platform.defaultPermissions.DefaultPermissionService
Extension point for configuring the permissions to be set for different object types.
For instance :
<configuration>
<document type="CommentRoot">
<principal name="members">
<permission isGranted="true">Read</permission>
<permission isGranted="false">Write</permission>
</principal>
</document>
</configuration>
org.nuxeo.ecm.webapp.search.SearchUIConfigService
This extension point is used to register lists of fields.
org.nuxeo.ecm.webapp.trashManagement.TrashManagementService
org.nuxeo.ecm.core.schema.TypeService
Type manager configuration
This includes prefetching options and other global configuration regarding type management
org.nuxeo.ecm.core.search.backend.compass.CompassBackend
Extension point for database connection.
This overrides the connection information that's specified
in main Compass configuration file.
FileConnectionDescriptor: use the standard Lucene file system storage.
Attribute: path. If relative, this will be from NXRuntime's home.
DefaultConnectionDescriptor: clears all contribution to the present
extension point, ie get back to what's specified in main Compass XML
configuration file.
org.nuxeo.theme.webwidgets.Service
org.nuxeo.ecm.platform.workflow.service.WorkflowService
Contribute a workflow definition to a specified target workflow engine formerly contributed as
workflow engine.
Once contributed the workflow definition will be deployed in the specified target workflow engine
backened. Depending on the workflow engine backened, you need to take care of the versioning of
the workflow definition since the definition will be deployed every time this contributions will
be deployed.
Important : the format of the workflow definition is always the native format
of the target workflow engine backened.
You need to specify along with the path of the workflow definition the mimetype of the file holding
the definition. This will be useful in a clustered environement for the core workflow backened
for serialization purpose.
org.nuxeo.runtime.services.deployment.DeploymentService
Deploys the components at the location given by extensions
<deployment src="config/MyConfig.xml" />
org.nuxeo.ecm.directory.ldap.LDAPDirectoryFactory
The directories extension point is used to register LDAP filtering
parameters to identify which part of the LDAP branches are actually
used by Nuxeo EP to fetch its entries.
Examples:
<directory name="userDirectory">
<server>default</server>
<schema>user</schema>
<idField>username</idField>
<passwordField>password</passwordField>
<searchBaseDn>ou=people,dc=example,dc=com</searchBaseDn>
<searchClass>person</searchClass>
<searchFilter>(&(sn=toto*)(myCustomAttribute=somevalue))</searchFilter>
<searchScope>onelevel</searchScope>
<readOnly>false</readOnly>
<cacheTimeout>3600</cacheTimeout>
<cacheMaxSize>1000</cacheMaxSize>
<creationBaseDn>ou=people,dc=example,dc=com</creationBaseDn>
<creationClass>top</creationClass>
<creationClass>person</creationClass>
<creationClass>organizationalPerson</creationClass>
<creationClass>inetOrgPerson</creationClass>
<rdnAttribute>uid</rdnAttribute>
<fieldMapping name="username">uid</fieldMapping>
<fieldMapping name="password">userPassword</fieldMapping>
<fieldMapping name="firstName">givenName</fieldMapping>
<fieldMapping name="lastName">sn</fieldMapping>
<fieldMapping name="company">o</fieldMapping>
<fieldMapping name="email">mail</fieldMapping>
<references>
<inverseReference directory="groupDirectory" dualReferenceField="members" field="groups" />
</references>
</directory>
<directory name="groupDirectory">
<server>default</server>
<schema>group</schema>
<idField>groupname</idField>
<searchBaseDn>ou=groups,dc=example,dc=com</searchBaseDn>
<searchFilter>(|(objectClass=groupOfUniqueNames)(objectClass=groupOfURLs))</searchFilter>
<searchScope>subtree</searchScope>
<readOnly>false</readOnly>
<cacheTimeout>3600</cacheTimeout>
<cacheMaxSize>1000</cacheMaxSize>
<creationBaseDn>ou=groups,dc=example,dc=com</creationBaseDn>
<creationClass>top</creationClass>
<creationClass>groupOfUniqueNames</creationClass>
<rdnAttribute>cn</rdnAttribute>
<fieldMapping name="groupname">cn</fieldMapping>
<references>
<ldapReference directory="userDirectory" dynamicAttributeId="memberURL" field="members" forceDnConsistencyCheck="false" staticAttributeId="uniqueMember" />
<ldapReference directory="groupDirectory" dynamicAttributeId="memberURL" field="subGroups" forceDnConsistencyCheck="false" staticAttributeId="uniqueMember" />
<inverseReference directory="groupDirectory" dualReferenceField="subGroups" field="parentGroups" />
</references>
</directory>
In the previous examples we configured two directories one for the
users and one for the groups of users. Each directory uses a
single schema which is to be registered as any core document
schema and that will be used to build a DocumentModel for each
matching entry of the directory.
The references tags are used to dynamically build nxs:stringList
fields of that schema that are to compute membership relationships
between users and groups or between parent groups and sub groups.
Nuxeo EP provides group resolution for statically dn-referenced
entries (in read and write mode) and for dynamically ldapUrl
matched entries (readonly).
When using dynamic references, caching is advised since dynamic
group resolution can be expensive.
org.nuxeo.ecm.directory.multi.MultiDirectoryFactory
This extension point can be used to register new
multi-directories. The extension can contain any number of
directories declarations of the form:
...
<directory name="userDirectory">
<schema>user</schema>
<idField>username</idField>
<passwordField>password</passwordField>
<querySizeLimit>1000</querySizeLimit>
<source name="ldapusers">
<subDirectory name="authinfo">
<field for="email">mail</field>
</subDirectory>
<subDirectory name="userinfo">
<field for="firstName">givenName</field>
<field for="lastName">sn</field>
<field for="company">o</field>
</subDirectory>
</source>
<source creation="true" name="sqlusers">
<subDirectory name="sqlUserDirectory" />
</source>
</directory>
...
Here is the description for each field:
org.nuxeo.ecm.directory.sql.SQLDirectoryFactory
This extension point can be used to register new SQL-based
directories. The extension can contain any number of directories
declarations of the form:
<directory name="userDirectory">
<schema>vocabulary</schema>
<dataSource>java:/nxsqldirectory</dataSource>
<table>t</table>
<dialect>org.hibernate.dialect.HSQLDialect</dialect>
<idField>username</idField>
<autoincrementIdField>false</autoincrementIdField>
<createTablePolicy>on_missing_columns</createTablePolicy>
<dataFile>setup-hsqldb.csv</dataFile>
<querySizeLimit>1000</querySizeLimit>
<init-dependencies>
<dependency>dir1</dependency>
<dependency>dir2</dependency>
</init-dependencies>
<references>
<tableReference dataFile="user2group.csv" directory="groupDirectory" field="groups" schema="user2group" sourceColumn="userId" table="user2group" targetColumn="groupId" />
</references>
</directory>
Here is the description for each field:
treeManagerComponentBase
This extension point is used to configure the display of the TreeManager.
Possible XML elements are :
showFiles : true/false
showSection : true/false
excludedTypes/type : list of types that won't be displayed in the tree
filterClass : name of the class that implements the DocumentFilter interface.
By default, the filterClass will be implemented by TypeBasedDocumentFilter
org.nuxeo.ecm.platform.workflow.document.service.WorkflowRulesService
Extension allowing the contributions of workflow rules related to document
types.
This is one of the most basic rule allowing to restrict the use of
a given workflow definition to given types.
For instance, one can contribute a rule stating that for a document of
type File only the workflow definitions with names Foo and
bar can be applied.
org.nuxeo.ecm.platform.modifier.service.DocModifierService
Extension Point for registering new document modifiers XML extensions may
contain any number of 'docModifier' elements of the form: -
<docModifier destinationFieldName="content" documentType="File" name="wordMLinjectModifier" order="10" sourceFieldName="content" transformationPluginName="wordMLinjectPlugin">
<customField name="dc:title" xmlNode="o:TitreDocument" />
<customField name="uid" xmlNode="o:HAG" />
... ...
<coreEvent>documentCreated</coreEvent>
<coreEvent>beforeDocumentModification</coreEvent>
...
<customOutputField name="dc:title" outputParamName="titleParam" />
...
</docModifier>
- The specific tag is
<docModifier />
which is mapped on class DocModifierEPDescriptor. The following attributes
are important for document modifier descriptor: - documentType: specifies
the type of the document for which this document modifier will be applied.
In this case the all documents of type 'File' will be taken into
consideration.
An option is to specify many document types that will be associated with
the same modifier. For this, one could use nested elements insted of
"documentType" attribute. Nested elements can be defined as:
- transformationPluginName: specifies the name of the plugin that must be
defined as an NXTransformationPlugin – and registered with Transformation
service. This plugin will need to be able to handle binary data and some
variable parameters list. - sourceFieldName: is the name of the document
property that has the binary value (with runtime instance of type
LazyBlob) - destinationFieldName: the name of the document property to put
the new value (the result of the transformation) into. For a particular
case it may be the same as the sourceFieldName in which case the initial
value is replaced.
- The customField(s) can be defined in any number and must have one of the
following attribute pairs: - name + xmlNode - value + xmlNode
- name is the name of the document property for which value is read and
transferred as value for Property with name defined by xmlNode (due to
change into destPropName) - value is a plain value (string) - defined
inside the xml
- The coreEvent(s) should have as value the name of the core events (as
they are defined in DocumentEventTypes class. If a core event matching one
of the specified event names occurs, the document modifier is applied.
If there are many document modifiers defined for a type of Document they
are applied sequencially.
Note: if no core event is specified, then the transformation will be
applied for default core events: "documentCreated" "documentModified" -
Composition: If a destPropName is defined many times then the values are
concatenated as strings if it is possible
- Triggering: The DocumentModifier is invoked for BEFORE_DOC_UPDATE and
DOCUMENT_CREATED events.
org.nuxeo.ecm.core.schema.TypeService
Extension Point to register new document types.
Document types may implement several schemas and extends other
document types. You can compare document types with java
classes and schemas with java interfaces. Document types may
also contains several facets that define a behavior.
A doctype XML extension may contain several 'doctype' elements.
A doctype element may look like this:
<doctype extends="Document" name="File">
<schema name="common" />
<schema name="file" />
<schema name="dublincore" />
<schema name="uid" />
<facet name="Downloadable" />
<facet name="Versionable" />
</doctype>
org.nuxeo.runtime.LoginComponent
Enable clients to register new security domains in the application
There are 2 predefined security domains that clients may define:
org.nuxeo.theme.services.ThemeService
Extension Point for registering Theme Elements such as Themes, Pages, Sections, Cells, Fragments, etc.
This is for internal use mainly, new types of Elements are not supposed to be registered by third-party applications.
org.nuxeo.ecm.platform.workflow.service.WorkflowService
Extension point allowing the contributions of workflow engine implementation.
The workflow engine implementation should implement the WorkflowEngine interface.
org.nuxeo.ecm.platform.api.WorkflowEngine
Several workflow engine implementations can be registered and one single implementation
can be used as the default one unless another is overriding your contribution. Only one
implementation can possibily be the default backened and you can specify it while registering
your workflow engine implementation. You will have to make sure your default workflow engine implementation
is the latest contributed at deployment time to be sure no other extensions will override yours as
default implementation later during deployment. Please see Nuxeo runtime deployment fragment order.
The default workflow engine implementation in NXP is a JBPM engine implementation.
org.nuxeo.ecm.platform.workflow.jbpm
org.nuxeo.theme.services.ThemeService
org.nuxeo.theme.services.ThemeService
Extension Point for registering Event Listeners.
The XML syntax is:
where:
- 'event' is the name of the Event
- 'handler' is the Event Handler implementing org.nuxeo.theme.events.EventListener
org.nuxeo.ecm.platform.audit.service.NXAuditEventsService
This service registered auditable events.
Registered events are dummy strings for now.
This service is used to filter auditable events from the JMS topic based on their
names.
org.nuxeo.ecm.platform.mimetype.service.MimetypeRegistryService
Extension to register filename extension to mimetype association
rules.
Specify how a given extension should be used to detect a mimetype.
If the extension is marked 'ambiguous', a sniffing of the content
of the file is advised.
For instance :
<fileExtension ambiguous="true" mimetype="text/xml" name="xml" />
org.nuxeo.ecm.platform.content.template.service.ContentTemplateService
org.nuxeo.ecm.platform.content.template.service.ContentTemplateService
org.nuxeo.ecm.directory.DirectoryServiceImpl
This extension point can be used to register directory
factories.
The XML extension can contain an arbitrary number of factory
declarations of the form:
Here, Foo must be a class that implements the org.nuxeo.ecm.directory.DirectoryFactory interface
org.nuxeo.ecm.platform.actions.ActionService
An action filter is a set of rules that will apply - or not - given an
action and a context.
Filter properties :
- id: will be used ot identify the filter from actions definitions.
- rules: set of rules composing the filter
The default filter implementation uses filter rules with the following
properties:
- grant: boolean indicating whether this is a granting rule or a denying
rule.
- permission: permission like "Write" that will be checked on the context
for the given user. A rule can hold several permissions: it applies if
user holds at least one of them.
- facet: facet like "Folderish" that can be set on the document type
(org.nuxeo.ecm.core.schema.types.Type) to desribe the document type
genral behaviour. A rule can hold several facets: it applies if current
document in context has at least one of them.
- condition: EL expression that can be evaluated against the context. The
seam context is made available for conditions evaluation. A rule can hold
several conditions: it applies if at least on of the conditions is
verified.
- type: document type to check against current document in context. A rule
can hold several types: it applies if current document is one of them. The
fake 'Server' type is used to check the server context.
- schema: document schema to check against current document in context. A
rule can hold several schemas: it applies if current document has one of
them.
A filter is granting access to an action if, among its rules, no denying
rule is found and at least one granting rule is found. If no rule is set,
it is granted.
Custom filters can be defined on the extension point, provided they follow
the org.nuxeo.ecm.platform.actions.ActionFilter interface, using
the following syntax:
<object class="my.package.MyFilter" />
Example of action filter using default filter implementation:
<filter id="theFilter">
<rule grant="">
<permission>Write</permission>
<facet>Folderish</facet>
<condition>EL condition</condition>
<type>Workspace</type>
<type>Section</type>
</rule>
<rule grant="false">
<condition>EL condition 1</condition>
<condition>EL condition 2</condition>
</rule>
</filter>
org.nuxeo.theme.services.ThemeService
Extension Point for registering Format filters.
This is for internal use mainly, new types of filters are not supposed to be registered by third-party applications.
org.nuxeo.theme.services.ThemeService
Extension Point for registering Format types such as Style, Layout, Widget.
This is for internal use mainly, new types of Formats are not supposed to be registered by third-party applications.
org.nuxeo.theme.services.ThemeService
Extension Point for registering new types of Fragments.
Fragments produce Model data that is rendered by Views.
The XML syntax is:
where:
- 'class' is the Java class implementing org.nuxeo.themes.fragments.Fragment
- 'model-type' is the type of Model data produced by the Fragment.
The Model type information is optional, however it determines the types of Views that the Fragment will be renderable with.
org.nuxeo.ecm.core.search.service.SearchServiceImpl
Extension point allowing the contributions full text index
definition.
org.nuxeo.ecm.platform.ec.notification.service.NotificationService
This extension point can be used to define general settings. For
now only server prefix E.g. : http://server:port/appName/
org.nuxeo.ecm.platform.uidgen.service.UIDGeneratorService
The extension point provided by this component gives the possibility to
register generators. A generator should be an implementation of
org.nuxeo.ecm.platform.uidgen.UIDGenerator
or a subclass of
org.nuxeo.ecm.platform.uidgen.AbstractUIDGenerator
.
org.nuxeo.ecm.platform.relations.services.RelationService
org.nuxeo.ecm.platform.relations.services.RelationService
org.nuxeo.ecm.core.search.service.SearchServiceImpl
Extension point allowing the contributions of mappings from
docType to indexable resources names.
org.nuxeo.ecm.core.search.service.SearchServiceImpl
Extension point allowing the contributions of indexing event
definitions.
org.nuxeo.ecm.core.search.service.SearchServiceImpl
Extension point allowing the contributions of parameters for
the indexing thread pool.
org.nuxeo.ecm.platform.forms.layout.WebLayoutManager
A layout is a group of widgets that defines the rendering of a document in
a given mode.
Default mode values are:
- view: the view mode;
- edit: the edit mode;
- create: the create mode;
- any: any mode; this is the default value in case no value is given for a
specific mode. When applying to lists of values, values given for this
mode will be merged with values given for the specific mode.
A specific mode is also accepted when specifying a widget mode: "hidden".
It is used to avoid rendering the widget at all.
Layout properties :
- name: the layout name; this is an identifier for this layout to the
layout service and it can be used in a document type definition.
- templates: a template can be provided to control the layout rendering.
Different layouts can be used given the mode. The test for the layout mode
can also be done in the template itself.
- rows: rows describe the organization of widgets within the layout.
Several widgets can be placed in the same row. When using the default
layout template, a table is used to display each row in a table row, and
widgets at the same row will be displayed on different columns in this
row.
- widgets: widgets with names used in the layout rows configuration. They
can hold specific properties given the widget type.
Widget generic properties:
- name: this is the widget identifier within this layout; it can be used
to reference this widget in the layout rows.
- type: the widget type defines how the widget will be displayed in a
given mode.
- labels: labels to use for the widget in a given mode.
- helpLabels: help labels to use for the widget in a given mode.
- widgetModes: mode to use for this widget given the layout/parent widget
(used to override the parent mode) ; can be useful, for instance, to state
that a field will only be displayed as "read-only" whatever the layout
mode.
- translated: true or false, defines if the widget labels and help labels
have to be translated (in case these labels should match jsf messages).
- fields: fields that will be taken into account when displaying/editing a
document field.
- properties: map of properties that will apply to the jsf component built
in a given mode by the widget type. For instance, in a text widget, all
properties defined in the view mode will be dealt as attributes on a
<h:outputText /> tag, and properties defined in the edit mode will
be dealt as attributes on a <h:inputText /> tag.
- subWidgets: list of sub widgets to use provided the widget type knows
how to handle them. each sub widget definition is like a widget
definition.
Example of layout using default widget types:
<layout name="heading">
<templates>
<template mode="any">
/layouts/layout_default_template.xhtml
</template>
</templates>
<rows>
<row>
<widget>title</widget>
</row>
<row>
<widget>description</widget>
</row>
</rows>
<widget name="title" type="text">
<labels>
<label mode="any">title</label>
</labels>
<translated>true</translated>
<fields>
<field>dc:title</field>
</fields>
<properties mode="edit">
<property name="required">true</property>
</properties>
<properties mode="create">
<property name="required">true</property>
</properties>
</widget>
<widget name="description" type="textarea">
<labels>
<label mode="any">description</label>
</labels>
<translated>true</translated>
<fields>
<field>dc:description</field>
</fields>
</widget>
</layout>
org.nuxeo.ecm.core.lifecycle.LifeCycleService
Extension point for registering life cycle definition.
A life cycle is a state-transition model described as an XML document.
A life cycle within Nuxeo Core describes only the states and the transitions
without any security policy whatsoever. For instance, the workflow service
(or BPM service) will be responsible of the security policy and actors
involved.
org.nuxeo.ecm.core.lifecycle.LifeCycleService
Extension point for registering life cycle manager.
Life cycle manager are responsible of the life cycle properties storage and
are bound to a life cycle.
Nuxeo core default life cycle manager is a JCR life cycle manager. It means
the life cycle properties for a given document will be stored in the JCR
along with the other document properties. You may define another type of
life cycle manager such as an SQL life cycle manager that would store the
life cycle properties in a SQL DB aside the JCR.
The life cycle properties are :
org.nuxeo.ecm.webapp.documentsLists.DocumentsListsService
org.nuxeo.ecm.core.listener.CoreEventListenerService
Extension point for registering event listeners.
An event listener has the following properties:
- name: identifier for this listener. It must be unique within the
application.
- class: the class to use for this event listener, see below for
implementation requirements.
- order: the order in which the listener will be notified of an event.
This may be useful if different listeners have to react in a specified
order. If no order is given, order 0 is assumed. Negative orders are
accepted. Listeners can share the same order, but the notification order
will not be reliable.
- eventId: event ids this listener processes. Multiple values can be
defined. If no eventId attributes are defined, the listener is notified
for all events. It is then responsible for filtering events it has to
process in its notifyEvent method.
Event listeners must implement the
org.nuxeo.ecm.core.listener.EventListener interface and will be notified
on each call back : public void notifyEvent(CoreEvent coreEvent); Core
Event listeners are synchronous. Thus they should be implemented to
rather perform non time consuming heavy computing that would decrease
core txn performances.
Nuxeo core defines a default set of event ids that are defined in :
org.nuxeo.ecm.core.api.event.DocumentEventTypes. Though, you can extend
them and define your own event ids and listeners reacting on them.
org.nuxeo.runtime.EventService
Enable clients to register event listeners to one or more topics
org.nuxeo.ecm.platform.util.LocationManagerService
This extension point can be used to register new repository locations (new core instances).
The location registry is typically used to build the list of available servers on the first screen of the web app.
The XML extension can contain a arbitrary number of location declaration if the form :
This extension point can be used to disable a previously declared location :
The locationURI tag must point on an existing core instance that was declared using :
org.nuxeo.ecm.platform.audit.service.NXAuditEventsService
This service registered loge entry factory XXX
org.nuxeo.ecm.platform.mimetype.service.MimetypeRegistryService
Extension allowing one to register mimetypes.
A mimetype holds meta information about a given mimetype.
<mimetype binary="true" iconPath="pdf.png" normalized="application/pdf">
<mimetypes>
<mimetype>application/pdf</mimetype>
</mimetypes>
<extensions>
<extension>pdf</extension>
</extensions>
</mimetype>
org.nuxeo.ecm.core.search.api.client.querymodel.QueryModelService
Registry for QueryModelDescriptor instances.
org.nuxeo.ecm.webapp.pagination.ResultsProviderService
org.nuxeo.theme.services.ThemeService
Extension Point for registering new types of Models.
The XML syntax is:
where:
- 'class' is the Java class implementing org.nuxeo.themes.models.Model.
org.nuxeo.theme.services.ThemeService
org.nuxeo.ecm.platform.ec.notification.service.NotificationService
This extension point can be used to specify the notifications.
org.nuxeo.ecm.platform.workflow.document.service.WorkflowRulesService
Extension allowing the contributions of workflow rules related to application
level paths.
This rule is pretty useful for restricting the use of given workflows within
sub-paths of the application
For instance, you could specify different workflow path rules for the same
document type within the Workspaces and Sections of NXP.
Typical case is for publication versus review on the same doc type in Sections
and Workspaces.
org.nuxeo.ecm.core.security.SecurityService
Extension point to register permission definitions or override
existing permissions.
Example to define a single atomic permissions that are not meant
to be displayed in the rights management screen of folders:
<permission name="Browse" />
<permission name="ReadVersion" />
<permission name="ReadProperties" />
<permission name="ReadChildren" />
<permission name="ReadLifeCycle" />
<permission name="ReviewParticipant" />
Example to define a compound permission that holds many related
atomic permissions into a single high level (role-like)
permission:
<permission name="Read">
<include name="Browse" />
<include name="ReadVersion" />
<include name="ReadProperties" />
<include name="ReadChildren" />
<include name="ReadLifeCycle" />
<include name="ReviewParticipant" />
</permission>
Note that each of the included permissions should have been
previously registered with their on <permission/>
declaration.
It is later possible to override that definition in another
contribution to that extension-point to add a new permission
'CustomPerm' and remove 'ReviewParticipant':
<permission name="CustomPerm" />
<permission name="Read">
<include name="CustomPerm" />
<remove name="ReviewParticipant" />
</permission>
Eventually the permissions declaration also accept 'alias' tags to
handle backward compatibility with deprecated permissions:
<permission name="ReadVersion">
<alias name="Version" />
</permission>
NB: the alias feature is parsed by the extension point but the
underlying SecurityManager implementation does not leverage it
yet.
org.nuxeo.ecm.core.security.SecurityService
Extension point to register permission visibility in user
interface or override existing settings.
Example to define the default list of permissions that are
manageable through the UI screens:
<visibility>
<item order="10" show="true">Read</item>
<item order="50" show="true">ReadWrite</item>
<item order="100" show="true">Everything</item>
</visibility>
This list of options items will be displayed if no type specific
settings are registered.
Example to define the default list of permissions that are
specific to the Section document type:
<visibility type="Section">
<item order="10" show="true">Read</item>
<item order="100" show="true">Everything</item>
</visibility>
Note: the 'show' attribute defaults to 'true' and the 'order'
attribute defaults to '0'.
org.nuxeo.theme.services.ThemeService
Extension Point for registering perspectives.
The XML syntax is:
where:
- 'name' is the name of perspective (lower-case alpha-numeric characters, underscores and hyphens)
- 'title' is the title of the perspective
org.nuxeo.ecm.platform.login.LoginPluginRegistry
This extension point can be used to register new Login Plugin.
The XML extension can contain a arbitrary number of Plugin declaration if the form :
...
The parameters tag can be repeated an arbitrary number of time and can be used to pass configuration to the plugin.
The class attribute defines the class implementing the org.nuxeo.ecm.platform.login.LoginPlugin interface.
org.nuxeo.ecm.platform.filemanager.service.FileManagerService
The plugin system for the FileManager give the possibility to
register extenstion that will be responsible for creating a
document from a given mime-type. The plugin should implement the
org.nuxeo.ecm.platform.filemanager.interfaces.Plugin interface.
The registration of a file importer can be done like this:
<plugin class="com.example.MyFileImporterImplementationClass" name="myCustomFileImporter">
<filter>text/plain</filter>
</plugin>
The filter tag is used to know what mime-types cab be used with
the plugin.
Similarly, to override the default behavior to import folders,
custom folder importers are registered as follows:
<folderImporter class="com.example.MyFolderImporterImplementationClass" name="myCustomFolderImporter" />
The latest registered folder importer will be used in place of any
other previously registered folder importer.
org.nuxeo.ecm.platform.transform.service.TransformService
Extension allowing one to register transformation plugins
A transformation plugin must implements :
org.nuxeo.ecm.platform.transform.interfaces.PLugin and should extend :
org.nuxeo.ecm.platform.transform.plugin.AbstractPlugin
A plugin is responsible for a given transformation of one or several input files to one or
several output files.
For instance a plugin converting pdf to text using pdfbox :
<extension point="plugins" target="org.nuxeo.ecm.platform.transform.service.TransformService">
<plugin class="org.nuxeo.ecm.platform.transform.plugin.pdfbox.impl.PDFBoxPluginImpl" destinationMimeType="plain/text" name="pdf2text">
<sourceMimeType>application/pdf</sourceMimeType>
</plugin>
</extension>
You can find the plugin implementation class over there :
org.nuxeo.ecm.platform.transform.plugin.pdfbox.impl.PDFBoxPluginImpl
:XXX: explain plugin options.
org.nuxeo.ecm.platform.ui.web.htmleditor.service.HtmlEditorPluginServiceImpl
This extension point let you contribute new plugins to TinyMCE.
Sample contribution :
org.nuxeo.ecm.core.security.PolicyService
org.nuxeo.theme.services.ThemeService
Extension Point for registering Presets.
Presets are stored in Palettes.
The XML syntax is:
where:
- 'name' is the name of the Palette.
- 'src' is the source of the Palette (String)
- 'category' is the palette category (optional)
Supported palette types are:
- *.properties (Properties file)
- *.aco (Photoshop color palettes)
- *.gpl (Gimp palettes)
org.nuxeo.ecm.platform.versioning.service.VersioningService
This extension point allows to define which properties should be used to
set versions given a document type.
If no property definition is found for the document type, default
properties set on the service will be used (uid:major_version and
uid:minor_version).
<versioningProperties>
<majorVersion>my:major_version</majorVersion>
<minorVersion>my:minor_version</minorVersion>
<documentType>File</documentType>
<documentType>Note</documentType>
</versioningProperties>
org.nuxeo.ecm.core.api.DocumentAdapterService
Extension Point for registering new property factories
org.nuxeo.ecm.core.schema.TypeService
Extension point to register type providers. Type providsers are usually used to import types
defined on remote servers
org.nuxeo.theme.webwidgets.Service
org.nuxeo.ecm.platform.publishing
Extension point that permit to define the field holding the valid
date for publishing.
org.nuxeo.ecm.platform.publishing
Extension point where to contribute the a rule aimed at computing the
validators for a document just request for publishing.
org.nuxeo.theme.services.ThemeService
Extension Point for adding Registries. Registries are used internally by NXThemesCore to store information about registered Elements, Fragments, Models, Formats, etc.
This is for internal use mainly, new registries are not supposed to be created by third-party applications.
org.nuxeo.ecm.core.api.repository.RepositoryManager
Extension points for registering new repositories.
Be aware that this extension point is not declaring repository backends but only
a client descriptor for repositories already registered in the system using
org.nuxeo.ecm.core.repository.RepositoryService#repository extension point
In a future these 2 extension points may be merged.
A repository is defined by an unique name (in the application) an optional label
and 0 or more properties that are dependent on the repository implementation
org.nuxeo.ecm.core.repository.RepositoryService
Extension point to register new repositories.
The extension should use the format:
... random XML content ...
The repository tag may contains any valid XML content that can be used by to specify
repository implementation specific configuration data.
The name of the repository must be unique in the application
org.nuxeo.ecm.core.search.service.SearchServiceImpl
Extension point allowing the contributions of indexing
configuration per schema.
org.nuxeo.ecm.core.search.service.SearchServiceImpl
Extension point allowing the contributions of indexing
resource type.
org.nuxeo.ecm.platform.relations.services.RelationService
org.nuxeo.theme.services.ThemeService
Extension Point for registering Resources.
The XML syntax is:
where:
- 'name' is the name of the Resource. Supported extensions are '.js', '.css' and '.json'.
- 'path' is the path of the Resource to be loaded by the class loader.
- 'require' is the name of another Resource that is required. (Optional)
Several resources can be required:
org.nuxeo.ecm.platform.ui.web.restAPI.service.PluggableRestletService
This extension point let you contribute new Restlets : ie, new REST API executor.
Sample contribution :
org.nuxeo.ecm.webapp.search.SearchUIConfigService
This extension point is used to register lists of fields.
org.nuxeo.ecm.platform.versioning.service.VersioningService
EP 'rules' - one can define rules that will be applied in different cases
when a request for version incrementation appears.
May contain any number of 'docModifier' elements of the form:
<versioningRuleEdit action="ask_user" lifecycleState="*" name="sampleEditRuleAnyState">
<includeDocType>File</includeDocType>
<option default="true" value="no_inc" />
<option value="inc_minor" />
<option lifecycleTransition="transition-name" value="inc_major" />
</versioningRuleEdit>
<createSnapshot default="true" name="sampleSR" optional="true">
<lifecycleState>project</lifecycleState>
or specify an implementation of org.nuxeo.ecm.platform.versioning.api.Evaluator
<evaluator>com.abc.versioning.SnapshotOptionEvaluator"</evaluator>
</createSnapshot>
Conditions defined by evaluators in createSnapshot are checked if there is a match for
specified lifecycle states.
The <versioningRuleAuto> is applied in the following situations:
org.nuxeo.ecm.platform.scheduler.core.service.SchedulerRegistryService
Extension allowing the registration of schedules.
This is similar to a cron job sending events.
A scheduler definition contains information about what event is sent,
when, and under what identity.
For instance :
<schedule id="mySchedule">
<username>Administrator</username>
<password>Administrator</password>
<eventId>myEvent</eventId>
<eventCategory>default</eventCategory>
<cronExpression>0 0 3 1 * ?</cronExpression>
</schedule>
org.nuxeo.ecm.core.schema.TypeService
Extension Point to register new schemas.
Schemas are defined using XSD files.
The schema extension XML may containg several 'schema' objects as
the following ones:
<schema name="common" src="schema/common.xsd" />
<schema name="dublincore" prefix="dc" src="schema/dublincore.xsd" />
The name attribute uniquely identify the schema, the src attribute specify
the path to that schema (relative to the bundle root) and the prefix is used as
a prefix (short name) of the schema namespace.
The schema namespace is the targetNamespace defined inside the XSD file
Note that multiple schemas can share the same target namespace and prefix
org.nuxeo.runtime.ScriptingComponent
Extension to regsiter scripts that will be cached in a compiled form
org.nuxeo.ecm.core.search.service.SearchServiceImpl
Extension point allowing the contributions of search engine
plugin implementation.
org.nuxeo.ecm.directory.ldap.LDAPDirectoryFactory
The servers extension point is used to register network connection
parameters to a pool of LDAP servers.
Examples:
<server name="default">
<ldapUrl>ldap://localhost:389</ldapUrl>
<ldapUrl>ldap://server2:389</ldapUrl>
<ldapUrl>ldaps://server3:389</ldapUrl>
<bindDn>cn=nuxeo5,ou=applications,dc=example,dc=com</bindDn>
<bindPassword>changeme</bindPassword>
</server>
The ldapUrl tags point to server (IP address or DNS name) and
ports. If more than one is provided, the Nuxeo EP will use a pool
of load balanced connections to each server. They are assumed to
be replicated versions of a master server that should belong to
the list.
The bindDn and bindPassword credentials are used by Nuxeo EP to
access the content of the LDAP servers. It should have the read
permission to any entry that is to be used by Nuxeo EP and write
right to branches were Nuxeo EP is supposed to create or edit
entries.
For instance, in OpenLDAP you should have ACLs such as:
access to attrs="userPassword"
by dn="cn=ldapadmin,dc=example,dc=com" write
by dn="cn=nuxeo5,ou=applications,dc=example,dc=com" write
by anonymous auth
by self write
by * none
access to dn.base="" by * read
# nuxeo5 can manage the ou=people branch
access to dn.subtree="ou=people,dc=example,dc=com"
by dn="cn=nuxeo5,ou=applications,dc=example,dc=com" write
by users read
by self write
by * none
access to dn.subtree="ou=groups,dc=example,dc=com"
by dn="cn=nuxeo5,ou=applications,dc=example,dc=com" write
by users read
by self write
by * none
# The admin dn has full write access
# other
access to *
by dn="cn=ldapadmin,dc=example,dc=com" write
by users read
by * none
User authentication is done using a bind method against the user
provided login and password from the login form and not the bindDn
/ bindPassword credentials.
org.nuxeo.ecm.platform.api.PlatformService
Define an extension point to register new platform servers. Platform
servers are parts of the same application that are deployed on different
JVMs
Each server may expose a set of services and repositories.
Exposed services are defined as bindings between the service class and a
JNDI name where the service (bean service) can be located remotely. If the
client try to get a service not defined by any server the platform will
try to lookup it using the local NXRuntime.
The extension should use the format:
<server host="localhost" jndiContextFactory="org.nuxeo.ecm.platform.api.DefaultJndiContextFactory" jndiPrefix="nuxeo/" jndiSuffix="/remote" name="core" port="1099" repositoryConnector="org.nuxeo.ecm.platform.api.DefaultRepositoryConnector" serviceConnector="org.nuxeo.ecm.platform.api.DefaultServiceConnector">
<service class="org.nuxeo.ecm.platform.type.TypeManager" jndiName="%TypeManager" private="false" />
...
<repository connector="connectorClass" description="A description" name="demo" />
...
</server>
All attributes other than name are optional and have as default values the
values in the example above. The host attribute is optional only if you
are contributing new service and repository bindings to a server delcared
by other bundle.
org.nuxeo.runtime.api.ServiceManagement
Define a server that expose services.
A server is
org.nuxeo.runtime.api.ServiceManagement
Define a service binding.
Services are part of a group. If no group is specified the root group will be used
Groups are bound to servers. If a group is not bound services in the group will be considered
to be part of the root group
Services are defined by a class and an optional name. The service locator used
for the server exposing the service will locate the service using these informations.
You can optionally specify a custom locator by using the "locator" sub-element.
Services bindings may also define an adapter that will be used to adapt the service immediately
after its instantiation. This can be used to decorate services (for example you can decorate a service to
enable caching on the client side) or to handle session oriented services.
This way you can start the session using the adapter.
org.nuxeo.ecm.core.api.CoreService
Used to register new session factories. Contributions for this extension
point are of the form:
org.nuxeo.theme.services.ThemeService
Extension Point for registering navigation shortcuts (access keys, ...)
The XML syntax is:
where:
- 'key' is the shortcut key..
- 'target' is the associated URL.
org.nuxeo.theme.services.ThemeService
Extension Point for registering Standalone Filters.
The XML syntax is:
where:
- 'engine' is the name of the Engine for which the Filter will be applied. (Optional)
- 'class' is the Java class extending org.nuxeo.theme.rendering.StandaloneFilter
org.nuxeo.ecm.platform.ui.web.auth.service.PluggableAuthenticationService
Defines a list of URL prefix that is considered safe to start a new session.
Typically, in default webapp you will have :
- GET url patterns
- nxstartup.faces
- RSS/ATOM get URL
org.nuxeo.ecm.platform.ec.notification.service.NotificationService
This extension point can be used to define templates for
notifications.
Inside the template files are supported by default these
expressions :
${docId} - displays the UID of the document that produced the
notification
${author} - displays the user that produced the event
${dateTime) - date and time when it happened - must be formatted
according to the freemaker rules
${docUrl} - For now it displays the path to follow to get to the
document that was the source of the event
${docTitle} - displays the title of the document that produced the
notification
${newDocUrl} - this can display the path of the document
modified/created inside the document that produced the
notification. This newDoc is the child of the producer document.
${newDocTitle} - the same that ${newDocUrl}, but displays the
title.
${newDocId} - the same that ${newDocUrl}, but displays the UID.
If you need to add some more variables into your templates, just
put the data you need to display in the notification in the
eventInfo map of the JMS message that is sent to queue
topic/NXPMessages.
The same goes for subject but in this case there is no need to
define a template. Just put the string that you need to have as
subject and if it contains dynamic elements ${XXX}, they will be
rendered just like it happens in the body.
For example :
When creating the message : mesage.getEventInfo().put("docSize",
sizeOfDocument);
In your template file : The document has ${docSize}KB.
org.nuxeo.theme.services.ThemeService
org.nuxeo.ecm.platform.transform.service.TransformService
Extension allowing one to register transformation chains.
A transformer takes given sources and transform them using default and/or runtime
options. The transformation is performed by underlying plugins defined in a ordered
plugins chain.
In most of the cases you won't need to deploy your own transformer. You will simply need to
contribute a well configured transformer extension.
:XXX: explain transformation options forwarded to plugins as options
org.nuxeo.ecm.webapp.directory.DirectoryTreeService
org.nuxeo.ecm.core.schema.TypeService
This extension point let you contribute new type helpers that control extended
type handling like encondig, decodig values etc.
A contribution example:
<helper class="BlobHelper" schema="file" type="content" />
org.nuxeo.ecm.core.lifecycle.LifeCycleService
Extension point for registering document type to life cycle mappings.
For instance, you can specify that a documen type File will follow a
default life cycle where default is the name of a registered
life cycle.
org.nuxeo.ecm.platform.types.TypeService
A document type has the following properties:
- id: its string identifier
- coretype: its core type identifier. The core type holds information
about the document schemas org.nuxeo.ecm.core.schema.types.Type.
WARNING: id and coretype currently need to be identical in the definition.
- icon: icon path used to represent the document type.
- label: string title.
- subtypes: list of the allowed sub document types for a given container.
This can be used to filter some document types creation and copy to
specific kinds of container documents.
- default-view: this view will be returned when accessing the document.
- create-view: this view will be returned when creating the document.
- edit-view: this view can be used to display the document default edit
page.
- views: other views can be defined, so that they can be customized easily
and trigger specific behaviour. For instance, defining a view named
'after-edit' on the document will allow to parameter which view should be
displayed after the document edition.
WARNING: the views definitions and associated behaviours may change in the
future. You should avoid customizing more than default-view and
create-view for now.
- layouts: the list of layouts to use in a given mode. Usual modes are
"view", "create" and "edit". When no layouts are defined for a specific
mode, layouts for the mode "any" are taken.
- layout: deprecated layout configuration.
Example:
<type coretype="Domain" id="Domain">
<label>Domain</label>
<icon>/icons/folder.gif</icon>
<default-view>view_documents</default-view>
<subtypes>
<type>WorkspaceRoot</type>
<type>SectionRoot</type>
</subtypes>
<layouts mode="any">
<layout>heading</layout>
</layouts>
</type>
Types extension point provides merging features: you can change an
existing type definition in your custom extension point provided you use
the same identifier.
org.nuxeo.ecm.webapp.security.UIPermissionService
org.nuxeo.ecm.platform.ui.web.rest.URLService
URL patterns are used on the web layer to perform actions when a url is
entered, and to rewrite urls after a post.
They are designed to use a given codec.
org.nuxeo.ecm.platform.usermanager.UserService
Configure the userManager.
The extension should use the format:
<userManager>
<users>
<directory>somedirectory</directory>
<emailField>mail</emailField>
<searchFields append="true">
<searchField>first</searchField>
<searchField>last</searchField>
</searchFields>
<listingMode>tabbed</listingMode>
<anonymousUser id="Anonymous">
<property name="first">Anonymous</property>
<property name="last">Coward</property>
</anonymousUser>
</users>
<defaultAdministratorId>admin</defaultAdministratorId>
<userSortField>sn</userSortField>
<userPasswordPattern>^[a-zA-Z0-9]{5,}$</userPasswordPattern>
<groups>
<directory>somegroupdir</directory>
<membersField>members</membersField>
<subGroupsField>subgroups</subGroupsField>
<parentGroupsField>parentgroup