cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <>
Subject Re: FW: configuration metadata and schemas
Date Wed, 01 Nov 2006 18:37:18 GMT
Lin, Bozhong wrote:

>[don't know why my previous "send" did not make it, here send it again]
>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.


>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?

View raw message