Customizing the default implementation

The signature of the getNextTask function on the curam.core.hook.task.impl.InboxActions interface is as follows:

package curam.core.hook.task.impl;  

@ImplementedBy(InboxActionsImpl.class)
public interface InboxActions {

  public long getNextTask(String userName);
   
   .
   .
   .
   .
}

The default implementation for the function is specified in the curam.core.hook.task.impl.InboxActionsImpl class

package curam.core.hook.task.impl;  

public class InboxActionsImpl implements InboxActions {

  public long getNextTask(String userName) { 
    // Default implementation code is here....
  }

  . 
  .
  .
  .
}

To customize getNextTask, the method must be implemented in the new custom class created earlier which extends the default curam.core.hook.task.impl.InboxActionsImpl implementation class.

package custom.hook.task.impl;  

public class CustomInboxActionsImpl extends InboxActionsImpl {

  public long getNextTask(final String userName) { 
    // Custom implementation code goes here
  }
  
}

To ensure that the application executes the new custom class rather than the default implementation a new class custom.hook.task.impl.Module.java which extends com.google.inject.AbstractModule must be written with the configure method implemented as the following example shows:

package custom.hook.task.impl; 
 
public class Module extends com.google.inject.AbstractModule {
  protected void configure() {
    bind(
      curam.core.hook.task.impl.InboxActions.class).to(
        custom.hook.task.impl.CustomInboxActionsImpl.class);
    }
}

Finally the custom.hook.task.impl.Module class name must be inserted into the ModuleClassName column of the ModuleClassName database table. This can be inserted by adding an extra row to the ModuleClassName.DMX file or directly into the database table if required.

Using this approach, when the application is redeployed, the system will now invoke the customized version of the getNextTask function rather than the default implementation.