On 13/07/2011 16:37, Simon Laws wrote:
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
Folks,
I'd like to break this down into simple steps which address specific issues and functions, rather
than considering some grand scheme. Small steps that each provide value.
The first thing I'd like to consider is the way in which Context is passed to the application code -
and in particular where binding implementation / interceptor extensions can use the Context
mechanism to pass (arbitrary) data to the application code - and vice-versa.
Currently, there are 2 pieces of Context available to an application:
- ComponentContext
- RequestContext
These can be retrieved either via injection controlled by @ComponentContext and @RequestContext, or
via the API with explicit get..() calls.
Of these two, perhaps the most important is the RequestContext, although the principles can apply
equally to ComponentContext.
My thinking is that when requested to supply RequestContext to the application, that Tuscany
supplies not the formal OASIS-defined RequestContext, but a subclass - "TuscanyRequestContext".
I think that the simplest approach to TuscanyRequestContext that is still general is to add a single
map-style method to get additional context information, based on the use of a key that is a string:
Object getExtendedContext( String contextName );
...for code within Tuscany there would be an equivalent setter method:
void setExtendedContext( String contextName, Object );
If we prefer something more typesafe, we can use Generic versions of these
methods:
<T> getExtendedContext<T>( String contextName ); (etc)
What I prefer about this approach is that it is still possible to write application code that is
portable through the use of instanceof - avoiding the need for the application to have things like
Tuscany annotations in the code.
Yours, Mike.
PS Next I think we should look at context information being passed from the application code to the
code involved in a reference invocation...
