sca-j message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-j] [ISSUE 149] SCA Spring C & I specification need to specify thelimitations of implicit references - Discussion and Proposal
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-j@lists.oasis-open.org
- Date: Mon, 17 Aug 2009 10:14:41 +0100
Dave,
Sorry if there is confusion here.
It is important to distinguish between
the <property/> elements in the Spring Application Context and the
<property/> and <reference/> elements
that turn up in the componentType derived
from the Application Context.
In the example quoted below from Ram's
note, the computation of componentType ONLY relates to the <ref bean="myDataSource"/>
- this is a bean reference, as described
in the SCA Spring spec text:
"A <property/> element exists
for each unique bean reference in the application context..."
(line 436)
There is NOT an SCA property called
"someList" here - that list is a Spring thing, not an SCA thing.
What SCA has here is simply a reference
to a single bean (which is either a reference or a property, depending
on its type).
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
| David Booz <booz@us.ibm.com>
|
To:
| sca-j@lists.oasis-open.org
|
Date:
| 14/08/2009 19:24
|
Subject:
| Re: [sca-j] [ISSUE 149] SCA Spring C
& I specification need to specify the limitations of implicit references
- Discussion and Proposal |
I should probably stay out of this discussion since I
know so little about Spring FW, but I have to ask a question. I also realize
that this question is related to a previous issue,but JAVA-149 builds on
the previous issue so I need to understand it. Let's use Ram's first example:
<property name="someList">
<list>
<value>a list element followed by a reference</value>
<ref bean="myDataSource" />
</list>
</property>
What does the componentType look like? I'm confused by lines 436-438 (wd04).
Assuming myDataSource wasn't in the context, the current wording leads
me to believe that I'd get an sca property named myDataSource, which isn't
what I was expecting. Shouldn't there be an sca property name someList?
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
Mike
Edwards ---08/14/2009 09:59:28 AM---Folks, This email discusses Issue 149
and makes a proposal for resolution. It is
From:
|
Mike Edwards <mike_edwards@uk.ibm.com>
|
To:
|
"OASIS Java" <sca-j@lists.oasis-open.org>
|
Date:
|
08/14/2009 09:59 AM
|
Subject:
|
[sca-j] [ISSUE 149] SCA Spring C & I specification need to specify
the limitations of implicit references - Discussion and Proposal |
Folks,
This email discusses Issue 149 and makes a proposal for resolution. It
is based on WD04 of the Spring C&I Specification.
In the issue, Ram makes the point that there are potential ways to configure
a Spring application context that can result in
difficulties in introspecting the Type of a Spring reference - namely if
the actual parameters of the Bean are Generic types.
I am not sure that there is a real problem here.
To quote one of Ram's examples from the JIRA:
public void setSomeList(List<?> someList)
...might be the declaration for the setter method for a property on some
Spring Bean.
I believe that in this case, the FORMAL type of the List is effectively
List<Object> - ie the list can contain Objects of any Java class.
I think that it is possible to introspect this and to make the type of
the reference Object. In XML terms, I believe that this translates
to an <any/>.
In SCA terms this can only be introspected as a <property/> since
there is no remotable interface. It is a <property/> of type <any/>.
If the owner of the Spring application context does not want this mapping,
then they have the facility of using the <sca:reference/>
element to explicitly state what kind of SCA artifact they want.
So I believe that it is possible to close Issue 149 with no action.
An alternative is to add a minimal amount of explanatory text as follows,
to the end of section 3 (Component Type of a Spring Application Context):
-------------------------------
3.1 Introspecting the Type Implied by a Spring Bean Reference
In the case where a reference or a property in the component type is derived
by introspection of bean references, the type of the reference or property
is determined by introspection of the related property setter method or
constructor method of the Bean which is the source of the reference.
In some cases, the type introspected by this process could be a generic
type - for example a List<?>. In such cases, the formal type of the
reference
becomes Object. This will be interpreted as an SCA property with a Java
type of Object, which maps to an XML type of <any/>.
-------------------------------
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]