On Fri, Jul 15, 2011 at 12:42 PM, Mike Edwards
<mike.edwards.inglen...@gmail.com
<mailto:mike.edwards.inglen...@gmail.com>> wrote:
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.
I was thinking more of allowing the following as a Tuscany specific
extension. Of course you need to be in Tuscany to use
TuscanyRequestContex but that's true of a cast also.
@Context
TuscanyRequestContext myRequestContext.
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'm slightly uneasy about that as it requires the Tuscany specific
annotations. I have considered the following but maybe that's just as
complex. WDYT?
@Context
RequestContext requestContext;
@Context
TuscanyRequestContext requestContext;
@Context
MyContextUnrelatedToRequestContext myContextReference1;
public void someServiceOperation(){
ContextValue value1 =
myContextReference1.getSomeValueFromTheContext();
ContextValue value2 =
requestContext.getExtendedContext(MyContextUnrelatedToRequestContext.class.getName()).getSomeValueFromTheContext();
// I would expect value1 and value2 to be the same object.
}
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.
+1
Yours, Mike.
Simon
--
Apache Tuscany committer: tuscany.apache.org <http://tuscany.apache.org>
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
<http://tuscanyinaction.com>
