[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] [ISSUE 55] SCA Java Specifications do not Adequately Define theComponentType of a Java implementation - Updated Proposal
Hi Mike,
Regarding the multiplicity... Just like checking for the size incase of an
array or collection, the user code can always check for null in case of
scalars to avoid errors. In case of no @Property and @Reference
annotations, we are computing reference and properties as if a @Property or
a @Reference annotation without any attributes is specified on the fields
and methods. And when there is a reference defined, we will want it wired
typically whether it is multivalued or not (I recall that we rejected an
issue that proposed to change the default value of required to false in
@Reference annotation). IMO, it will be confusing if the reference is
mandated & injected in the case of scalar reference and not in the case of
an array/collection.
++Vamsi
Apache Tuscany Committer http://tuscany.apache.org
Apache Geronimo Committer and Member of PMC http://geronimo.apache.org
Mike Edwards
<mike_edwards@uk.
ibm.com> To
"OASIS Java"
12/12/2008 18:30 <sca-j@lists.oasis-open.org>
cc
Subject
Re: [sca-j] [ISSUE 55] SCA Java
Specifications do not Adequately
Define the ComponentType of a Java
implementation - Updated Proposal
Vamsi,
Thanks for a thorough review. I've attached an updated version of the
proposal that fixes the errors you found on
Lines 395, 398.
As for 475-477, my reasoning goes as follows:
- if a field is present that looks like a reference, then I think that
field would typically have to have a value in order
for it to work - so I take the view that it must be 1..1 rather than 0..1
by default, otherwise we are likely to run into
errors fairly often.
- if a field is present that is an array/collection of references, then I
take the view that by default Java code would
typically always test the size of the array/collection, which means that a
size of 0 is acceptable and so it is more
permissive to have the multiplicity default to 0..n rather than 1..n.
This is a personal view and it would be interesting to get the views of
other folk on the TC. I can see the argument
about consistency, but on the other hand, if the developer wants to be
specific, we have some very nice annotations
that will get them exactly what they want...
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 C Vamsi <vamsic007@in.ibm.com>
:
To: Mike Edwards/UK/IBM@IBMGB
Cc: "OASIS Java" <sca-j@lists.oasis-open.org>
Date 12/12/2008 11:33
:
Subj Re: [sca-j] [ISSUE 55] SCA Java Specifications do not Adequately
ect: Define the ComponentType of a Java implementation - Updated Proposal
Hi Mike,
A few comments/questions on the proposal in the attached
sca-javaci-draft-20070926_Issue55b.doc are given below.
Line 395: It should be @Reference instead of @Required
Line 398: It should be @Reference instead of @Required
Lines 475-477: Why is the multiplicity 1..1 (equivalent to required=true)
incase of interface and 0..n (equivalent to required=false) incase of
array/collection of interface? Should it be 0..1 instead of 1..1 so that
it is consistent (equivalent to required=false) in both cases? Or else we
should change 0..n to 1..n so that it is consistent with required=true
which is the default value for required attibute of @Reference annotation.
++Vamsi
Apache Tuscany Committer http://tuscany.apache.org
Apache Geronimo Committer and Member of PMC http://geronimo.apache.org
Mike Edwards
<mike_edwards@uk.
ibm.com> To
"OASIS Java"
12/12/2008 15:57 <sca-j@lists.oasis-open.org>
cc
Subject
[sca-j] [ISSUE 55] SCA Java
Specifications do not Adequately
Define the ComponentType of a Java
implementation - Updated Proposal
Folks,
Here is an updated version of the proposal for Issue 55:
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
(See attached file: sca-javaci-draft-20070926_Issue55b.doc)
---------------------------------------------------------------------
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
[attachment "sca-javaci-draft-20070926_Issue55b.doc" deleted by Mike
Edwards/UK/IBM]
---------------------------------------------------------------------
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
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
(See attached file: sca-javaci-draft-20070926_Issue55c.doc)
---------------------------------------------------------------------
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
sca-javaci-draft-20070926_Issue55c.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]