[
https://jira.jboss.org/jira/browse/DNA-270?page=com.atlassian.jira.plugin...
]
Randall Hauch commented on DNA-270:
-----------------------------------
Incidentally, this change also eliminates the practical difference between components that
take an ExecutionContextFactory, and those that take an ExecutionContext, since an
ExecutionContext instance will be created and passed to both kinds of components. (The
semantic difference is still there, in that when a factory is provided, the recipient
needs to create a context; whereas if a context is provided, it could be used as is or
could be used to create a subcontext.)
Simplify the ExecutionContext framework
---------------------------------------
Key: DNA-270
URL:
https://jira.jboss.org/jira/browse/DNA-270
Project: DNA
Issue Type: Task
Components: API, Connectors, Documentation, Examples, Graph, Sequencers
Affects Versions: 0.3
Reporter: Randall Hauch
Assignee: Randall Hauch
Fix For: 0.4
Attachments: dna-270-executioncontext.patch
The ExecutionContext interface is used throughout the system. It's defined in
'dna-graph', and used to represent the context or environment for executing
various activities. There is also ExecutionContextFactory, which is an interface for
creating other contexts with different JAAS security contexts (login context or access
control contexts). There are also the Basic* implementations of these interfaces, as well
as several subclasses (with various implementations).
The idea of using an interface for this was to simplify the design of the components that
uses/took an ExecutionContext, to prevent propagating dependencies, and to allow
customization. However, since ExecutionContext is largely just an aggregation of
references, there's little need to customize the behavior, and this doesn't really
add any other dependencies to the classpath (all implementations of the aggregated
components are already in 'dna-graph') and it doesn't expose any
implementations through the method signatures. Using interfaces also complicates the
usage, since clients have to know about the concrete implementations. This is even more
true when they're setting up the DNA services and repositories in
'dna-repository' and 'dna-jcr'.
So, consider changing this interface to a concrete class, with methods that make it easy
to create instances as well as instances with custom components (e.g., a new context that
is the same as 'this' but with a supplied NamespaceRegistry implementation).
This will change the public API, but this should be acceptable given that we're not
yet at 1.0 (and this really improves both the client code, and doesn't really change
extension implementations).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira