[
https://issues.apache.org/jira/browse/AURORA-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Farner reopened AURORA-332:
--------------------------------
Reopening to mark resolution=resolved.
> Extend the client plugin architecture to support pre-dispatch and cleanup
> operations
> ------------------------------------------------------------------------------------
>
> Key: AURORA-332
> URL: https://issues.apache.org/jira/browse/AURORA-332
> Project: Aurora
> Issue Type: Story
> Components: Client
> Reporter: Mark Chu-Carroll
> Assignee: Mark Chu-Carroll
> Fix For: 0.5.0
>
>
> (From the proposal shared with the mailing list.)
> The way that configuration plugins work right now in the noun/verb framework
> is super simple. A configuration plugin is an object with an "execute"
> method. During command dispatch, after the command parser processes the
> arguments and a command-appropriate context is created, the framework
> iterates over the plugins, and calls the execute method of each one, with the
> context object and parsed command line parameters.
> There are two problems that I've encountered working with these in practice:
> Some plugins really want to be run before the command-line arguments are
> processed, and some want to be run after. For example, for a distributed
> logging system, we'd like to be able to have the logging system optionally
> enabled before the command is dispatched, so that the dispatch process can
> use logging. But others, for managing things like proxies, need to be called
> after arguments are processed, because they rely on arguments.
> Some plugins need cleanups. For example, in logging again, for best
> performance, we'd like to use multiprocessing to do asynchronous
> communication with a logserver. But to do that, we need to do a join after
> the command completes execution. In the current framework, there's no way to
> do that.
> What I'm thinking about is going more aspect-oriented in the plugins. There
> will be three points during the execution of a command where plugins can get
> injected:
> before any argument processing is performed. The only thing that the plugin
> would be allowed to look at would be the raw, unprocessed command-line
> parameters. It would return a (potentially) modified copy of the parameters,
> which would be passed to other plugins, and finally to the actual noun/verb
> for the command being executed.
> after arguments have been processed, but before the noun/verb is executed.
> This is exactly what the current plugin "execute" method does.
> after the command has completed executing, but before the client exits.
> The code signatures would be:
> def beforeDispatch(self, args):
> """code to execute before dispatching to a noun/verb command.
> args: a list of the command-line parameters used
> to invoke aurora.
> Returns: a possibly modified list of command-line arguments. If this
> throws an exception, then the execution
> of the command will be aborted.
> """
>
> def beforeCommand(self, context):
> """Code to execute after command-line arguments have been
> processed, but before executing the command. If the
> code throws a CommandException, then the execution of
> the command will be aborted.
> context: the context object that will be used to invoke
> the command.
>
> def cleanupAfterCommand(self, context, returnval):
> """Code to run after the execution of a noun/verb command has
> completed, before the command-line application exits.
> context: the context object that was used to execute the command.
> returnval: the exit code returned by executing the command.
> """
> The order of execution of plugins would remain undefined.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
