thought on spring and blueprint configuration schemas

[Aki Yoshida <el...@googlemail.com>]

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

Re: thought on spring and blueprint configuration schemas

[Daniel Kulp <dk...@apache.org>]

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

Re: thought on spring and blueprint configuration schemas

[Aki Yoshida <el...@googlemail.com>]

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 <wi...@gmail.com>:
> 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]https://svn.apache.org/repos/asf/camel/trunk/components/camel-blueprint/pom.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
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>         http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang

Re: thought on spring and blueprint configuration schemas

[Willem Jiang <wi...@gmail.com>]

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]https://svn.apache.org/repos/asf/camel/trunk/components/camel-blueprint/pom.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
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang