[
https://jira.jboss.org/jira/browse/DNA-270?page=com.atlassian.jira.plugin...
]
Randall Hauch resolved DNA-270.
-------------------------------
Resolution: Done
Changed ExecutionContext from an interface to a concrete class, and made it implement
ExecutionContextFactory. This allowed removing the BasicExecutionContext and
BasicExecutionContextFactory implementations. Also added methods to ExecutionContext to
create "subcontext" (or context that inherit all of the same components except
for one), allowing removal of the ExecutionContexts class. These changes made it much
easier to use (no need to know about an implementation, anybody can create a context or
create a modified form of another context, less of a distinction between ExecutionContext
and ExecutionContextFactory, etc.), yet provides a lot of flexibility for defining
different combinations of components (including custom components) without requiring
subclassing (though subclassing is not precluded).
There were two primary subinterfaces of ExecutionContext (SequencerContext and
JcrExecutionContext); both of these were converted from classes to interfaces, eliminating
their implementation classes. Since both provide special kinds of contexts that only
added components to the "context" (rather than changing the behavior of the
existing components).
Also changed the documentation and examples to reflect these improvements.
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.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