Author: buildbot
Date: Mon Apr 16 09:57:28 2018
New Revision: 1028490
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/docs.pageCache
websites/production/cxf/content/docs/configuration-for-developers.html
Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/docs/configuration-for-developers.html
==============================================================================
--- websites/production/cxf/content/docs/configuration-for-developers.html
(original)
+++ websites/production/cxf/content/docs/configuration-for-developers.html Mon
Apr 16 09:57:28 2018
@@ -107,41 +107,7 @@ Apache CXF -- Configuration for Develope
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><h1
id="ConfigurationforDevelopers-HowCXFconfigurationworks">How CXF configuration
works</h1>
-<p>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:<br clear="none">
-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.<br clear="none">
-2. Generate JAXB types for the XSD in #1<br clear="none">
-3. Create configuration properties on your bean by using the JAXB generated
types<br clear="none">
-4. Write a BeanDefinitionParser for Spring</p>
-
-<h1
id="ConfigurationforDevelopers-AddingconfigurationsupportforyourcomponentinCXF">Adding
configuration support for your component in CXF</h1>
-
-<p>Let's say we want to add configuration for an HTTP Conduit inside CXF. </p>
-
-<p>TODO: Example forthcoming...</p>
-
-<h1 id="ConfigurationforDevelopers-RulesofConfiguration">Rules of
Configuration</h1>
-<p>Please follow the following guidelines when writing configuration related
code in CXF.</p>
-
-<p><strong>1. Keep in mind <em>all</em> your users.</strong><br clear="none">
-We have three configuration scenarios that we worry about.<br clear="none">
-1. Spring 2.0 Configuration Files<br clear="none">
-2. API users<br clear="none">
-3. Configuration embedded in the WSDL</p>
-
-<p><strong>2. Don't hide configuration objects in private fields, make it
available via the API</strong><br clear="none">
-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.</p>
-
-<p><strong>3. Use new namespaces sparingly</strong><br clear="none">
-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.</p>
-
-<p><strong>4. When writing XML schemas start elements and attributes with
lower case letters</strong><br clear="none">
-Instead of "<Conduit ConnectionTimeout="300">" we prefer "<conduit
connectionTimeout="300">"</p>
-
-<p><strong>5. Don't create redundant schema names</strong><br clear="none">
-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.../></p>
-
-<p><strong>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.</strong></p></div>
+<div id="ConfluenceContent"><h1
id="ConfigurationforDevelopers-HowCXFconfigurationworks">How CXF configuration
works</h1><p>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:<br clear="none">
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.<br clear="none"> 2.
Generate JAXB types for the XSD in #1<br clear="none"> 3. Create configuration
properties on your bean by using the JAXB generated types<br clear="none"> 4.
Write a BeanDefinitionParser for Spring</p><h1
id="ConfigurationforDevelopers-RulesofConfiguration">Rules of
Configuration</h1><p>Please follow the following guidelines when writing
configuration related code in CXF.</p><p><strong>1. Keep in mind <em>all</em>
your use
rs.</strong><br clear="none"> We have three configuration scenarios that we
worry about.<br clear="none"> 1. Spring 2.0 Configuration Files<br
clear="none"> 2. API users<br clear="none"> 3. Configuration embedded in the
WSDL</p><p> </p><p><strong>2. Don't hide configuration objects in private
fields, make it available via the API</strong><br clear="none"> 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.</p><p> </p><p><strong>3. Use new namespaces sparingly</strong><br
clear="none"> 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.</p><p> </p><p><str
ong>4. When writing XML schemas start elements and attributes with lower case
letters</strong><br clear="none"> Instead of "<Conduit
ConnectionTimeout="300">" we prefer "<conduit
connectionTimeout="300">"</p><p> </p><p><strong>5. Don't create
redundant schema names</strong><br clear="none"> 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.../></p><p> </p><p><strong>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.</strong></p></div>
</div>
<!-- Content -->
</td>
