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:[EMAIL PROTECTED] > Sent: Thursday, November 02, 2006 2:37 AM > To: [email protected] > 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 > > > > > > > > > > > > >
