cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bozhong Lin <>
Subject Re: FW: configuration metadata and schemas
Date Thu, 02 Nov 2006 01:27:10 GMT
Ok, so the real issue might just be duplicated schemas, and the second 
issue in original email isn't really an issue.

 From your email, I assume user can tweak CXF runtime configuration 
through their custom configuration, which will override default runtime 
configuration. How about those configuration metadata, such as bean 
definition schema? Shall users have access to for bean definition? As 
long as those are well documented, this might not be a concern.

Unless anyone has objections, for M1, we will only try to remove 
duplications [1], and leave those schemas and configuration metadata in 
each individual jar.



Andrea Smyth wrote:
> Lin, Bozhong wrote:
>> [don't know why my previous "send" did not make it, here send it again]
>> Hi,
>> Right now, various resources (configuration metadata, configurations,
>> schemas) used by CXF are dispersed in different modules, and these
>> resources are eventually packaged in different jars. This causes a
>> couple issues:
>> 1. Some schemas are duplicated in several modules and packages, such as
>> wsdl.xsd and addressing.xsd. This could become difficult to maintain in
>> the long run.
> Hi Bo,
> IMO the schemata should appear in the module that first uses them (in 
> case of the addressing.wsdl that may actually be shifted to 
> cxf-rt-ws-addr, but then the addressing part in the api module should 
> also be moved into the addressing module, which could perhaps be 
> substructured into api and impl packages). This avoids duplication and 
> ensures extensibility.
> Tests in cxf-tools-validator and cxf-tools-wsdl2java and source in 
> cxf-rt-databinding should use the resources in cxf-common-metacode 
> instead of their own copies.
>> 2. End users need access to some of resources, such as configuration
>> metadata and runtime configurations. In current distribution, these
>> resources are packaged in jar and they are hard for users to access 
>> and change.
> These resources are not meant to be changed - and leaving them in their 
> resp. jars provides some protection against that.
> I agree however that in a binary distribution it would be easier for 
> users to e.g. provide overrides for default bean definitions in their 
> user cfg files if they could find the default cfg file fragments in some 
> directory instead of having to extract them from a jar.
> The downside of making these resources available on disk in binary 
> distributions is that users may change them and then wonder why their 
> changes do not have any effect.
> Andrea.
>> I see two options to resolve the issues:
>> 1. consolidate all resources to location
>> common/common/src/main/resources, and distribution can easily copy all
>> resources in this location to an installation directory accessible to
>> end users.
>> 2. modify current distribution to pick up resource in various modules
>> and put them under an installation location accessible to end users.
>> Maintenance is still an issue with this option.
>> What do you guys think about this?
>> Thanks,
>> Bo

View raw message