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.
