Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of jim.ma@iona.com designates
 65.223.216.181 as permitted sender)
From: "Jim Ma" <jim.ma@iona.com>
To: <cxf-dev@incubator.apache.org>
Subject: RE: FW: configuration metadata and schemas
Date: Thu, 2 Nov 2006 10:20:53 +0800
Message-ID: <NJEGKBFJCOPBPCAHACGLIEAACOAA.jim.ma@iona.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <4548E95E.4000104@iona.com>
Importance: Normal

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