On Tuesday, December 06, 2011 9:25:46 PM Willem Jiang wrote: > 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.
And I personally think that is a crappy solution. It ends with with schema files that are obviously machine generated and missing a lot of the extras like annotations and such that make the schema actually usable. I definitely would NOT recommend going that direction. Looking at the schemas and such, it looks like #4 should definitely be OK. Dan > 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/p > om.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 -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
