On Fri, Aug 1, 2008 at 2:38 PM, Mike Edwards < [EMAIL PROTECTED]> wrote:
> Simon Laws wrote: > >> >> >> On Wed, Jul 30, 2008 at 8:30 PM, Scott Kurz <[EMAIL PROTECTED] <mailto: >> [EMAIL PROTECTED]>> wrote: >> >> Simon, >> >> About the 2nd case... >> >> Let me just throw out a case where the ComponentContext is useful >> without needing a single field to hold the reference: >> >> Say component A has a dependency on component B over a >> conversational intf, and say A wants to manage the sessions. So >> instead of a single MyReference it has a map of <SomeSessionID, >> MyReference>. In the SCDL, though, we only want to model the >> single reference, not the map of References. >> >> Now... I know this brings up the question of why are you having your >> business logic manage sessions.. which is a good counterpoint, but I >> did want to mention an example so it didn't look totally useless. >> >> Scott >> >> <snip> > >> Hi Scott >> >> Interesting scenario. My mental model is that I expect that a component >> type will define, through a side file or through (annotated or unannotated) >> fields, all of its references and the types of those references. >> >> You scenario would still operate if the user had included the reference >> description in a side file or had put >> >> @Reference >> MyInterface MyReference; >> >> in their code. It would just look a little odd. >> >> I don't believe that including a <reference> on a component in a composite >> file is equivalent to defining a reference on a component type. I do note >> though that the <interface> element is still apparently optional in the >> component type descrition in section 1.4.1 of the assembly spec. Another >> question to raise. >> >> For example, if I have a composite implementation for my component and >> then define a reference at the component level but not the composite level >> there is no link between the reference at the component level and a >> component reference, in the underlying composite, that it is intended to >> promote. It just so happens that when there is Java implementation there is >> an API we can use to look up references. I think though that they should >> still be defined on the component type. >> >> Another scenario that comes to mind for using >> ComponentContext.getService() is if you have a component that has many >> independent references with the same interface and you want to be able to >> choose between them dynamically by name. I still feel the references should >> be defined in the component type. If they were an arbitrarty number I would >> be more likely to use a single reference with a multiplicity >1. >> >> Does this help? >> >> Simon >> >> Folks, > > There is an important point here, which the SCA Java specifications don't > make clear. > I'll raise an issue in the OASIS Java TC to address this - but I'll discuss > it here first. > > Let me latch onto Simon's comment above: > > "I don't believe that including a <reference> on a component in a composite > file is equivalent to defining a reference on a component type" > > No - it's not meant to be. The component metadata is configuration of the > implementation - but the configurable points are defined by the > implementation, not by the component. > > The ideal position is that the Java implementation explicitly says what all > its services, references and properties are, using annotations. If it is > written as an SCA component implementation, this should be no big deal. The > question arises if the class were originally written for some other purpose > and the desire is to use it unchanged - hence the material in the Java POJO > implementation spec about calculating the component type of an unannotated > Java class (it's this material that is deficient and needs fixing btw). > > Now, take some of the scenarios that have been described. They all seem to > revolve around a reference which should not be injected but which will be > obtained programmatically via an API. This is allowed for in the SCA Java > spec - you need something like: > > @Reference(required=false) > MyInterfaceType myReference; > > Note that the field is still required - it defines the interface of the > reference and in this case it also names the reference. But the > "required=false" parameter in the @Reference says "don't inject this > reference" - so the runtime knows everything about the reference, but > injection will not occur because we have asked to suppress it (it ain't the > default because in the simple cases, injection is what you want...). > > The Java code is then free to go and ask for an actual reference proxy > using the componentContext - and to do this as often as it likes (this would > be a way to have multiple conversations with the same conversational > service...). > > The other valid way to do things would be to use a componentType side file > (not my cup of tea, for sure) and to lay out the references in there. I > dislike this so much I've never even asked whether it works in Tuscany for a > Java POJO. I know it works for a BPEL process since I wrote the code to get > rid of the need to do it ;-) > > I hope this frames the discussion a bit - and now I'll go raise my issue > against the SCA Java specs to clarify the handling of component type for > POJOs. > > > Yours, Mike. > Hi Mike I've just stumbled across some more words in the spec that are pertinent to this conversation. Java Annotations and API Section 1.7.1 describes the getService method as returning a proxy for the "reference defined by the current component". This could be clarified to make it clear that this is the reference from the component type that is important not the reference that appears on a component in SCDL. Java Component Implementation Section 1.2.2.2 describes dynamic references. and could be clarrified to explain that the references that are the subject of dynamic access must first be described as part of the the component type. Simon
