[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: JAVA-131: Proposed direction for resolution
OK, I am finally biting the bullet on this one! I found something in the spec that has caused me to reverse my previous position. Section 9.17 (@Reference) says that an unwired reference of multiplicity 0..1 is presented to the implementation code by the SCA runtime as null, and an unwired reference of multiplicity 0..n is presented as an empty array. This implies that unwired references of multiplicity 0..n are explicitly injected. Unwired field references of multiplicity 0..1 don't need to be injected, because Java will provide a null value. Unwired setter references of multiplicity 0..n are explicitly injected. For unwired setter references, whether or not to inject will be decided by this issue. Constructor references are never 0..1 or 0..n, so there will always be a non-null value for these. It may be useful to summarize the valid combinations in a table: 0..1 unwired 0..n unwired Field injection not needed empty array Field reinjection null empty array Setter injection ? empty array Setter reinjection null empty array The right-hand column is a model of consistency. The left-hand column is all over the map. For simplicity and consistency, I think we should put "null" all the way down the left-hand column. Now let's consider callbacks. I can't think of any good reason why unwired callbacks should be treated differently from unwired references. A reasonable model is to think of callbacks as having: a) multiplicity 1..1 if all services of the component are bidirectional and have a callback interface that matches the callback field or setter b) multiplicity 0..1 if some but not all services of the component are bidirectional and have a callback interface that matches the callback field or setter c) multiplicity 0..0 if no services of the component are bidirectional and have a callback interface that matches the callback field or setter We can simplify the number of combinations by saying that c) is an error, as the callback field or setter could never be injected. For a), a callback proxy is always injected. For b), I think we should be consistent with references and inject null into fields or setters when there is no callback. This is something of a corner case, so performance overhead shouldn't be an issue. At present, callbacks can't be constructor parameters. I think we should allow this for case a) but not for case b). This is consistent with references. For properties with mustSupply=false, it's possible for no value to be configured. However, the Java implementation might have set a default value in the code, so injecting null or an empty array would wipe out the implementation's default value. This would be a common source of errors, so we should say that properties are only injected if they have a value configured in the component type or component definition. This is the exact opposite of how we would treat unwired references, but I think people will understand the reason for the difference. Comments, questions? Simon
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]