Johnson, Eric wrote:
What I meant by default appears to be off a little. The Wiki says that
by default CXF applications pick up their configuration from a file
/cxf.xml that is on the classpath. However, many of the samples use a
configuration file called something.cxf and use the -Dcxf.config.file to
specify the name of the configuration file. It sounds like the reason
for this is avoid any confusion with the other "cxf.xml" files that are
also used to configure CXF.
It sounds like there are a number of configuration files that are used
by CXF to wire itself together. If I were a developer writing a service
with CXF, what is the best way for me to supply my custom configuration
settings? Is it:
To follow what the samples do and add a configuration file using the
command line flag?
To add a cxf.xml file to my class path?
To use the URL method for creating a bus?
Hi Eric,
My preference would be programmatic specification of the location, i.e. use
(new SpringBusFactory()).createBus(URL myCfgURL)
or
(new SpringBusFactory()).createBus(String myCfgResource)
as it does not involve the setting of system properties.
If that is not an option (e.g. in portable JAX-WS application), pass a
-Dcxf.config.file=<myCfgResource> or -Dcxf.config.file.url=<myCfgURL> to
the VM as is done in the samples.
Whether URLs (relative or absolute file URL, or other forms of URL) or
classpath resources are more appropriate depends on the application and
how it is deployed.
NOTE: the names of the system properties are misleading:
"cxf.config.file" is expected to represent a classpath resource, not a
location in the file, and "cxf.config.file.url" can be any URL (that can
be resolved by Spring), not necessarily a file system URL.
In the -Dcxf.config.file case, there is no need to specify the property
if its value defaults to "cxf.xml", so simply having a "cxf.xml" on the
classpath will do.
There is no default value for system property cxf.config.file.url.
Cheers,
Andrea.
-----Original Message-----
From: Andrea Smyth [mailto:[EMAIL PROTECTED]
Sent: Monday, June 18, 2007 10:44 AM
To: [email protected]
Subject: Re: Use of ***.cxf files in the samples
Johnson, Eric wrote:
What is the reason for using .cxf files to hold the configuration
information for the samples instead of just using the
default cfx.xml
file? Is this a "Best Practice" for using CXF?
Hi Eric,
What do you mean with the default cxf.xml file - and with
'instead of'?
If you refer to the META-INF/cxf/cxf.xml shipped in the
cxf-rt-core module, this is one of many cfg files that wire
together the CXF runtime - actually its the core cfg file,
and you are unlikely to get anywhere without it.
ADDITIONALLY, demos may use a cfg file containing application
specific configuration that overwrites/completes the defaults
in the default cxf.xml files and the other default cfg files
on the class path (cxf-extension*.xml). This file is mostly
called cxf.xml also, but could also be callled
"hello-world-secure.xml" or similar to indicate Both files
will be (and must be) used, and there will be no mix up as
long as the application speciffic cfg files is not picked up
as "META-INF/cxf/cxf.xml" (it isn't, all of the demos pick it
up as "cxf.xml").
If you want to avoid this potential clash, use the URL form
of creating a bus (with an absolute file URL).
For the demos however, picking up the application (or demo)
specific cfg file from the classpath works just fine as it's
independent of the installation directory (although a
relative file URL would do the same).
Hope that helps,
Andrea.
----------------------------
IONA Technologies PLC (registered in Ireland) Registered
Number: 171387 Registered Address: The IONA Building,
Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
