[dna-issues] [JBoss JIRA] Updated: (DNA-181) Consolidate security, messages, and progress within the ExecutionContext and make framework consistent in its use and passing of this context

Consolidate security, messages, and progress within the ExecutionContext and make framework consistent in its use and passing of this context --------------------------------------------------------------------------------------------------------------------------------------------- Key: DNA-181 URL: https://jira.jboss.org/jira/browse/DNA-181 Project: DNA Issue Type: Feature Request Components: API, SPI Affects Versions: 0.1 Reporter: Johnny Verhaeg Fix For: 0.3 We are already passing around an ExecutionContext to various parts of the DNA framework, and in some places a progress monitor that in turn contains problems encountered (as of DNA-75). We're now looking into security information that also needs to be passed around during login and execution, and it's now evident that a better way to handle all of these information types would be to consolidate all of it within the execution context and make it the common "token" that is consistently passed between all framework components, including the SPI. Messages, progress, security, etc., should always be dealt with in relation to a particular context, and contexts may be hierarchical in nature. For example, the messages, problems, and progress for a particular operation should be recorded in a manner that ties them to that operation's execution within whatever context it occurred, which will have been initiated as part of a broader context, that being either a higher-level or composite operation or, at the very least, within the context of the client's session. Recording information in this manner should make it easier to audit, debug, providing complex logging facilities, etc. "Problems" should be treated more generically as simply "Messages", allowing the framework much for flexibility to handle context-specific information, such as messages specific to an operation or executed command. The entire logging framework can then work off of these messages rather than leaving it to SPI implementors to determine when something should be logged, added as a problem/message, or both. The framework contains only a few other types of information, none of which should be dangerous to pass around, and any of which can be further protected if necessary via context wrappers that may, for instance, return immutable versions of that information.