On Tue, Jul 12, 2011 at 5:56 PM, Raymond Feng <enjoyj...@gmail.com> wrote: > Good summary :-). > I like the context driven approach. In addition to what you listed, I > propose a few more: > * TUSCANY_CONTEXT: The context for the whole Tuscany runtime in the JVM (can > be seen as the replacement for NodeFactory). It provides accesses to the > ExtensionPointRegistry (in turn Extension Points and Extensions). > * NODE_CONTEXT: The context for a given Tuscany node (can be seen as the > replacement for CompositeContext) > On the application side, we could have things like: > * DOMAIN_CONTEXT (to access the domain registry) > * COMPONENT_CONTEXT (as well as BINDING_CONTEXT, IMPLEMENTATION_CONTEXT?) > * REQUEST_CONTEXT (to access the security context, thread, MESSAGE) > Also there should be a hierarchy of the context objects, for example, the > NODE_CONTEXT should have a pointer to the TUSCANY_CONTEXT. > Thanks, > Raymond > ________________________________________________________________ > Raymond Feng > rf...@apache.org > Apache Tuscany PMC member and committer: tuscany.apache.org > Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com > Personal Web Site: www.enjoyjava.com > ________________________________________________________________
Yes, it's a shame we don't pass round a TuscanyContext rather than the ExtensionPointRegistry when we configure extension factories. We could look to do that but that's possibly a little orthogonal to how we pass context along the invocation chain. Although having said that if the providers did have access to a more complete context picture they could of course prime a message with a reference to that context at little extra cost. I was hinting at needing to add a context extension point so maybe that is a simple way through this. I.e. define a context base class and have context factories and structures registered against it, e.g. Static context: o.a.t.s.context.ContextFactory -> o.a.t.s.context.TuscanyContextFactory;context=o.a.t.s.context.TuscanyContext // for anything that doesn't change at runtime we could add the context object to the registry also Dynamic context: o.a.t.s.context.ContextFactory -> o.a.t.s.context.RequestContextFactory;context=o.a.t.s.context.RequestContext o.a.t.s.context.ContextFactory -> o.a.t.s.context.MyPolicyContextFactory;context=o.a.t.s.context.MyPolicyContext For the @Context visitor we could then look at the type of the injected context and compare against registered context types before creating and injector (currently it only allows Compoent/RequestContext) For the Message we could then adjust the interface to be something like Map<String, Object> getHeaders(); // retains this to hold message protocol headers. Any existing code that uses it remains the same <T> T getContext(Class<T> contextClass); // replaces getBindingContext() Hence when you need a particular context you do something like: MyPolicyContext context = message.getContext(MyPolicyContext.class); That should allows us include context extensibly in support of passing policy driven context to component implementations. If subsequently we want to connect context into a hierarchy that's great. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
