cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: thought on spring and blueprint configuration schemas
Date Tue, 06 Dec 2011 15:02:03 GMT
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 <>:
> 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]
> 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:
> Blog: (English)
> (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang

View raw message