[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]