How CXF configuration works

CXF supports configuration through a variety of means - the API, Spring bean definitions, and configuration embedded inside the WSDL. Configuration for a component typically breaks down like so:
1. Write a schema for your Spring configuration. Optional: If you wish to allow snippets of configuration inside the WSDL, create schema types which can be referenced by both your Spring configuration and your WSDL.
2. Generate JAXB types for the XSD in #1
3. Create configuration properties on your bean by using the JAXB generated types
4. Write a BeanDefinitionParser for Spring

Adding configuration support for your component in CXF

Let's say we want to add configuration for an HTTP Conduit inside CXF.

TODO: Example forthcoming...

Rules of Configuration

Please follow the following guidelines when writing configuration related code in CXF.

1. Keep in mind all your users.
We have three configuration scenarios that we worry about.
1. Spring 2.0 Configuration Files
2. API users
3. Configuration embedded in the WSDL

2. Don't hide configuration objects in private fields, make it available via the API
Remember that a lot of users won't touch XML configuration. Example: a user creates a Client and they want to change the proxy server. We should make this as easy as possible instead of forcing them to use XML or navigate a bunch of objects.

3. Use new namespaces sparingly
When users write configuration for a component they don't want to have to worry if its in one namespace or the other. For instance, instead of dividing JMS configuration into many different namespaces, use just one so users only need to add one namespace to their configuration file.

4. When writing XML schemas start elements and attributes with lower case letters
Instead of "<Conduit ConnectionTimeout="300">" we prefer "<conduit connectionTimeout="300">"

5. Don't create redundant schema names
If you are writing a JMS transport schema, don't name your type "jmsConduit". Instead name it just "conduit". The schema type will already be in the JMS namespace so "jmsConduit" is overly redundant. Example: <jms:conduit.../> and not <jms:jmsConduit.../>

6. If your component does not need to be configured via WSDL, write your component as a bean and then just write a Spring 2.0 schema for it.