[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] JAVA-139: Discussion
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]