You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by bu...@apache.org on 2018/04/17 11:57:30 UTC
svn commit: r1028550 - in /websites/production/cxf/content:
cache/docs.pageCache cache/main.pageCache coding-guidelines.html
docs/configuration-of-runtime-constructed-objects.html
docs/configuration-of-the-bus.html docs/cxf-architecture.html
Author: buildbot
Date: Tue Apr 17 11:57:30 2018
New Revision: 1028550
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/docs.pageCache
websites/production/cxf/content/cache/main.pageCache
websites/production/cxf/content/coding-guidelines.html
websites/production/cxf/content/docs/configuration-of-runtime-constructed-objects.html
websites/production/cxf/content/docs/configuration-of-the-bus.html
websites/production/cxf/content/docs/cxf-architecture.html
Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/coding-guidelines.html
==============================================================================
--- websites/production/cxf/content/coding-guidelines.html (original)
+++ websites/production/cxf/content/coding-guidelines.html Tue Apr 17 11:57:30 2018
@@ -99,62 +99,7 @@ Apache CXF -- Coding Guidelines
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><h1 id="CodingGuidelines-Introduction">Introduction</h1>
-
-<p>CXF makes use of both PMD and CheckStyle to enforce common coding conventions. However, not everything can be expressed in a rule in one of these systems. This page describes additional conventions and considerations.</p>
-
-<h2 id="CodingGuidelines-CodeFormatting">Code Formatting</h2>
-
-<p>We use an indent of 4 characters with spaces not tabs. The line length is 110 characters.<br clear="none">
-For Eclipse there is a <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/etc/eclipse/CXFCodeFormatter.xml">CXFCodeFormatter.xml</a> you can use.</p>
-
-<h2 id="CodingGuidelines-Projectsandpackages(proposal)">Projects and packages (proposal)</h2>
-
-<p>The package base for all CXF packages is "org.apache.cxf".</p>
-
-<p>CXF is organized in maven projects. The groupId and artifactId of a project should relate to the base package name of the project. So for example<br clear="none">
-a maven project with groupId="org.apache.cxf" and artifactId="cxf-rt-transports-http-jetty" should only contain packages below "org.apache.cxf.transports.http-jetty.*".</p>
-
-<p>It should always be avoided to have the same package name in more than one maven project as this will cause a lot of trouble in OSGi.</p>
-
-<h2 id="CodingGuidelines-CyclicDependencies(proposal)">Cyclic Dependencies (proposal)</h2>
-
-<p>Cyclic dependencies between packages should be avoided as they make maintenance harder and make it more difficult to understand the architecture. Some more details can be found at: <a shape="rect" class="external-link" href="http://www.headwaysoftware.com/blog/2008/12/software-erosion-and-package-tangles/" rel="nofollow">Software erosion and package tangles</a></p>
-
-<p>Every CXF committer can get a free license of the Architecture tool <a shape="rect" class="external-link" href="http://www.headwaysoftware.com/downloads/index.php?product=Structure101" rel="nofollow">structure 101</a> which is very helpfull in finding and avoiding cyclic dependencies. Just tell them that you are committer at Apache CXF to get a free license.</p>
-
-<h2 id="CodingGuidelines-CommonsXMLSchema">Commons XML Schema</h2>
-
-<p>CXF makes internal use of the Apache Commons XML Schema. Web services are defined in terms of XML Schemas, and that library provides a data model.</p>
-
-<p>The code from the XML Schema project provides almost no consistency checking. For each object in the model, it provides all the fields for all the possible settings. It does not provide or enforce a consistent discipline. It is very easy to write code that produces paradoxical schemas that have unexpected consequences. CXF includes some utilities that address some of these issues.</p>
-
-<p>The XML Schema developers are very fond of 'final', so CXF does not have the option of using subclasses as a way to implement and enforce a model. Instead, CXF defines utilities and wrappers in org.apache.cxf.common.xmlschema.</p>
-
-<h3 id="CodingGuidelines-ElementNamesandReferences">Element Names and References</h3>
-
-<p>In the standard for XML Schema, an element can have a name (a QName) or a refName (another QName). Not both. Commons XML Schema provides the Element object with a QName, a Name, and a refName. The first is a string while the latter two are QNames. </p>
-
-<p>The possibilities for inconsistency here are numerous. You can set the name to be different from the local part of the QName. You can set both a name and a refName.</p>
-
-<p>To avoid this, use the functions in the XmlSchemaTools class. It provides functions for setting these three values. </p>
-
-<p>CXF code should never call XmlSchemaElement.setName. The XMLSchemaTools functions will always set it, as a convenience value, to the local part of the refName or the QName, whichever is active.</p>
-
-<p>CXF code should never call XmlSchemaElement.setQName or setRefName. Call XmlSchemaTools.setElementQName or <br clear="none">
-XmlSchemaTools.setElementRefName. These function will throw an exception in the case of an inconsistency, and will also call setName<br clear="none">
-with the local part.</p>
-
-<h3 id="CodingGuidelines-TheSchemaCollection">The Schema Collection</h3>
-
-<p>Each CXF service (or, if you prefer, WSDL), has a collection of XML schemas (schemata?). When one schema element refers to another with a qualified name, (e.g. type="bloop:Bleep"), the prefix is as defined for the current schema (or the WSDL as a whole), and the namespace referenced by the schema must be one of the schemas in the collection.</p>
-
-<p>Commons XML Schema provides XmlSchemaCollection for this purpose. It has a number of, well, surprising characteristics. Generally, its authors gave much more thought to the case of reading schemas in from XML files than to creating them in a program. One example: each global type or element has to be presented to the collection API twice for it to be visible to the lookup APIs.</p>
-
-<p>CXF wraps XmlSchemaCollection in the SchemaCollection class to deal with these items. </p>
-
-<p><a shape="rect" class="external-link" href="http://www.docjar.com/docs/api/org/apache/cxf/common/xmlschema/FixedExtensionDeserializer.html" rel="nofollow"><code>FixedExtensionDeserializer</code></a> is a class that works around a specific XML Schema bug.</p>
-</div>
+<div id="ConfluenceContent"><h1 id="CodingGuidelines-Introduction">Introduction</h1><p>CXF makes use of both PMD and CheckStyle to enforce common coding conventions. However, not everything can be expressed in a rule in one of these systems. This page describes additional conventions and considerations.</p><h2 id="CodingGuidelines-CodeFormatting">Code Formatting</h2><p>We use an indent of 4 characters with spaces not tabs. The line length is 110 characters.<br clear="none"> For Eclipse there is a <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/etc/eclipse/CXFCodeFormatter.xml" rel="nofollow">CXFCodeFormatter.xml</a> you can use.</p><h2 id="CodingGuidelines-Projectsandpackages(proposal)">Projects and packages (proposal)</h2><p>The package base for all CXF packages is "org.apache.cxf".</p><p>CXF is organized in maven projects. The groupId and artifactId of a project should relate to the base package name of the project. So for example<br clear="no
ne"> a maven project with groupId="org.apache.cxf" and artifactId="cxf-rt-transports-http-jetty" should only contain packages below "org.apache.cxf.transports.http-jetty.*".</p><p>It should always be avoided to have the same package name in more than one maven project as this will cause a lot of trouble in OSGi.</p><h2 id="CodingGuidelines-CyclicDependencies(proposal)">Cyclic Dependencies (proposal)</h2><p>Cyclic dependencies between packages should be avoided as they make maintenance harder and make it more difficult to understand the architecture. Some more details can be found at: <a shape="rect" class="external-link" href="http://www.headwaysoftware.com/blog/2008/12/software-erosion-and-package-tangles/" rel="nofollow">Software erosion and package tangles</a></p><p>Every CXF committer can get a free license of the Architecture tool <a shape="rect" class="external-link" href="http://www.headwaysoftware.com/downloads/index.php?product=Structure101" rel="nofollow">structure 101</a>
which is very helpful in finding and avoiding cyclic dependencies. Just tell them that you are committer at Apache CXF to get a free license.</p><h2 id="CodingGuidelines-CommonsXMLSchema">Commons XML Schema</h2><p>CXF makes internal use of the Apache Commons XML Schema. Web services are defined in terms of XML Schemas, and that library provides a data model.</p><p>The code from the XML Schema project provides almost no consistency checking. For each object in the model, it provides all the fields for all the possible settings. It does not provide or enforce a consistent discipline. It is very easy to write code that produces paradoxical schemas that have unexpected consequences. CXF includes some utilities that address some of these issues.</p><p>The XML Schema developers are very fond of 'final', so CXF does not have the option of using subclasses as a way to implement and enforce a model. Instead, CXF defines utilities and wrappers in org.apache.cxf.common.xmlschema.</p><h3 id="C
odingGuidelines-ElementNamesandReferences">Element Names and References</h3><p>In the standard for XML Schema, an element can have a name (a QName) or a refName (another QName). Not both. Commons XML Schema provides the Element object with a QName, a Name, and a refName. The first is a string while the latter two are QNames.</p><p>The possibilities for inconsistency here are numerous. You can set the name to be different from the local part of the QName. You can set both a name and a refName.</p><p>To avoid this, use the functions in the XmlSchemaTools class. It provides functions for setting these three values.</p><p>CXF code should never call XmlSchemaElement.setName. The XMLSchemaTools functions will always set it, as a convenience value, to the local part of the refName or the QName, whichever is active.</p><p>CXF code should never call XmlSchemaElement.setQName or setRefName. Call XmlSchemaTools.setElementQName or <br clear="none"> XmlSchemaTools.setElementRefName. These functi
on will throw an exception in the case of an inconsistency, and will also call setName<br clear="none"> with the local part.</p><h3 id="CodingGuidelines-TheSchemaCollection">The Schema Collection</h3><p>Each CXF service (or, if you prefer, WSDL), has a collection of XML schemas (schemata?). When one schema element refers to another with a qualified name, (e.g. type="bloop:Bleep"), the prefix is as defined for the current schema (or the WSDL as a whole), and the namespace referenced by the schema must be one of the schemas in the collection.</p><p>Commons XML Schema provides XmlSchemaCollection for this purpose. It has a number of, well, surprising characteristics. Generally, its authors gave much more thought to the case of reading schemas in from XML files than to creating them in a program. One example: each global type or element has to be presented to the collection API twice for it to be visible to the lookup APIs.</p><p>CXF wraps XmlSchemaCollection in the SchemaCollection cla
ss to deal with these items.</p><p><a shape="rect" class="external-link" href="http://www.docjar.com/docs/api/org/apache/cxf/common/xmlschema/FixedExtensionDeserializer.html" rel="nofollow"><code>FixedExtensionDeserializer</code></a> is a class that works around a specific XML Schema bug.</p></div>
</div>
<!-- Content -->
</td>
Modified: websites/production/cxf/content/docs/configuration-of-runtime-constructed-objects.html
==============================================================================
--- websites/production/cxf/content/docs/configuration-of-runtime-constructed-objects.html (original)
+++ websites/production/cxf/content/docs/configuration-of-runtime-constructed-objects.html Tue Apr 17 11:57:30 2018
@@ -32,8 +32,8 @@
<link type="text/css" rel="stylesheet" href="/resources/highlighter/styles/shThemeCXF.css">
<script src='/resources/highlighter/scripts/shCore.js'></script>
-<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
+<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -117,28 +117,16 @@ Apache CXF -- Configuration of Runtime C
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><p>All objects specified in the default bean configuration files are created by the underlying IOC container (Spring in this case) - either when the bus is initialised or by the time they are needed. Several things happen at that point:</p>
-<ol><li>Spring instantiates the object by invoking the constructor of the bean class (or a factory method) specified in the bean definition.</li><li>Spring injects the property values from the bean definition into the newly created object - either by passing them as arguments to the constructor (constructor injection) or by invoking the corresponding setters (setter based injection).</li><li>Spring invokes any post processors that the CXF runtime has registered, e.g. the Jsr250PostProcessor which takes care of invoking all @PostConstruct annotated methods in the newly created object.</li></ol>
-
-
-<p>However this can only occur for objects whose use you can anticipate. But when using the JAX-WS frontend to create a web service client:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-URL url = getClass().getResource("/HelloWorld.wsdl");
+<div id="ConfluenceContent"><p>All objects specified in the default bean configuration files are created by the underlying IOC container (Spring in this case) - either when the bus is initialised or by the time they are needed. Several things happen at that point:</p><ol><li>Spring instantiates the object by invoking the constructor of the bean class (or a factory method) specified in the bean definition.</li><li>Spring injects the property values from the bean definition into the newly created object - either by passing them as arguments to the constructor (constructor injection) or by invoking the corresponding setters (setter based injection).</li><li>Spring invokes any post processors that the CXF runtime has registered, e.g. the Jsr250PostProcessor which takes care of invoking all @PostConstruct annotated methods in the newly created object.</li></ol><p>However this can only occur for objects whose use you can anticipate. But when using the JAX-WS frontend to create a web servi
ce client:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">URL url = getClass().getResource("/HelloWorld.wsdl");
String ns = "http://cxf.apache.org/samples/HelloWorld";
QName serviceName = new QName(ns, "HelloWorldService");
QName portName = new QName(ns, "HelloWorldPort");
Service service = Service.create(url, serviceName);
HelloWorld proxy = service.getPort(portName, HelloWorld.class);
</pre>
-</div></div>
-
-<p>CXF needs to look at the wsdl to decide which binding or conduit to create for the proxy. For example, depending on the child elements of the port element in the HelloWorld.wsdl, this may be a JMS or an HTTP conduit. The creation of the actual conduit is therefore left to the CXF runtime instead of the IOC container. But we can still use the IOC container to configure this newly created object - all we need to do so is identify the object so the IOC container can look for a template bean. In the case of the HTTP conduit, the identification is via the port name, and the following bean definition:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-<bean name="{http://cxf.apache.org/samples/HelloWorld}HelloWorldPort.http-conduit" abstract="true">
+</div></div><p>CXF needs to look at the wsdl to decide which binding or conduit to create for the proxy. For example, depending on the child elements of the port element in the HelloWorld.wsdl, this may be a JMS or an HTTP conduit. The creation of the actual conduit is therefore left to the CXF runtime instead of the IOC container. But we can still use the IOC container to configure this newly created object - all we need to do so is identify the object so the IOC container can look for a template bean. In the case of the HTTP conduit, the identification is via the port name, and the following bean definition:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;"><bean name="{http://cxf.apache.org/samples/HelloWorld}HelloWorldPort.http-conduit" abstract="true">
<property name="client">
<value>
<http-conf:client DecoupledEndpoint="http://localhost:9999/decoupled_endpoint"/>
@@ -146,25 +134,13 @@ HelloWorld proxy = service.getPort(portN
</property>
</bean>
</pre>
-</div></div>
-<p>will cause the HTTP conduit (which is created when the proxy is created) to use a decoupled endpoint, i.e. expect responses on a separate incoming connection.<br clear="none">
-The registration of property editors for JAXB generated types such as HTTPClientPolicy (the value type for the client property) enables the bean configuration parser to handler the syntax above (the editors are registeres by the property editor registrars defined in the cxf-property-editors.xmk files).</p>
-
-<p>Note that the above bean is declared abstract (hence the bean class need to be specified). This underlines the fact that in this case we don't want the IOC container to create this object for us. Instead we want the IOC container to inject its properties into an object that the runtime created for us (to perform steps 2. amd 3. listed above).</p>
-
-<p>Aside from conduits, other objects that - depending on the use of the frontend, may be created by the runtime include destinations, services, client.server endpoints and bindings.<br clear="none">
-Please check the code for how these can be identified.</p>
-
-<p>Note that the container can inject dependencies (i.e. references to other objects) as well as actual property values (e.g. for the "client" property") into such objects. So it is possible for example to include a custom handler only in the interceptor chain used for the HelloWorld endpoint:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-<bean name="{http://cxf.apache.org/samples/HelloWorld}HelloWorldPort" abstract="true">
- <property name="outInterceptors">
- <property name="outInterceptors">
- <list>
- <ref bean="myLoggingInterceptor"/>
- </list>
- </property>
+</div></div><p>will cause the HTTP conduit (which is created when the proxy is created) to use a decoupled endpoint, i.e. expect responses on a separate incoming connection.<br clear="none"> The registration of property editors for JAXB generated types such as HTTPClientPolicy (the value type for the client property) enables the bean configuration parser to handler the syntax above (the editors are registered by the property editor registrars defined in the cxf-property-editors.xml files).</p><p>Note that the above bean is declared abstract (hence the bean class need to be specified). This underlines the fact that in this case we don't want the IOC container to create this object for us. Instead we want the IOC container to inject its properties into an object that the runtime created for us (to perform steps 2. and 3. listed above).</p><p>Aside from conduits, other objects that - depending on the use of the frontend, may be created by the runtime include destinations, services, cli
ent.server endpoints and bindings.<br clear="none"> Please check the code for how these can be identified.</p><p>Note that the container can inject dependencies (i.e. references to other objects) as well as actual property values (e.g. for the "client" property") into such objects. So it is possible for example to include a custom handler only in the interceptor chain used for the HelloWorld endpoint:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;"><bean name="{http://cxf.apache.org/samples/HelloWorld}HelloWorldPort" abstract="true">
+ <property name="outInterceptors">
+ <list>
+ <ref bean="myLoggingInterceptor"/>
+ </list>
+ </property>
</bean>
</pre>
</div></div></div>
Modified: websites/production/cxf/content/docs/configuration-of-the-bus.html
==============================================================================
--- websites/production/cxf/content/docs/configuration-of-the-bus.html (original)
+++ websites/production/cxf/content/docs/configuration-of-the-bus.html Tue Apr 17 11:57:30 2018
@@ -32,8 +32,8 @@
<link type="text/css" rel="stylesheet" href="/resources/highlighter/styles/shThemeCXF.css">
<script src='/resources/highlighter/scripts/shCore.js'></script>
-<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
+<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -117,29 +117,22 @@ Apache CXF -- Configuration of the Bus
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><p>By creating a bus with your own bean configuration file, i.e. using the factory method </p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">SpringBeanFactory.createBus("mycxf.xml")</pre>
-</div></div>
-<p> you can complement or overwrite the bean definitions that CXF would use by default. In this case <code>mycxf.xml</code> must be on the classpath, but you can also use a factory method taking a URL that points to your bean configuration file.</p>
-
-<p>For example, by replacing the bus bean defined in <code>cxf.xml</code> with this bean in your configuration file:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-<bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus">
+<div id="ConfluenceContent"><p>By creating a bus with your own bean configuration file, i.e. using the factory method</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">SpringBusFactory.createBus("mycxf.xml")</pre>
+</div></div><p>you can complement or overwrite the bean definitions that CXF would use by default. In this case <code>mycxf.xml</code> must be on the classpath, but you can also use a factory method taking a URL that points to your bean configuration file.</p><p>For example, by replacing the bus bean defined in <code>cxf.xml</code> with this bean in your configuration file:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;"><bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus">
<property name="outInterceptors">
- <list>
- <ref bean="myLoggingInterceptor"/>
- </list>
- </property>
+ <list>
+ <ref bean="myLoggingInterceptor"/>
+ </list>
+ </property>
</bean>
<bean id="myLogHandler" class="org.mycompany.com.cxf.logging.LoggingInterceptor">
...
</bean>
</pre>
-</div></div>
-<p>the constructed bus will use a list of out interceptors consisting of your LoggingInterceptor (the default list of out interceptors at the bus level is empty).</p></div>
+</div></div><p>the constructed bus will use a list of out interceptors consisting of your LoggingInterceptor (the default list of out interceptors at the bus level is empty).</p></div>
</div>
<!-- Content -->
</td>
Modified: websites/production/cxf/content/docs/cxf-architecture.html
==============================================================================
--- websites/production/cxf/content/docs/cxf-architecture.html (original)
+++ websites/production/cxf/content/docs/cxf-architecture.html Tue Apr 17 11:57:30 2018
@@ -117,11 +117,11 @@ Apache CXF -- CXF Architecture
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><h1 id="CXFArchitecture-ApacheCXFSoftwareArchitectureGuide">Apache CXF Software Architecture Guide</h1><p>This document provides an architectural overview of the Apache CXF services framework.</p><h2 id="CXFArchitecture-TableofContents">Table of Contents</h2><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1508777374197 {padding: 0px;}
-div.rbtoc1508777374197 ul {list-style: outline;margin-left: 0px;}
-div.rbtoc1508777374197 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1523966210043 {padding: 0px;}
+div.rbtoc1523966210043 ul {list-style: outline;margin-left: 0px;}
+div.rbtoc1523966210043 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1508777374197">
+/*]]>*/</style></p><div class="toc-macro rbtoc1523966210043">
<ul class="toc-indentation"><li><a shape="rect" href="#CXFArchitecture-ApacheCXFSoftwareArchitectureGuide">Apache CXF Software Architecture Guide</a>
<ul class="toc-indentation"><li><a shape="rect" href="#CXFArchitecture-TableofContents">Table of Contents</a></li><li><a shape="rect" href="#CXFArchitecture-ArchitecturalGoalsandConstraints">Architectural Goals and Constraints</a></li><li><a shape="rect" href="#CXFArchitecture-CXF-API">CXF-API</a>
<ul class="toc-indentation"><li><a shape="rect" href="#CXFArchitecture-Bus">Bus</a></li><li><a shape="rect" href="#CXFArchitecture-Howservicecallsareprocessed">How service calls are processed</a></li><li><a shape="rect" href="#CXFArchitecture-Front-ends">Front-ends</a></li><li><a shape="rect" href="#CXFArchitecture-Messaging&Interceptors">Messaging & Interceptors</a></li><li><a shape="rect" href="#CXFArchitecture-TheServiceModel">The Service Model</a></li><li><a shape="rect" href="#CXFArchitecture-DataBindings">Data Bindings</a></li><li><a shape="rect" href="#CXFArchitecture-ProtocolBindings">Protocol Bindings</a></li><li><a shape="rect" href="#CXFArchitecture-Transports">Transports</a></li><li><a shape="rect" href="#CXFArchitecture-AJAX-WSexample">A JAX-WS example</a></li></ul>
@@ -129,18 +129,18 @@ div.rbtoc1508777374197 li {margin-left:
<ul class="toc-indentation"><li><a shape="rect" href="#CXFArchitecture-References">References</a></li></ul>
</li></ul>
</li></ul>
-</div><h2 id="CXFArchitecture-ArchitecturalGoalsandConstraints">Architectural Goals and Constraints</h2><p>The Apache CXF services framework seeks to build the necessary infrastructure components for services. Goals for CXF are many and include:</p><ul><li>Embeddable</li><li>High performance</li><li>Easy configuration</li><li>Intuitive and easy to use</li><li>Clean separation of front-ends from the core code</li><li>Data formats support</li><li>Data bindings support</li><li>Protocol bindings support</li><li>Multiple transports support</li><li>Multiple Programming Languages Support</li><li>WS-* and related specifications support</li><li>Tools for code generation and WSDL validation</li><li>Flexible deployment</li></ul><h2 id="CXFArchitecture-CXF-API">CXF-API</h2><p>The overall CXF architecture is primarily made up of the following parts:</p><ol><li>Bus: Contains a registry of extensions, interceptors and Properties</li><li>Front-end: Front-ends provide a programming model to create s
ervices.</li><li>Messaging & Interceptors: These provide the low level message and pipeline layer upon which most functionality is built.</li><li>Service Model: Services host a Service model which is a WSDL-like model that describes the service.</li><li>Pluggable Data Bindings: ...</li><li>Protocol Bindings: Bindings provide the functionality to interpret the protocol.</li><li>Transports: Transportfactory creates Destinations (Receiving) and Conduits (Sending)</li></ol><p>In the upcoming sections, we'll take a look at each layer in turn and examine how they work together.</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image confluence-thumbnail" src="cxf-architecture.data/cxf_architecture.png"></span></p><h3 id="CXFArchitecture-Bus">Bus</h3><p>The bus, being CXF's backbone, is a provider of shared resources to the CXF runtime. Examples for such shared resources include WSDL managers and binding factory managers. The bus can easily be extende
d to include your own custom resources or services, or you can replace default resources like the HTTP destination factory (based on Jetty) with your own (possibly based on another web container such as Apache Tomcat).</p><p>This extensibility is made possible by dependency injection; the default bus implementation is based on <a shape="rect" class="external-link" href="http://www.springsource.com/developer/spring" rel="nofollow">Spring Framework</a>, which wires the runtime components together for you.</p><p>The <code>SpringBusFactory</code> searches for all bean configuration files in the <code>META-INF/cxf</code> directories on your classpath, and builds an application context from them. The bean configuration files included in the application context construction are:</p><ul><li><code>META-INF/cxf/cxf.xml</code> (e.g., in <code>cxf-rt-core</code> only)</li><li><code>META-INF/cxf/cxf-extension.xml</code> (e.g. in <code>cxf-rt-bindings-soap</code>)</li><li><code>META-INF/cxf/cxf-p
roperty-editors.xml</code> (e.g. in <code>cxf-rt-transports-http</code>)</li></ul><p>See <a shape="rect" href="configuration-of-the-bus.html">Configuration of the Bus</a> for an example of how to customize the bus by supplying your own bean configuration file and <a shape="rect" href="configuration-of-runtime-constructed-objects.html">Configuration of Runtime Constructed Objects</a> for more information on the special case of injecting into objects created by the runtime (as opposed to objects created by the IoC container itself).</p><h3 id="CXFArchitecture-Howservicecallsareprocessed">How service calls are processed</h3><p>
+</div><h2 id="CXFArchitecture-ArchitecturalGoalsandConstraints">Architectural Goals and Constraints</h2><p>The Apache CXF services framework seeks to build the necessary infrastructure components for services. Goals for CXF are many and include:</p><ul><li>Embeddable</li><li>High performance</li><li>Easy configuration</li><li>Intuitive and easy to use</li><li>Clean separation of front-ends from the core code</li><li>Data formats support</li><li>Data bindings support</li><li>Protocol bindings support</li><li>Multiple transports support</li><li>Multiple Programming Languages Support</li><li>WS-* and related specifications support</li><li>Tools for code generation and WSDL validation</li><li>Flexible deployment</li></ul><h2 id="CXFArchitecture-CXF-API">CXF-API</h2><p>The overall CXF architecture is primarily made up of the following parts:</p><ol><li>Bus: Contains a registry of extensions, interceptors and Properties</li><li>Front-end: Front-ends provide a programming model to create s
ervices.</li><li>Messaging & Interceptors: These provide the low level message and pipeline layer upon which most functionality is built.</li><li>Service Model: Services host a Service model which is a WSDL-like model that describes the service.</li><li>Pluggable Data Bindings: ...</li><li>Protocol Bindings: Bindings provide the functionality to interpret the protocol.</li><li>Transports: Transportfactory creates Destinations (Receiving) and Conduits (Sending)</li></ol><p>In the upcoming sections, we'll take a look at each layer in turn and examine how they work together.</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image confluence-thumbnail" src="cxf-architecture.data/cxf_architecture.png"></span></p><h3 id="CXFArchitecture-Bus">Bus</h3><p>The bus, being CXF's backbone, is a provider of shared resources to the CXF runtime. Examples for such shared resources include WSDL managers and binding factory managers. The bus can easily be extende
d to include your own custom resources or services, or you can replace default resources like the HTTP destination factory (based on Jetty) with your own (possibly based on another web container such as Apache Tomcat).</p><p>This extensibility is made possible by dependency injection; the default bus implementation is based on <a shape="rect" class="external-link" href="http://www.springsource.com/developer/spring" rel="nofollow">Spring Framework</a>, which wires the runtime components together for you.</p><p>The <code>SpringBusFactory</code> searches for all bean configuration files in the <code>META-INF/cxf</code> directories on your classpath, and builds an application context from them. The bean configuration files included in the application context construction are:</p><ul><li><code>META-INF/cxf/cxf.xml</code> (e.g., in <code>cxf-core</code> only)</li><li><code>META-INF/cxf/cxf-extension.xml</code> (e.g. in <code>cxf-rt-bindings-soap</code>)</li><li><code>META-INF/cxf/cxf-prop
erty-editors.xml</code> (e.g. in <code>cxf-rt-transports-http</code>)</li></ul><p>See <a shape="rect" href="configuration-of-the-bus.html">Configuration of the Bus</a> for an example of how to customize the bus by supplying your own bean configuration file and <a shape="rect" href="configuration-of-runtime-constructed-objects.html">Configuration of Runtime Constructed Objects</a> for more information on the special case of injecting into objects created by the runtime (as opposed to objects created by the IoC container itself).</p><h3 id="CXFArchitecture-Howservicecallsareprocessed">How service calls are processed</h3><p>
-<span class="gliffy-container" id="gliffy-container-25591945-9748" data-fullwidth="1269" data-ceoid="44806" data-edit="${diagramEditLink.getLinkUrl()}" data-full="${diagramZoomLink.getLinkUrl()}" data-filename="MessageFlowOnClientSide">
+<span class="gliffy-container" id="gliffy-container-25591945-2437" data-fullwidth="1269" data-ceoid="44806" data-edit="${diagramEditLink.getLinkUrl()}" data-full="${diagramZoomLink.getLinkUrl()}" data-filename="MessageFlowOnClientSide">
- <map id="gliffy-map-25591945-4427" name="gliffy-map-25591945-4427"></map>
+ <map id="gliffy-map-25591945-3788" name="gliffy-map-25591945-3788"></map>
- <img class="gliffy-image" id="gliffy-image-25591945-9748" width="600" height="274" data-full-width="1269" data-full-height="580" src="https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnClientSide.png?version=4&modificationDate=1298215366000&api=v2" alt="MessageFlowOnClientSide" usemap="#gliffy-map-25591945-4427">
+ <img class="gliffy-image" id="gliffy-image-25591945-2437" width="600" height="274" data-full-width="1269" data-full-height="580" src="https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnClientSide.png?version=4&modificationDate=1298215366000&api=v2" alt="MessageFlowOnClientSide" usemap="#gliffy-map-25591945-3788">
- <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591945-9748" name="gliffy-dynamic-map-25591945-9748"></map>
+ <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591945-2437" name="gliffy-dynamic-map-25591945-2437"></map>
</span>
@@ -149,13 +149,13 @@ div.rbtoc1508777374197 li {margin-left:
-<span class="gliffy-container" id="gliffy-container-25591953-6475" data-fullwidth="1222" data-ceoid="44806" data-edit="${diagramEditLink.getLinkUrl()}" data-full="${diagramZoomLink.getLinkUrl()}" data-filename="MessageFlowOnServerSide">
+<span class="gliffy-container" id="gliffy-container-25591953-1514" data-fullwidth="1222" data-ceoid="44806" data-edit="${diagramEditLink.getLinkUrl()}" data-full="${diagramZoomLink.getLinkUrl()}" data-filename="MessageFlowOnServerSide">
- <map id="gliffy-map-25591953-6574" name="gliffy-map-25591953-6574"></map>
+ <map id="gliffy-map-25591953-1472" name="gliffy-map-25591953-1472"></map>
- <img class="gliffy-image" id="gliffy-image-25591953-6475" width="600" height="295" data-full-width="1222" data-full-height="600" src="https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnServerSide.png?version=4&modificationDate=1298310696000&api=v2" alt="MessageFlowOnServerSide" usemap="#gliffy-map-25591953-6574">
+ <img class="gliffy-image" id="gliffy-image-25591953-1514" width="600" height="295" data-full-width="1222" data-full-height="600" src="https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnServerSide.png?version=4&modificationDate=1298310696000&api=v2" alt="MessageFlowOnServerSide" usemap="#gliffy-map-25591953-1472">
- <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591953-6475" name="gliffy-dynamic-map-25591953-6475"></map>
+ <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591953-1514" name="gliffy-dynamic-map-25591953-1514"></map>
</span>
@@ -171,7 +171,7 @@ div.rbtoc1508777374197 li {margin-left:
writeSoapEnvelopeEnd();
}
</pre>
-</div></div><h3 id="CXFArchitecture-TheServiceModel">The Service Model</h3><p>The Service model is the representation of a service within CXF. It is made up of two parts. First there is the <code>ServiceInfo</code> which contains a WSDL-like model of the service and its operations, bindings, endpoints and schema. Second, there is the Service itself, which contains the <code>ServiceInfo</code>, data-binding information, service interceptors, service properties and more.</p><p>A service can be constructed from many different sources including classes and WSDLs (1.1 or 2.0). Typically front-ends are responsible for creating a service via service factories. Factory components such as <code>ServerFactoryBean</code> and <code>ClientProxyFactoryBean</code> can used with the front-end to create, publish and consume web services. The factory classes build up the service model and configure the service interceptors, data bindings and more.</p><p>The Service model itself is contained in the <c
ode>ServiceInfo</code> class. The following image depicts a subset of the Service Model's packaged API:</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image confluence-thumbnail" src="cxf-architecture.data/service_model.png"></span></p><h3 id="CXFArchitecture-DataBindings">Data Bindings</h3><p>Data bindings implement the mapping between XML elements and Java objects. Data bindings convert data to and from XML, produce XML schema, and provide support for wsdl2java code generation. Not all data bindings support all of this functionality. At very least, a data binding must provide the data conversion. See <a shape="rect" href="data-binding-architecture.html">Data Binding Architecture</a> for details. Currently supported data bindings include JAXB 2.x (default), Aegis, Apache XMLBeans, Service Data Objects (SDO) and JiBX (under development).</p><h3 id="CXFArchitecture-ProtocolBindings">Protocol Bindings</h3><p>Bindings provide ways to map concrete f
ormats and protocols on top of transports. A binding contains two main parts, a <code>BindingFactory</code> and a <code>Binding</code>. A <code>BindingFactory</code> builds a <code>Binding</code> from the service model's <code>BindingInfo</code>. The binding contains interceptors specific to the binding and also implements the <code>createMessage()</code> method, which creates a <code>Message</code> implementation specific for that binding.</p><p>CXF currently supported the following bindings protocols: SOAP 1.1, SOAP 1.2, REST/HTTP, pure XML and CORBA.</p><h4 id="CXFArchitecture-TheSoapBinding">The Soap Binding</h4><p>The prototypical binding is SOAP. It has its own <code>Message</code> class called the <code>SoapMessage</code>. It adds the ability to hold the current <code>SoapVersion</code> and the headers for the message.</p><p>The <code>Soap</code> binding also adds a special type of interceptor called the <code>SoapInterceptor</code>. The <code>SoapInterceptor</code> adds two
methods to the <code>Interceptor</code> class:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><h3 id="CXFArchitecture-TheServiceModel">The Service Model</h3><p>The Service model is the representation of a service within CXF. It is made up of two parts. First there is the <code>ServiceInfo</code> which contains a WSDL-like model of the service and its operations, bindings, endpoints and schema. Second, there is the Service itself, which contains the <code>ServiceInfo</code>, data-binding information, service interceptors, service properties and more.</p><p>A service can be constructed from many different sources including classes and WSDLs (1.1 or 2.0). Typically front-ends are responsible for creating a service via service factories. Factory components such as <code>ServerFactoryBean</code> and <code>ClientProxyFactoryBean</code> can used with the front-end to create, publish and consume web services. The factory classes build up the service model and configure the service interceptors, data bindings and more.</p><p>The Service model itself is contained in the <c
ode>ServiceInfo</code> class. The following image depicts a subset of the Service Model's packaged API:</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image confluence-thumbnail" src="cxf-architecture.data/service_model.png"></span></p><h3 id="CXFArchitecture-DataBindings">Data Bindings</h3><p>Data bindings implement the mapping between XML elements and Java objects. Data bindings convert data to and from XML, produce XML schema, and provide support for wsdl2java code generation. Not all data bindings support all of this functionality. At very least, a data binding must provide the data conversion. See <a shape="rect" href="data-binding-architecture.html">Data Binding Architecture</a> for details. Currently supported data bindings include JAXB 2.x (default) and Aegis.</p><h3 id="CXFArchitecture-ProtocolBindings">Protocol Bindings</h3><p>Bindings provide ways to map concrete formats and protocols on top of transports. A binding contains two main
parts, a <code>BindingFactory</code> and a <code>Binding</code>. A <code>BindingFactory</code> builds a <code>Binding</code> from the service model's <code>BindingInfo</code>. The binding contains interceptors specific to the binding and also implements the <code>createMessage()</code> method, which creates a <code>Message</code> implementation specific for that binding.</p><p>CXF currently supported the following bindings protocols: SOAP 1.1, SOAP 1.2, REST/HTTP, pure XML and CORBA.</p><h4 id="CXFArchitecture-TheSoapBinding">The Soap Binding</h4><p>The prototypical binding is SOAP. It has its own <code>Message</code> class called the <code>SoapMessage</code>. It adds the ability to hold the current <code>SoapVersion</code> and the headers for the message.</p><p>The <code>Soap</code> binding also adds a special type of interceptor called the <code>SoapInterceptor</code>. The <code>SoapInterceptor</code> adds two methods to the <code>Interceptor</code> class:</p><div class="code pane
l pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">Set<URI> getRoles();
Set<QName> getUnderstoodHeaders();
</pre>