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.
With the subclass/cast approach, it's possible to write code that will run
on non-Tuscany runtimes, though not taking advantage of the Tuscany-specific
functionality in that case. Something like the following:
public class MyComponentImpl ....
@Context
RequestContext myRequestContext;
....
try {
Class trc =
MyComponentImpl.class.getClassLoader().loadClass("org.apache.tuscany.sca.TuscanyRequestContext");
if (trc.isAssignableFrom(myRequestContext.getClass()) {
// Tuscany-specific code, using reflection to access the
TuscanyRequestContext object
}
} catch(ClassNotFoundException e) {
}
This may or may not be useful, but I thought it's worth mentioning the
possibility :-)
Simon
@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
