Initial proposal for MIFOSX-1355

Guys,

This implements the MIFOSX-1355 proposal as per our email/skype conversation. It introduces a CommandHook interface/class for each of the operations. The goal is for the integrator to override the classes in their implementation and then inject through spring configuration.

Let us know what you think and we will make some more changes.
Sorry for the late reply :-( I think that your proposal to register an
instance makes a lot of sense, I am not sure why we went with classes.

On Wed, Nov 5, 2014 at 9:41 AM, Michael Vorburger <notifications@github.com>
wrote:

> In
> mifosng-provider/src/main/java/org/mifosplatform/infrastructure/hooks/CommandHookRegistry.java:
>
> > +
> > +import java.util.List;
> > +
> > +@Service
> > +public class CommandHookRegistry {
> > +
> > +    private final CommandHookProvider commandHookProvider;
> > +
> > +    @Autowired
> > +    public CommandHookRegistry(final CommandHookProvider commandHookProvider) {
> > +        this.commandHookProvider = commandHookProvider;
> > +    }
> > +
> > +    private final static ListMultimap<CommandHookType,ResolvedHook> hooks = Multimaps.synchronizedListMultimap(ArrayListMultimap.<CommandHookType, ResolvedHook>create());
> > +
> > +    public void register(final CommandHookType hookType, final Class<? extends CommandHook> hookClass ) throws IllegalAccessException, InstantiationException {
>
> @winding-lines <https://github.com/winding-lines> I'm sitting together
> with @avikganguly01 <https://github.com/avikganguly01> (in Bangalore)
> looking at your code (and just rebased it to latest develop, see
> https://github.com/avikganguly01/mifosx/tree/MifosX-1355-CodeHooks), and
> we are wondering why you've chosen to register a CommandHook class instead
> of an instance of a CommandHook?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/openMF/mifosx/pull/1030/files#r19890585>.
>