On Fri, Jul 15, 2011 at 12:42 PM, Mike Edwards
<[email protected]> 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
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
