Hi Willem, thanks for the information. This is certainly one option that we can take, which is similar to option 2 but without the disadvantage of having duplicated classes or having to maintain manually two almost identical schemas.
But it is kind of complex. I am feeling that everything would become very simple if we could go for option 4. regards, aki 2011/12/6 Willem Jiang <[email protected]>: > Hi Aki， > > If you take a look at the camel-blueprint [1], you will find the schema is > generated from JAXB annotated class and replace the target namespace with > the blueprint one. > > In this way we could reuse the module class as much as possible. > > [1]https://svn.apache.org/repos/asf/camel/trunk/components/camel-blueprint/pom.xml > > > On Tue Dec 6 21:00:26 2011, Aki Yoshida wrote: >> >> 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 >> > > > -- > Willem > ---------------------------------- > FuseSource > Web: http://www.fusesource.com > Blog: http://willemjiang.blogspot.com (English) > http://jnn.javaeye.com (Chinese) > Twitter: willemjiang > Weibo: willemjiang
