cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject thought on spring and blueprint configuration schemas
Date Tue, 06 Dec 2011 13:00:26 GMT
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

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.


regards, aki

View raw message