cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: thought on spring and blueprint configuration schemas
Date Tue, 06 Dec 2011 19:19:18 GMT
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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Mime
View raw message