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

[Simon Nash <oasis@cjnash.com>]

Dave,
In the case of a property defined using @Property with defaultValue(),
the SCA property type is well defined and becomes part of the
component type as specified by the component type introspection rules
in chapter 8 of JavaCI, just as it would without defaultValue().

I can't see much difference between the following two cases:

  1. The property type is computed from the @Property element using the
     rules specified in chapter 8 of JavaCI, and its value is provided by
     a component definition in one of the following ways:
      a) using a value attribute on the <property> element
      b) inside a <value> element or elements within the <property> element
      c) as XML content of the <property> element
      d) as the value of another <property> element
      e) as the contents of a file
     In all these cases, the SCA runtime must convert the value
     (supplied either as a string or as XML) into the Java type of
     the property.

  2. The property type is computed from the @Property element using the
     rules specified in chapter 8 of JavaCI, and its value is supplied in
     the defaultValue() attribute.  In this case, the SCA runtime must
     convert the value (supplied either as a string or as XML) into the
     Java type of the property.

For case 1, there's currently no definition of how the string or XML
provided by the component definition is converted into a Java primitive
or Java object to inject into the component implementation.  There's
also nothing in either the Java specs or the assembly spec saying what
happens if this conversion fails (e.g., the Java property type is "int"
and the supplied value is "ABC").

If we define these conversion rules for case 1, the same rules can be
used for case 2.  The property type is computed in exactly the same way
for both cases.

   Simon

David Booz wrote:
> 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
>  > >
>  >
>  >
>