Manipulating Content: The SlingPostServlet

Multiple Ways to Modify Content

As always in life there is more than one way to do it. So to modify content in a JCR repository underlying Sling, you have multiple options, two of which are WebDAV and the Sling default POST Servlet also called the SlingPostServlet. This page is about how you can modify - create, modify, copy, move, delete - content through the SlingPostServlet. In addition it also explains how to extend the SlingPostServlet with new operations.

What is Content anyway ? In the following discussion, I use the terms Content and Item interchangeably. With Content I just mean some data to be stored in the JCR repository to be later used as the basis for some presentation. In this sense Content is a rather conceptual term. Item is the name of the parent interface of the JCR Node and Property interfaces. When speaking of Items we mean some actual data stored in the repository ignoring whether the data is actually stored as a Node with child nodes and properties or just a single Property.

Quickstart: Creating Content

To create content you simply send an HTTP POST request using the path of the node to store the content in and include the actual content as request parameters. So one possibility to do just that is by having an HTML Form like the following:

<form method="POST" action="http://host/some/new/content" enctype="multipart/form-data">
   <input type="text" name="title" value="" />
   <input type="text" name="text" value="" />
</form>

This simple form will set the title and text properties on a node at /some/new/content. If this node does not exist it is just created otherwise the existing content would be modified.

Similarly you can do this using the curl command line tool:

$ curl -Ftitle="some title text" -Ftext="some body text content" http://host/some/new/content

You might want to use a specific JCR node type for a newly created node. This is possibly by simply setting a jcr:primaryType property on the request, e.g.

$ curl -F"jcr:primaryType=nt:unstructured" -Ftitle="some title text" -Ftext="some body text content" http://host/some/new/content

Similary you may assing JCR mixin node types using the jcr:mixinTypes property and a Sling resource type using the sling:resourceType property. For example:

$ curl -F"sling:resourceType=sling:sample" -Ftitle="some title text" -Ftext="some body text content" http://host/some/new/content

Preface: multipart/form-data POSTs

Sometimes you might want to have the content modifications applied in a certain order. This is particularly interesting if you use fields to create child nodes and if you want to stipulate a certain child node order based on the form fields.

In this case ensure you are submitting the POST request using multipart/form-data encoding. This preserves the order of parameter application according to the original HTML form. To this avail ensure to always include the enctype="multipart/form-data" attribute with the <form> tag.

This support requires Sling Engine 2.1.0 and the Sling Default Post Servlet 2.0.6.

SlingPostServlet Operations

Note that the launchpad/testing module contains a number of integration tests for the SlingPostServlet. Most of these tests are fairly readable, and can be used to find out more details about the servlet's behavior.

The SlingPostServlet is actually just a frontend to the actual operations. To select the actual operation to execute, the :operation request parameter is used. Out of the box, the SlingPostServlet supports the following operations:

• property not set or empty – Create new content or modify existing content
• delete – Remove existing content
• move – Move existing content to a new location
• copy – Copy existing content to a new location
• nop – Explicitly requests to do nothing and just sets the response status

All these operations always operate on the resource of the request as returned by SlingHttpServletRequest.getResource(). Some operations require additional parameters to be set to operate completely.

Content Creation or Modification

The simplest and most common use case, probably, is content creation and modification. We already saw an example above in the quickstart section. In this section we elaborate more on the concrete stuff.

First, the request URL indicates the actual repository node to be handled. If the URL addresses an existing node, the request parameters just provide values for the properties to be set on the existing node.

If the resource of the request is a synthetic resource, e.g. NonExistingResource or StarResource, a new item is created. The path (including name) of the item to be created is derived from the resource path:

• If the resource path ends with a /* or / the name of the item is automatically created using a name creation algorithm taking into account various request parameters.
• Otherwise the resource path is used as the path and name of the new item.

In both cases the path may still include selectors and extensions, which are cut off the path before finding out, what to do.

To illustrate this algorithm, lets look at some examples:

Setting Property Values

Setting property values is as simple as just adding a request parameter whose name is the name of the property to be set and whose value is the value to be assigned to the property. We already saw how to do this in the quick start examples above.

Here is another example show a simple HTML form to create a new node with an automatically created name:

<form method="POST" action="/content/page/first" enctype="multipart/form-data">
    <input type="text" name="title" />
    <input type="text" name="text" />
    <input type="Submit" />
</form>

If this form is submitted with title and This is some Text as values for the title and text fields, resp., a new node is created at the path /content/page/first and the title and text properties set to the respective field values. If a node at /content/page/first already existed before submitting the form, the title and text properties are just updated to the new values from the form fields.

If a parameter has multiple values, the respective property will be created as a multi-value property. So for example the command line:

$ curl -Fmulti=one -Fmulti=two http://host/content/page

Would assign the /content/page/multi property the value [ "one", "two" ].

This is pretty much all there is to know about creating and modifying content. The following sections will now introduce more functionality which help you with more fine-grained control in your content management application.

File Uploads

File uploads are typically done using the <input type="file""/> element of an HTML form and ensuring the correct form encoding. The SlingPostServlet handles uploaded files specially, in that the file data is not simply written into a property, but a node is actually created with three properties:

• jcr:data – The actual file contents
• jcr:lastModified – The time stamp of processing the uploaded file
• jcr:mimeType – The MIME type from the original file submission (if contained in the file body part) or derived from the original file name

The name of the node is either taken from the parameter name or if the name is * from the name of the uploaded file.

The primary node type of the uploaded file is selected using the following algorithm:

1. If a @TypeHint suffixed parameter (see below for a description) is present check whether the value is a known non-mixin node type. If so, the node is created with this primary node type.
2. If a @TypeHint suffixed parameter is not present or the value does not denote an existing non-mixin node type, the node will be created as an nt:file node if the parent node is of type nt:folder. Otherwise the node will be created with primary node type nt:resource.

If the node to be created is nt:file, the actual file data will really be stored in the jcr:content child node of the new nt:file node whose primary node type is then set as nt:resource.

Example 1: Upload an image to a node named image below /content/page:

<form method="POST" action="/content/page" enctype="multipart/form-data">
    <input type="file" name="image" />
    <input type="Submit" />
</form>

Example 2: Upload a file as a node of type nt:file below /content/folder:

<form method="POST" action="/content/page" enctype="multipart/form-data">
    <input type="file" name="*" />
    <input type="hidden" name="*@TypeHint" value="nt:file" />
    <input type="Submit" />
</form>

Assuming the user selected a file named myImage.jpg the uploaded file would be stored in an nt:file node at /content/folder/myImage.jpg.

Omitting Some Parameters

There may be times, that you have forms which contain a lot of fields, which you do not want to actually store in content. Such forms usually are created using some client-side GUI library which uses the fields for its own purposes. To be able to easily differentiate between real content to be actually stored and such control parameters, you may prefix the names of the fields destined for content with a dot-slash (./).

As soon as the SlingPostServlet encounters parameters prefixed with dot-slash, only those parameters are considered for content updates while all other parameters not prefixed are just ignored. In addition to dot-slash prefixed parameters, also parameters prefixed with dot-dot-slash (../) and slash (/) are considered in this situation.

For example, the following form only uses the first two fields for content update and ignores the rest:

<form method="POST" action="/content/page/first" enctype="multipart/form-data">
    <input type="text" name="./title" />
    <input type="text" name="../first/text" />
    <input type="hidden" name="control0" /><!-- ignored -->
    <input type="hidden" name="control1" /><!-- ignored -->
    <input type="Submit" />
</form>

Because the SlingPostServlet encounters the ./title parameter, only parameters prefixed with dot-slash, dot-dot-slash and slash are considered for content update. In this case this would ./title and ../first/text while control0 and control1 are not prefixed and thus ignored.

Background: The name of the parameters used for content update are actually intended to be relative path names of the properties to modify. So in effect using the field name text is equivalent to ./text – dot-slash meaning relative to the current node identified by the action attribute value for form tag – or ../first/text if first is the name of the node to modify – dot-dot-slash meaning relative to the parent node of the node identified by the action attribute value of the form tag.

Parameters whose name start with a colon (:) are always ignored by the SlingPostServlet with respect to content update. The reason is that the prefixing colon is intended as a marker for SlingPostServlet control parameters.

Controlling Content Updates with @ Suffixes

Generally just creating forms with parameters and their values suffices it completely. Sometimes, though, you want to have more control on how the parameter values are actually stored in the properties. For example, you want to set a property to a default value if the user did provide an actual value. Or you might want to store a parameter explicitly with a given data type, such as numeric, boolean etc.

The SlingPostServlet provides such property control in the form of @ suffixed parameters, which are now presented.

The @ suffixed parameters are not used on their own but always in conjunction with a plain parameter. The part of the parameter name before the @ suffix is used in this case for correlation and must match exactly the name of the parameter to which the @ suffixed parameter belongs.

For example, the parameter width@TypeHint applies to the width parameter and the ./height@TypeHint parameter applies to the ./height parameter. As can be seen, the correlation between the parameters is a simple case-sensitive string comparison. That is the widht@TypeHint parameter would not apply to the ./width even though both parameters address the same property but they do not have a string match.

@TypeHint

Parameters with the @TypeHint suffix may be used to force storing the named parameter in a property with the given type. The value of the @TypeHint parameter, if applied to a parameter for a property, is the JCR property type name. If the @TypeHint parameter is applied to a field upload parameter, the value is used to indicate the JCR primary node type for the node into which the uploaded file is stored.

If the @TypeHint ends with "[]", it indicates a multi-value property. A multi-value property is usually auto-detected if there are mutliple values for the property (ie. request parameter). But if only a single value is present in the request, the desired property type needs to be explicitly defined as multi-value by stating @TypeHint=<type>[].

Example: The following form sets the numeric width, the boolean checked, and the multi-valued hobbys (with 3 values to enter) properties:

<form method="POST" action="/content/page/first" enctype="multipart/form-data">
    <input type="text" name="width" />
    <input type="hidden" name="width@TypeHint" value="Long" />
    <input type="checkbox" name="checked" />
    <input type="hidden" name="checked@TypeHint" value="Boolean" />
    <input type="text" name="hobbys"/>
    <input type="text" name="hobbys"/>
    <input type="text" name="hobbys"/>
    <input type="hidden" name="hobbys@TypeHint" value="String[]" />
    <input type="Submit" />
</form>

In real applications you would need some javascript that allows to add/remove values, ie. add/remove inputs with the name "hobbys". Or a pure javascript based form post would be used, that gathers the properties to update programmatically, but the additional parameter hobbys@TypeHint=String[] would be the same.

The @TypeHint suffixed parameter is assumed to be single-valued. If the parameter has multiple values, only the first is actually used.

For more information on applying @TypeHint to a file upload parameter see the section on File Uploads above.

@DefaultValue

The @DefaultValue suffixed parameter may be provided to set a property to a default value should no value be provided in the actual parameters. Same as for normal paramaters, the @DefaultValue parameter may have multiple values to create multi-valued properties.

Example: Set the text property to a default value if the user does not provide one:

<form method="POST" action="/content/page/first" enctype="multipart/form-data">
    <input type="text" name="text" />
    <input type="hidden" name="text@DefaultValue" value="--- Default Value ---" />
    <input type="Submit" />
</form>

@ValueFrom

In some situations, an HTML form with parameters may be reused to update content. But one or more form parameters may not comply with the names expected to be used for properties. In this case a parameter suffixed with @ValueFrom may be set containing the name of the parameter providing the actual data to be used.

Example: To set the property text from a form element supplied_text, you might use the following form:

<form method="POST" action="/content/page/first" enctype="multipart/form-data">
    <input type="text" name="supplied_text" />
    <input type="hidden" name="./text@ValueFrom" value="supplied_text" />
    <input type="Submit" />
</form>

To prevent storing the additional paramaters in the repository you might want to use the prefixing mechanism as shown in the example above, where the @ValueFrom parameter is prefixed and thus the supplied_text parameter is not used for property setting.

The @ValueFrom suffixed parameter is assumed to be single-valued. If the parameter has multiple values it is ignored completely.

The @ValueFrom suffixed parameter is also special in that there must not be a correlated parameter without a suffix. Thus have parameters text and text@ValueFrom may have unexpected results.

@Delete

Sometimes it may be required to not set a property to a specific value but to just remove it while processing the content update request. One such situation is a property filled from one or more checkboxes in an HTML form. If none of the checkboxes are checked, no parameter is actually submitted for these checkboxes. Hence the SlingPostServlet will not touch this property and effectively leave it untouched, while the natural reaction would have been to remove the property.

Here comes the @Delete suffixed parameter. This simply causes the indicated property be removed if it exists. If the property does not exist, nothing more happens. The actual value of the @Delete suffixed parameter does not care as long as the parameter is submitted.

Example: To ensure the color property is actually removed if no color has been selected, you might use the following form:

<form method="POST" action="/content/page/first" enctype="multipart/form-data">
    <input type="checkbox" name="color" value="red" />
    <input type="checkbox" name="color" value="green" />
    <input type="checkbox" name="color" value="blue" />
    <input type="hidden" name="color@Delete" value="delete text" /><!-- actual value is ignored -->
    <input type="Submit" />
</form>

The @Delete suffixed parameter is also special in that there need not be a correlated parameter without a suffix. If both – a parameters text and text@Delete are set, the text property is first deleted and then filled with the new content.

The @Delete suffixed parameter in fact calls for a sub-operation, which is executed after the node addressed by the request URL is created (if needed) but before any other tasks of content creattion and modification are done. Any item – this may be a property or a node, actually – addressed by the @Delete suffixed parameter is just removed if it exists. If the item does not exist, nothing happens.

@MoveFrom

Now, that your bright and shiny content management application has great Flash-based file upload feature you will want to be able to use the pre-uploaded files for your content with the same request as when you upload other content. For example you might have a node storing some text and an illustration you uploaded as an image file.

To support this kind of functionality, the @MoveFrom suffixed parameter may be set to the repository path of the node to where you uploaded the image file.

Example: Your Flash-based file upload stored the file on the server at /tmp/upload/123. You now want to store this file along with a title and a text in a newly created node. The following form will be your friend:

<!-- trailing slash generates a name for the new node -->
<form method="POST" action="/content/page/" enctype="multipart/form-data">
    <input type="hidden" name="image@MoveFrom" value="/tmp/upload/123" />
    <input type="text" name="title" />
    <input type="text" name="text" />
    <input type="Submit" />
</form>

If there exists no repository item at the indicated path, nothing is done. If the item indicated by the @MoveFrom suffixed parameter already exists, it is replaced by the item addressed by the parameter value – unless of course there is no item at the named location.

The @MoveFrom suffixed parameter is assumed to be single-valued. If the parameter has multiple values it is ignored completely.

The @MoveFrom suffixed parameter is also special in that there must not be a correlated parameter without a suffix. Thus have parameters text and text@MoveFrom may have unexpected results.

The @MoveFrom suffixed parameter in fact calls for a sub-operation, which is executed after the @Delete sub operation but before any other tasks of content creattion and modification are done.

@CopyFrom

Similar to the @MoveFrom suffix exists a @CopyFrom suffix. The latter works exactly the same as the former except that the item addressed by the parameter value is not moved but just copied.

Example: Your Flash-based file upload stored the file on the server at /tmp/upload/123. You now want to store this file along with a title and a text in a newly created node. The following form may be your friend:

<!-- trailing slash generates a name for the new node -->
<form method="POST" action="/content/page/" enctype="multipart/form-data">
    <input type="hidden" name="image@CopyFrom" value="/tmp/upload/123" />
    <input type="text" name="title" />
    <input type="text" name="text" />
    <input type="Submit" />
</form>

If there exists no repository item at the indicated path, nothing is done. If the item indicated by the @CopyFrom suffixed parameter already exists, it is replaced by the item addressed by the parameter value – unless of course there is no item at the named location.

The @CopyFrom suffixed parameter is assumed to be single-valued. If the parameter has multiple values it is ignored completely.

The @CopyFrom suffixed parameter is also special in that there must not be a correlated parameter without a suffix. Thus have parameters text and text@CopyFrom may have unexpected results.

The @CopyFrom suffixed parameter in fact calls for a sub-operation, which is executed after the @MoveFrom sub operation but before any other tasks of content creattion and modification are done.

Algorithm for Node Name Creation

If request is posted with an URL ending in slash / or slash-star /*, the SlingPostServlet derives a name for the node to be created upon the request applying the following algorithm:

1. If a :name parameter is supplied, the (first) value of this parameter is used unmodified as the name for the new node. If the name is illegally formed with respect to JCR name requirements, an exception will be thrown when trying to create the node. The assumption with the :name parameter is, that the caller knows what he (or she) is supplying and should get the exact result if possible.
2. Otherwise if a :nameHint parameter is supplied, the (first) value of this parameter is used to generate the node name. A name filtering is applied to this hint to ensure a valid JCR node name.
3. Otherwise a series of request paramaters supplied to set content is inspected for a possible name. The list of the names of these parameter is configurable with the SlingPostServlet and defaults ot [ title, jcr:title, name, description, jcr:description, abstract ]. The first request parameter with a non-empty value is used and filtered to get the valid JCR name.
4. Otherwise an ever increasing auto generated number is used. Filtering is also applied to this numeric name.

The filtering algorithm to create a valid name of the hints from above steps (except the first) works as follows:

• Convert the proposed name to all lower case.
• Replace all characters not in the range [0..9a..z_] by a single underscore _.
• If the name starts with a digit prepend an underscore. Technically names with leading digits are valid, but they present major issues when using such names in JCR XPath expressions. The algorithm takes care to not create names with two or more consecutive underscore characters.
• Finally the name is cut to a configurable maximum length (default is 20 characters).

For example the :nameHint value A quick brown Fox ... is filtered to become a_quick_brown_fox_

After generating and filtering the name it is further guaranteed that the name is unique: If a node of the same name as just generated from the algorithm already exists below the same parent node a numeric index is appended to the new node name to make it unique.

Response Status

The modification operation has the following status responses:

Content Removal

To remove existing content just address the item to be removed and set the :operation parameter to delete. For example the following command line removes the /content/sample page:

$ curl -F":operation=delete" http://host/content/sample

Response Status

The delete operation has the following status responses:

Deleting Multiple Items

By using the :applyTo request parameter it is possible to remove multiple items in one single request. Deleting items in this way leaves you with less control, though. In addition, if a single item removal fails, no item at all is removed.

When specifying the item(s) to be removed with the :applyTo parameter, the request resource is left untouched (unless of course if listed in the :applyTo parameter) and only used to resolve any relative paths in the :applyTo parameter.

To for example remove the /content/page1 and /content/page2 nodes, you might use the following command line:

$ curl -F":operation=delete" -F":applyTo=/content/page1" -F":applyTo=/content/page2" http://host/content/sample

If any resource listed in the :applyTo parameter does not exist, it is silently ignored.

Response Status

The delete operation applied to multiple resources has the following status responses:

Copying Content

To copy existing content to a new location, the copy operation is specified. This operation copies the item addressed by the request URL to a new location indicated by the :dest parameter. The :dest parameter is the absolute or relative path to which the resource is copied. If the path is relative it is assumed to be below the same parent as the request resource. If it is terminated with a / character the request resource is copied to an item of the same name under the destination path.

To illustrate the :dest parameter handling, lets look at a few examples. All examples are based on addressing the /content/sample item:

If an item already exists at the location derived from the :dest parameter, the copy operation fails unless the :replace parameter is set to true (case is ignored when checking the parameter value).

Response Status

The copy operation has the following status responses:

Copying Multiple Items

By using the :applyTo request parameter it is possible to copy multiple items in one single request. Copying items in this way leaves you with less control, though. In addition, if a single item copy fails, no item at all is copied.

When specifying the item(s) to be copied with the :applyTo parameter, the request resource is left untouched (unless of course if listed in the :applyTo parameter) and only used to resolve any relative paths in the :applyTo parameter.

To for example copy the /content/page1 and /content/page2 nodes to /content/target, you might use the following command line:

$ curl -F":operation=copy" -F":applyTo=/content/page1" -F":applyTo=/content/page2" -F":dest=/content/target/" http://host/content/sample

Please note the trailing slash character (/) in the value of the :dest parameter. This is required for mult-item copy operations using the :applyTo parameter. The copied items are created below the node indicated by the :dest.

If any resource listed in the :applyTo parameter does not exist, it is silently ignored. Any item already existing at the copy destination whose name is the same as the name of an item to be copied is silently overwritten with the source item.

Response Status

The copy operation applied to multiple resources has the following status responses:

Moving Content

To move existing content to a new location, the move operation is specified. This operation moves the item addressed by the request URL to a new location indicated by the :dest parameter. The :dest parameter is the absolute or relative path to which the resource is moved. If the path is relative it is assumed to be below the same parent as the request resource. If it is terminated with a / character the request resource is moved to an item of the same name under the destination path.

To illustrate the :dest parameter handling, lets look at a few examples. All examples are based on addressing the /content/sample item:

If an item already exists at the location derived from the :dest parameter, the move operation fails unless the :replace parameter is set to true (case is ignored when checking the parameter value).

Response Status

The move operation has the following status responses:

Moving Multiple Items

By using the :applyTo request parameter it is possible to move multiple items in one single request. Moving items in this way leaves you with less control, though. In addition, if a single item move fails, no item at all is moved.

When specifying the item(s) to be moved with the :applyTo parameter, the request resource is left untouched (unless of course if listed in the :applyTo parameter) and only used to resolve any relative paths in the :applyTo parameter.

To for example move the /content/page1 and /content/page2 nodes to /content/target, you might use the following command line:

$ curl -F":operation=move" -F":applyTo=/content/page1" -F":applyTo=/content/page2" -F":dest=/content/target/" http://host/content/sample

Please note the trailing slash character (/) in the value of the :dest parameter. This is required for mult-item move operations using the :applyTo parameter. The moved items are created below the node indicated by the :dest.

If any resource listed in the :applyTo parameter does not exist, it is silently ignored. Any item already existing at the move destination whose name is the same as the name of an item to be moved is silently overwritten with the source item.

Response Status

The move operation applied to multiple resources has the following status responses:

Null Operation

Sometimes it is useful to explicitly request that nothing is to be done. The SlingPostServlet now provides such an operation under the name nop. Apart from doing nothing, the nop operations sets the response status to either the default 200/OK or to any status requested by the :nopstatus request parameter.

The :nopstatus request parameter must be an integral number in the range [ 100 .. 999 ]. If the parameter value cannot be parsed to an integer or the value is outside of this range, the default status 200/OK is still set.

Response Status

The null operation sets a default status or the status requested by the :nopstatus request parameter.

Special Parameters

Some parameters have special significance for the complete processing of the SlingPostServlet or are used by multiple operations. This section summarizes these parameters:

:order

Child nodes may be ordered if the primary node type of their common parent node is defined as having orderable child nodes. To employ such ordering, the content creation/modification, move and copy operations support the :order parameter which apply child node ordering amongst its sibblings of the target node.

The :order parameter may have the following values:

Note that simple content reordering can be requested without applying any other operations. This is easiest done by placing a request to the resource to be reordered and just setting the :order parameter. For example to order the /content/sample/page5 resource above its sibbling resource /content/sample/other a simple request

$ curl -F":order=before other" http://host/content/sample/page5

does the trick. To be redirected after the reodering, the :redirect parameter may optionally also be specified.

:redirect

Instructs the SlingPostServlet to redirect the client to the indicated location if the operation succeeds. That is the reponse status is set to 302/FOUND and the Location header is set to the value of the :redirect parameter.

:status

By default the SlingPostServlet sets response status according to the status of the operation executed. In some cases, it may be desirable to not have the real status codes (e.g. 404 or 505) but a normal 200/OK to trick the client browser into displaying the response content generated by the SlingPostServlet.

To not send the actual response status back to the client, the :status request parameter should be set to browser. If this parameter is not set, is empty, is set to standard or to any other value, the actual status code is sent back to the client.

Advanced Topic: Extending the SlingPostServlet

The supported operations of the SlingPostServlet may be extended by registering an OSGi service of type org.apache.sling.servlets.post.SlingPostOperation with the sling.post.operation service registration property set to the name of the operation. This name may then be used as the value of the :operation parameter to select the extended operation.

As a simple example, let us register an operation named ping. This operation actually does nothing actually. First let's create the operation. We are using the Apache Felix Maven SCR Plugin to create an Declarative Services descriptor for this operation, so apart from packaging this class and the descriptor in a bundle, there is nothing more to be done.

/**
 * @scr.component metatype="no" immediate="true"
 * @scr.service
 * @scr.property name="sling.post.operation" value="ping"
 */
public class PingOperation implements SlingPostOperation {

public void run(SlingHttpServletRequest request, HtmlResponse response, SlingPostProcessor[] processors) {
  }
}

That's all. Package this in a bundle and deploy to a running Sling instance. Then you POST to this using ping as the operation name:

$ curl -F":operation=ping" http://host/content

For your convenience an abstract implementation of this interface exists as the org.apache.sling.servlets.post.AbstractSlingPostOperation abstract class, from which you may extend and implement the doRun(SlingHttpServletRequest, HtmlResponse, java.util.List<Modification>) method.