Re: [sca-j] JAVA-139: Proposed resolution

[David Booz <booz@us.ibm.com>]

I think I'm on a different point. In the case of a component definition, we know the type of the property from the underlying definition of the property in the componentType of the implementation. There is no coercion needed because the type is well known. In the case of your proposal, the default value is typed as a string [] where as the property itself might be some other type, like an int or even a complex type (POJO). In this case, coercion is needed from string [] to the property type. We don't have other cases of this in the specs today that I'm aware of.

What "existing" rules do you think are missing?

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

Simon Nash <oasis@cjnash.com> wrote on 07/02/2009 06:15:24 AM:

> [image removed]
>
> Re: [sca-j] JAVA-139: Proposed resolution
>
> Simon Nash
>
> to:
>
> David Booz
>
> 07/02/2009 06:17 AM
>
> Cc:
>
> sca-j
>
> Dave,
> I did think about this when writing the proposal.  The coercion
> rules for the defaultValue attribute (for properties of any type)
> should be the same as the existing coercion rules for a property
> value specified in the component definition (for properties of
> any type).
>
> Unfortunately, I was unable to find any text in the Java specs
> describing the coercion rules for property values specified in
> the component definition, or what happens if coercion of these
> values fails.  I did not think it was within the scope of JAVA-139
> to add new text describing these existing coercion rules for
> component property values.
>
> I think the best approach is to raise an issue for the lack of
> existing coercion rules for property values.  When this is resolved
> by adding suitable text, I can update the proposal for JAVA-139 to
> refer to this added text.
>
> To answer your questions: This proposal does apply to properties
> of all types, and I do still think we need to do this.
>
>    Simon
>
> David Booz wrote:
> > The proposal doesn't say anything about typing. Was your assumption that
> > the runtime would attempt to coerce the string values into the type of
> > the property? If so;
> > 1) you need to say how that works in the spec.
> > 2) you need to describe what happens if the coercion fails.
> >
> > If not, then you need to explicity state that the property type has to
> > be string [] to use this feature.
> >
> > Do you still think we need to do this?
> >
> > 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 Simon Nash ---06/29/2009 06:10:32 AM---I am
> > attaching updated JavaCAA and JavaCI documents containingSimon Nash
> > ---06/29/2009 06:10:32 AM---I am attaching updated JavaCAA and JavaCI
> > documents containing a proposed resolution to JAVA-139.
> >
> >
> > From:  
> > Simon Nash <oasis@cjnash.com>
> >
> > To:  
> > OASIS Java <sca-j@lists.oasis-open.org>
> >
> > Date:  
> > 06/29/2009 06:10 AM
> >
> > Subject:  
> > [sca-j] JAVA-139: Proposed resolution
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > I am attaching updated JavaCAA and JavaCI documents containing
> > a proposed resolution to JAVA-139.
> >
> >   Simon
> >
> > [attachment "sca-javacaa-1.1-spec-cd03+issue139.doc" deleted by David
> > Booz/Poughkeepsie/IBM] [attachment
> > "sca-javaci-1.1-spec-cd01+issue139.doc" deleted by David
> > Booz/Poughkeepsie/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
> >
>
>