OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-j] [Issue 225]: Ambiguity about the implicit reference interfacein the introspected component type of a Spring app context


There is a related issue for the case when there is an explicit 
sca:reference element in the app context. The spec says:

"When an application context contains one or more SCA reference 
elements, each of these elements acts as if it were a Spring <bean/> 
element, offering a target which can satisfy a reference from a <bean/> 
element within the application context. "

Since sca:reference acts as if it were a Spring bean, Spring rules 
should dictate the rules for the interface types. So I don't think we 
need to say anything more to cover this particular case, but thought I 
would mention it here.

Thanks!

-Anish
--

On 12/19/2010 10:30 PM, Anish Karmarkar wrote:
> This is now issue 225
> http://osoa.org/jira/browse/JAVA-225
>
> -Anish
> --
>
> On 12/19/2010 10:18 PM, Anish Karmarkar wrote:
>> Title: Ambiguity about the implicit reference interface in the
>> introspected component type of a Spring app context
>>
>> Spec: Spring C&I WD05
>>
>> Description:
>> Section 3 of the spec says:
>> "A <reference/> element exists for each unique bean reference in the
>> application context to a bean which is not found in the application
>> context and where the bean reference refers to a Java interface class"
>>
>> Further down for the introspected reference in the component type it
>> says:
>> " interface.java child element is present, with the interface attribute
>> set to the fully qualified name of the interface class identified by the
>> bean reference"
>>
>> But the spec does not address the case where,
>> 1) two or more beans refer to the same bean reference that is not found
>> in the application context (i.e., 2 or more beans refer to the same
>> introspected SCA reference), and
>> 2) fully qualified name of the interface class identified by the bean
>> references are different.
>>
>> For example:
>>
>> <beans>
>>
>> ...
>>
>> <bean id ="bean1" class ="org.example.Class1">
>> <property name="ref" ref="SCAReference"/>
>> </bean>
>>
>> <bean id ="bean2" class ="org.example.Class2">
>> <property name="someOtherRef" ref="SCAReference"/>
>> </bean>
>>
>> <beans>
>>
>> Both bean1 and bean2 refer to the same SCAReference. If the interface
>> type for ref in Class1 is the same as that of someOtherRef in Class2,
>> then there is no ambiguity about the interface type for the introspected
>> SCA reference, but if they are not, then it is not clear what should
>> happen.
>>
>> Proposal:
>> Here is an outline for a proposal to resolve the case above --
>> 1) if the interface type for properties that refer to the same bean are
>> not the same AND are not subinterfaces then that is an error.
>> 2) else, the narrowest subinterface is used for the value of
>> interface.java/@interface
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]