olingo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Santosh kumar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OLINGO-1034) Provide Call backs for CRUD operations
Date Sun, 13 Nov 2016 13:35:59 GMT

    [ https://issues.apache.org/jira/browse/OLINGO-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15661494#comment-15661494

Santosh kumar commented on OLINGO-1034:

Hi [~mirbo],

Sorry for delay in response.
PFA Git Diff File [file:///C:/Users/I324363/git/olingo-odata-callback/olingo-odata2/olingo-odata2.diff]
 for the PoC I did on this topic.
The patch includes changes only for OData Read call back. Few points to note:
#  Instead of having a separate call back for CRUD operations (for before execution only),The
 {{handle}} method of {{ODataEntityBeforeReadCallback}} class can be used instead. This is
because it accepts Parameter of Type {{org.apache.olingo.odata2.core.uri.UriInfoImpl}} which
is top level parameter before corresponding UriInfo is prepared based on the Operation type.

# We still need to figure out a way to pass EntityManager to client code in the callback method.
This is required if the client prefers to make any backend call. For example, while persisting
SalesOrder, the call back client code may want to update SalesOrderItem table based on SalesOrder
# Callback code should be allowed to throw any OData exceptions which again should be handled
gracefully by the Olingo code.
# Additionally we may have to introduce validations in Olingo code post call back execution
to prevent any data malformation as part of callback execution.

Also, please find below the client side code for callback execution.


public class CustomODataJPAServiceFactory extends ODataJPAServiceFactory {
	public ODataJPAContext initializeODataJPAContext() throws ODataJPARuntimeException {
  // code to intialize OdataJPAContext.

	public <T extends ODataCallback> T getCallback(final Class<T> callbackInterface)

		T callback = null;
		if (callbackInterface.isAssignableFrom(ReadCallback.class)) {
			callback = (T) new ReadCallback();


		return callback;

public static class ReadCallback implements BeforeReadEntityCallback, ODataEntityBeforeReadCallback,
AfterReadEntityCallback, ODataEntityAfterReadCallback

		public void handle(String entitySetName, ODataContext odataContext, List<Object> lstObjects,
				EntityManager entityManager) {

		public boolean isAfterReadCallbackEnabled() {
			return false;

		public boolean isBeforeReadCallbackEnabled() {
			return true;

		 * This callback method is used to customize OData Read operation.
		 * Below method customizes OData GET request for SalesOrders by
                 *  1. appending $filter=LastChangedUserName eq 'SPIELERB'.
                 *  2. adds $top=2 to the URL.
		public void handle(UriInfoImpl uriInfo, ODataRequest request, EntityManager entityManager)
			if(request.getMethod() == ODataHttpMethod.GET){
			String entitySetName = null;
			try {
				if (uriInfo.getTargetEntitySet() != null)
					entitySetName = uriInfo.getTargetEntitySet().getName();
					String filter ="LastChangedUserName eq 'SPIELERB'";
					EdmType targetType = uriInfo.getTargetType();
					// Set/Update the filter expression to UriInfo
					uriInfo.setFilter(new FilterParserImpl((EdmEntityType) targetType).parseFilterString(filter,
					// Set/Update $top in UriInfo
			} catch (ODataException e) {
				// Log Exception & throw it back to Olingo ???

> Provide Call backs for CRUD operations
> --------------------------------------
>                 Key: OLINGO-1034
>                 URL: https://issues.apache.org/jira/browse/OLINGO-1034
>             Project: Olingo
>          Issue Type: New Feature
>          Components: odata2-core, odata2-jpa
>    Affects Versions: V2 2.0.7
>            Reporter: Santosh kumar
>              Labels: features
> OData V2.0.7 doesn't have exit points for CRUD operations on Entities. Instead of exit
points Olingo supports extending its API class {{ODataJPAProcessorDefault}} for any custom
CRUD operation. The drawback of this approach is that the developer has to duplicate all the
operations even if only {{readEntity}} has to be customized. Also any modification to the
request parameters of these operations will require re-writing the Olingo code again. 
> The proposal is to introduce a call back mechanism(similar to existing debug call back)
which allows the developer to introduce custom code for CRUD operations (ex: {{readEntity}}).
This approach also prevents Olingo code duplication in client code

This message was sent by Atlassian JIRA

View raw message