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] JAVA-153: Proposed resolution rev3


Ok, I hadn't realized that callback had already set a precedent. I still stand by my assertion that the componentType should be a reflection of the implementation artifacts, but I don't want to argue against an existing precedent at this point in the spec lifecycle.

BTW, I don't see this as redundant info, I see it as the means for tooling to ensure the component shape contract without having to look at the implementation artifacts.

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

Inactive hide details for Mike Edwards ---06/17/2009 01:58:14 AM---Folks, My view is that IF the interface class is annotated @Mike Edwards ---06/17/2009 01:58:14 AM---Folks, My view is that IF the interface class is annotated @Remotable then it is


From:

Mike Edwards <mike_edwards@uk.ibm.com>

To:

"OASIS Java" <sca-j@lists.oasis-open.org>

Date:

06/17/2009 01:58 AM

Subject:

Re: [sca-j] JAVA-153: Proposed resolution rev3






Folks,

My view is that IF the interface class is annotated @Remotable then it is *NOT* necessary
to introspect the component type of a service or reference which uses that interface class
such that the <interface.java/> element contains the @remotable attribute set to true.

I think this is consistent with other places where the interface class contains other forms of
annotation. @Callback is the best example in my opinion - here the interface class can
contain @Callback and reference a callback interface, but the introspected componentType
simply has a <interface.java/> element which references the interface and it does not
require the callback interface to be referenced as well and yet the interface is still treated as
a callback interface.

I agree with Simon's view that redundant information is undesirable.


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

Simon Nash <oasis@cjnash.com> wrote on 16/06/2009 21:12:57:

> I think we need to be consistent here.  It seems to me that there are
> two possible consistent positions:
>
> 1. In the component type, specify the @remotable attribute only when
>     necessary (i.e., include it only when its value is "true" and when
>     it is needed to override the remotability setting that would
>     otherwise be inferred from the @interface attribute).
>
> 2. In the component type, always specify the @remotable attribute
>     (i.e., include it with an explicit value of "true" or "false"
>     whether or not this duplicates information in the @interface attribute).
>
> My preference is for 1, as in general I think it's better not to
> specify redundant information.  I think your preference is for 2.
> Any other views on this?
>






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]