I prefer to have strongly-typed context extensions. JAX-RS has the similar mechanism to allow custom context to be injected via @Context. The context can be resolved via:
http://jsr311.java.net/nonav/javadoc/javax/ws/rs/ext/ContextResolver.html 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 ________________________________________________________________ On Jul 15, 2011, at 5:38 AM, Simon Laws wrote: > On Fri, Jul 15, 2011 at 12:42 PM, Mike Edwards > <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 > Co-author of a book about Tuscany and SCA: tuscanyinaction.com
