hi, Is it allowed to merge the spring and blueprint versions of configuration schemas and use the resulting schema for both cases?
If the answer is a definitive no, the rest of this mail can be ignored. If the answer is yes or maybe, I would like to explain why I am asking this question. For the blueprint based configuration, we are using separate BP specific XML schemas to refer to those BP specific attributes that are relevant (e.g., for life-cycle management). As an example, a BP based schema uses its base type Tcomponent while its spring version uses its base type identifiedType. BP's Tcomponent has some additional attributes relevant for BP. The BP's schema itself uses this Tcomponent to define its various BP artifact types such as bean, service, etc, while the spring's own schema similarly uses its identifiedType to define its own spring artifact types. My question is whether it is necessary to have two configuration schema versions when we are defining our own configuration types. Could we have a single compound schema that can accept both artifacts that we can use to derive our configuration object types? Having two versions of the configuration schema is the right thing to clearly distinguish the difference of the two. For most components, this does not introduce any significant overhead other than physically having to maintain two almost identical schemas because their configuration objects are not complex. However, the situation is somewhat different for the ws-rm component. The ws-rm component uses a few jaxb based complex configuration objects and these complex jaxb types are currently defined in the spring version of the ws-rm namespace. When I made ws-rm into BP-ready, I didn't want to generate the identical jaxb types in another namespace and at the same time I wanted to keep the ws-rm configuration simple, I simply reused the spring version of the namespace for BP. In other words, I created another schema (for BP with the additional BP artifact attributes) using the same namespace as in the spring one. But this approach violates the convention of uniquely associating a namespace to its schema definition. As such, this needs to be corrected. And I have considered several options and I would like to get your comments. Hera are the 4 options considered for ws-rm: Option 1 Define two elements (wsrm-mgr:rmManager and wsrm-mgr:jdbcStore) in the new ws-rm BP namespace and keep the rest in the current ws-rm namespace and import them into the new ws-rm BP schema. Pro: straightforward implementation, no schema duplication for the identical parts, no duplicated jaxb classes Con: need two ws-rm namespaces for a BP based ws-rm configuration when the above two elements are configured. Option 2 Duplicate all the definitions in the new ws-rm BP namespace. Pro: one namespace in the configuration Con: schema and jaxb class duplicated, mapping of those jaxb objects required (however, this could be avoided by not simply duplicating each definition but making each definitions to be defined as an extension of its counterpart). Option 3 Declare only the elements in the new ws-rm BP namespace and keep the types in the original schema. And set the substitutionGroup property of each newly defined element to refer to its counterpart element in the original schema. Pro: one namespace in the configuration, no jaxb class duplicated, no jaxb objects mapping required Con: slightly more complex jaxb classes generated (as each substitutable element is wrapped in JAXBElement to carry its xml element information). Option 4 Merge/collapse the spring and BP artifacts into one bag of attributes and use one configuration schema for both spring and BP versions. Let the configuration runtime (i.e., the namespace handlers) recognize the relevant attributes. Pro: one shared schema, one namespace, no jaxb class duplication, straightforward implementation Con: irrelevant attributes are allowed by the schema (however, these irrelevant attributes can be checked by the corresponding namespace handlers during the configuration time). I am inclined towards option 4 for its simplicity. But I am not sure if the this approach is somehow discouraged or prohibited. Concretely, option 4 would derive a configuration type not from either bp-beans:Tcomponent or s-beans:identifiedType, but from a type that contains their merged artifact attribute groups and use this base type for both cases. In that way, we would need one configuration schema to maintain. If this approach is disallowed, I am opting for option 1 for ws-rm. Options 2 and 3 require an unnecessary duplication of various resources which does not appear to be justifiable for the ws-rm component, I think. I would appreciate your comments. thanks. regards, aki
