On 15/07/2011 12:08, Simon Laws wrote:
Commenting on the last two posts. Generally I prefer the strong typing
of context and the ability to have that type injected into an
implementation. I do though accept that there is no API alternative to
injection for anything other than RequestContext or derivatives. In
the derivative case the app writer would be still be expected to cast
to TuscanyRequestContext which isn't so elegant but will work.
Well, I suppose we could envisage an annotation like @TuscanyRequestContext that would signal
injection of a TuscanyRequestContext which would then not need any cast - but of course my concern
is that any such code would only work with Tuscany and would not work with any other SCA runtime,
which is the flip side of the concern.
In terms of "strong typing of context" I would be concerned about a scheme in which each potential
atom of context was separately injected - this would get out of hand very quickly I think. I
suppose one scheme is to treat context like a set of Properties to be injected, where the property
names are simple strings (of the type I'm advocating for getContext()), with the implication that
each field/setter would be annotated like @TuscanyRequestContext( "foo" ) - and with the assumption
that the type of the field/method had better match the implied type of that context property (which
must be defined by the runtime, not by the application).
I agree that the best we get for the set of names for context atoms is simply documentation - what
would be good is a catalog that aims to promote the maximum amount of commonality, especially
between Bindings, where I hope that header fields, for example, could use the same names and types
for a wide range of binding types. This is really a matter of trying to get developers of binding
implementations to use common context fields as far as possible.
Of course, once you head down the headers road, then there could be a desire to reflect any and all
headers into the application - something I don't think is a great idea - if it matters that much to
the application it should be part of the service signature in 99.99% of cases.
Yours, Mike.
