cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Ma" <jim...@iona.com>
Subject RE: FW: configuration metadata and schemas
Date Thu, 02 Nov 2006 02:20:53 GMT
Hi Andrea,

I think we need to provide some configuration templates to demonstrate all
the configuration items the CXF can provide .
For example : cxf-httpserverpolicy-conf.xml , cxf-jms-conf.xml and
cxf-jmx-conf.xml .
User can modify these configuration templates file to control what they
want.  If want to let these configuration take effect , user can add this
configuration file to classpath .

Thanks

Jim




> -----Original Message-----
> From: Andrea Smyth [mailto:andrea.smyth@iona.com]
> Sent: Thursday, November 02, 2006 2:37 AM
> To: cxf-dev@incubator.apache.org
> Subject: Re: FW: configuration metadata and schemas
>
>
> 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
> >
> >
> >
> >
> >
> >
>


Mime
View raw message