Re: [sca-j] JAVA-139: Discussion

[Simon Nash <oasis@cjnash.com>]

David Booz wrote:
> Following the brief discussion on the telecon today, I started thinking 
> about this issue. We noted that the Assembly spec defaults mustSupply to 
> false, but @Property defaults mustSupply behavior to true. Suppose we 
> changed the default for @Property to mustSupply=false (which is spelled 
> required(false) ) then at least the default value in the implementation 
> would be used in the default configuration, i.e., the component 
> definition provides no value and the @Property annotation is specified 
> in it's simplest form (or may be completely absent).
> 
> So then now the question arises, why do we need an SCA default? Why is 
> it important for SCA to be aware of a default property value? What would 
> SCA do with the default value?
> 
> If a property is mustSupply=false and was not given an initial value in 
> the implementation then the property will have the value given by the 
> JVM. If the component developer cannot know the value, he can use the 
> mustSupply feature to ensure that it gets set, in which case any default 
> in the code is appropriately meaningless. As long as the runtime only 
> injects a configured value, then we seem to have reasonable behavior. 
> Why do we need anything more? I guess I've lost the original use case 
> behind this issue.
> 
I think the only problem with this approach is that the getProperty()
API would not be able to return a property value set by Java code,
because the value given by the Java code will not be known to the
SCA runtime.

This seems like a minor disadvantage compared with the complexity that
results from trying to provide a default value that would be known
to the SCA runtime.

So I am inclined to agree with your suggestion to resolve JAVA-139 by
changing the default for @Property to required="false".

Interestingly, this was the default for @Property in the OSOA spec,
and we changed it some time last year.  I recall the discussion and
decision to do this, but I don't recall the reason why.  Can anyone
remember why we thought required="true" was a better default?

   Simon

> 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 06/15/2009 10:24:42 AM:
> 
>  > [image removed]
>  >
>  > [sca-j] JAVA-139: Discussion
>  >
>  > Simon Nash
>  >
>  > to:
>  >
>  > OASIS Java
>  >
>  > 06/15/2009 10:25 AM
>  >
>  > I haven't had any reply from Vamsi to the email I sent him about this.
>  >
>  > The main problem I see is what type to use for the new defaultValue
>  > attribute on the @Property annotation.  @Property can to applied to
>  > any Java type, which means that the default value can also be of any
>  > Java type.
>  >
>  > It's not possible to use a type of java.lang.Object for an attribute
>  > of an annotation.  One possible approach would be to define separate
>  > defaultValueXXX attributes for each Java primitive type and String.
>  > With this approach, the user would have to write code like:
>  >    @Property defaultValueInt(10)
>  >    protected int discountRate;
>  > We would also need defaultValueXXX attributes for arrays of these types.
>  >
>  > This takes care of simple-valued properties, but it doesn't provide
>  > any way to provide a default for a complex-valued property that is
>  > represented in Java by a class using JAXB mappings.
>  >
>  > For the complex-valued property case (including enums), it would be
>  > possible to use an XML string to represent the default value.  We
>  > could support this by defining a defaultValueXML attribute.
>  >
>  > With this approach we would need the following new attributes:
>  >    boolean defaultValueBoolean() default false;
>  >    byte defaultValueByte() default 0;
>  >    char defaultValueChar() default ' ';
>  >    double defaultValueDouble() default 0.0d;
>  >    float defaultValueFloat() default 0.0f;
>  >    int defaultValueInt() default 0;
>  >    long defaultValueLong() default 0;
>  >    short defaultValueShort() default 0;
>  >    String defaultValueString() default "";
>  >    boolean[] defaultValueBooleanArray() default {};
>  >    byte[] defaultValueByteArray() default {};
>  >    char[] defaultValueCharArray() default {};
>  >    double[] defaultValueDoubleArray() default {};
>  >    float[] defaultValueFloatArray() default {};
>  >    int[] defaultValueIntArray() default {};
>  >    long[] defaultValueLongArray() default {};
>  >    short[] defaultValueShortArray() default {};
>  >    String[] defaultValueStringArray() default {};
>  >    String defaultValueXML() default "";
>  >
>  > Comments, suggestions?
>  >
>  >    Simon
>  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > 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
>  >
>