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

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

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.

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
>