cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: thought on spring and blueprint configuration schemas
Date Tue, 06 Dec 2011 13:25:46 GMT
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.


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

Blog: (English)
Twitter: willemjiang
Weibo: willemjiang

View raw message