Hello, all! I would like to make a few changes to our experimental ClusterConfigurationService interface, focusing on better ease-of-use and matching intuition. The majority of these can be achieved very simply by regenerating our configuration objects from the cache XSD and passing a JAXB bindings file. Importantly, using a bindings file allows us to guarantee that we continue to respect the XSD during marshaling and usmarshaling of the cluster configuration objects, as well as providing explicit documentation to future developers about the differences between the Java implementation and the XSD specification.
A) Some fields (mostly port numbers) are specified in the cache XSD to be String, but are more naturally Integers. B) The XSD specifies many `xsd:choice' elements, which generate an ambiguous mixed-type JAX container. These should be split to be separate fields with distinct setters and getters in the Java configuration objects. (Much of this has already been done manually.) C) Those `xsd:sequence' elements, which become `List<...>' fields in the corresponding Java objects, should have field, setter, and getter names that clearly indicate the plurality of that field (e.g., "List<String> getValues()" rather than "List<String> getValue()"). D) Those attributes in the XSD with fixed values should, in the Java configuration object, be represented with `public static final' fields. E) Every cluster configuration object should be Serializable so that the objects may be sent from locators to members. Thoughts? Anyone who has been using the experimental interface, do you have other input on how to make it better while still adhering (more or less) to the specification of the cache XSD? Also related, please see my other email regarding the intent of CacheElement. Imagination is Change. ~Patrick Rhomberg
