Re: [sca-j] [ISSUE 149] SCA Spring C & I specification need to specify thelimitations of implicit references - Discussion and Proposal

[Mike Edwards <mike_edwards@uk.ibm.com>]

Dave,

The problem here is that we are trying
to interpret a pre-existing Spring App Context.

In the case discussed, the Spring property
can refer to a whole load of things INSIDE the app context,
with perhaps just that one bean ref
being something that SCA is supposed to supply.  We can't map 
the rest to anything in SCA because
it is stuff inside the app context that we don't control.

I suppose you might argue to stop these
kind of hybrid cases, but that would be to impose
special rules on how someone can construct
a Spring App Context, which I would not feel comfortable
to do.


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:	17/08/2009 13:02
Subject:	Re: [sca-j] [ISSUE 149] SCA Spring C & I specification need to specify the limitations of implicit references - Discussion and Proposal

---

Thanks Mike, that does help as it confirms my understanding
of what I was reading. But I still wonder why the Spring property isn't
mapped to an SCA property? What strikes me as strange is to see a subset
of the Spring property value (the bean ref) mapped to something in SCA.
Effectively, it means that the someList Spring property is not available
as a point of configuration in the SCA layer above, only the bean ref value
of the someList property is configurable. Even after a relaxing weekend,
it still seems odd. I suppose you're going to say if you want someList
to be a full configuration point, then add the <sca:property/> element
to the Spring context.

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/17/2009 05:15:16 AM---Dave, Sorry if there is confusion here.

From:	Mike Edwards <mike_edwards@uk.ibm.com>
To:	sca-j@lists.oasis-open.org
Date:	08/17/2009 05:15 AM
Subject:	Re: [sca-j] [ISSUE 149] SCA Spring C & I specification need to specify the limitations of implicit references - Discussion and Proposal

---

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

---

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