Sebastien,
When I wrote this I was thinking of the recursive composition case. Let's
say I have a composite with a component A that is initially implemented by a
POJO. I write some code that uses ComponentContext to get a
ServiceReference to one of its services or references. Later I decide to
replace component A with a composite implementation that has a matching
component type. Shouldn't the code I wrote that uses ComponentContext still
work with the services and references exposed by that composite
implementation?
If we ignore the recursive case and just think about independent composites,
then I'm also unsure about the use cases for finding an arbitrary component
context in the SCA domain. I had been assuming it would be possible for a
client (perhaps non-SCA) to get a ServiceReference to a service exposed by
an arbitrary *top-level* component to invoke it. I'm not so sure why anyone
would want to ServiceReference to a reference exposed by an arbitrary
top-level component.
I don't understand your comments about the implementation language of the
target. How does the ComponentContext interface require the target to be a
Java component?
On 4/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Greg Dritschler wrote:
> This is a bit of a nit. It appears that the
> SCARuntime.getComponentContextdoes not work if the given component is
> implemented by another composite.
> For example SCARuntime.getComponentContext("CalculatorServiceComponent")
> returns null when CalculatorServiceComponent has a composite
> implementation.
> <component name="CalculatorServiceComponent">
> <implementation.composite name="foo:InnerCalculatorComposite"/>
> </component>
> Should CompositeComponentImpl implement ComponentContextProvider?
>
Greg,
Thanks for reporting this. This is the current design. I checked the
spec documents, and I think we're going to have to ask the SCA Java Spec
workgroup to clarify if a ComponentContext is meant to represent any
kind of non-composite component or only Java components, and if a
ComponentContext can represent a composite or not...
On one hand supporting ComponentContexts for composite components seems
required to support what the SCA Java API and Annotation spec says on
line 351:
Non-SCA client code can use the ComponentContext API to perform
operations against a component in an SCA domain.
On the other hand it seems odd - to me at least :) to allow Java code to
sneak in the context of any component to get proxies for its references,
as described on line 798:
getService(Class<B> businessInterface, String referenceName) – Returns a
proxy for the reference defined by the current component.
And I find this even more troubling given that references on composite
components represent (through promotion) references declared by inner
non-composite components. So, as an SCA application developer, if I had
an OuterCompositeComponent/sampleReference reference promoting an
InnerJavaComponent/sampleReference, I'm not sure at all which
ComponentContext I should use to getService(BusinessInterface.class
"sampleReference")... Should I use the ComponentContext for the
OuterCompositeComponent or the InnerJavaComponent?
Another question is: What will a Java based ComponentContext mean if the
component is a BPEL or C++ component?
I'll follow up with the SCA Java spec workgroup.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
