cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dk...@apache.org
Subject svn commit: r1018111 [8/33] - in /websites/production/cxf/content: ./ cache/ docs/
Date Wed, 13 Sep 2017 15:05:57 GMT
Modified: websites/production/cxf/content/docs/cxf-2x-jms-configuration-removed-in-cxf-3.html
==============================================================================
--- websites/production/cxf/content/docs/cxf-2x-jms-configuration-removed-in-cxf-3.html (original)
+++ websites/production/cxf/content/docs/cxf-2x-jms-configuration-removed-in-cxf-3.html Wed Sep 13 15:05:52 2017
@@ -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/shBrushJava.js'></script>
 <script src='/resources/highlighter/scripts/shBrushBash.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
   SyntaxHighlighter.all();
@@ -118,13 +118,13 @@ Apache CXF -- CXF 2.x JMS configuration
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p>Standard JMS transport configuration in CXF is done by defining a JMSConduit or JMSDestination, discussed below.</p><h2 id="CXF2.xJMSconfiguration(removedinCXF3)-JMSNamespaces">JMS Namespaces</h2><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-WSDLNamespace">WSDL Namespace</h3><p>The WSDL extensions for defining a JMS endpoint are defined in the namespace <code><a shape="rect" href="http://cxf.apache.org/transports/jms">http://cxf.apache.org/transports/jms</a></code>. In order to use the JMS extensions you will need to add the namespace definition shown below to the definitions element of your contract.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>JMS Extension Namespace</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">xmlns:jms="http://cxf.apache.org/transports/jms"
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">xmlns:jms="http://cxf.apache.org/transports/jms"
 </pre>
 </div></div><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-ConfigurationNamespaces">Configuration Namespaces</h3><p>In order to use the JMS configuration properties you will need to add the line shown below to the <code>beans</code> element of your configuration.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>JMS Configuration Namespaces</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">xmlns:jms="http://cxf.apache.org/transports/jms"
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">xmlns:jms="http://cxf.apache.org/transports/jms"
 </pre>
 </div></div><h2 id="CXF2.xJMSconfiguration(removedinCXF3)-BasicEndpointConfiguration">Basic Endpoint Configuration</h2><p>JMS endpoints need to know certain basic information about how to establish a connection to the proper destination. This information can be provided in one of two places: WSDL or XML configuration. The following configuration elements which are described can be used in both the client side Conduits and the server side Destinations.</p><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-UsingWSDL">Using WSDL</h3><p>The JMS destination information is provided using the <code><a shape="rect" class="external-link" href="http://jmsaddress" rel="nofollow">jms:address</a></code> element and its child, the <code>jms:JMSNamingProperties</code> element. The <code><a shape="rect" class="external-link" href="http://jmsaddress" rel="nofollow">jms:address</a></code> element's attributes specify the information needed to identify the JMS broker and the destination. The <code>jms:JMSN
 amingProperties</code> element specifies the Java properties used to connect to the JNDI service.</p><h4 id="CXF2.xJMSconfiguration(removedinCXF3)-Theaddresselement">The address element</h4><p>The basic configuration for a JMS endpoint is done by using a <code><a shape="rect" class="external-link" href="http://jmsaddress" rel="nofollow">jms:address</a></code> element as the child of your service's <code>port</code> element. The <code><a shape="rect" class="external-link" href="http://jmsaddress" rel="nofollow">jms:address</a></code> element uses the attributes described below to configure the connection to the JMS broker.</p><p><span class="confluence-anchor-link" id="CXF2.xJMSconfiguration(removedinCXF3)-addressTable"></span></p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Attribute</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confl
 uenceTd"><p><code>destinationStyle</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies if the JMS destination is a JMS queue or a JMS topic.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>jndiConnectionFactoryName</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the JNDI name bound to the JMS connection factory to use when connecting to the JMS destination.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>jndiDestinationName</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the JNDI name bound to the JMS destination to which requests are sent.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>jndiReplyDestinationName</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the JNDI name bound to the JMS destinations where replies are sent. This attribute allows you to use a user defined destination for repl
 ies.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>connectionUserName</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the username to use when connecting to a JMS broker.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>connectionPassword</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the password to use when connecting to a JMS broker.</p></td></tr></tbody></table></div><h4 id="CXF2.xJMSconfiguration(removedinCXF3)-TheJMSNamingPropertieselement">The JMSNamingProperties element</h4><p>To increase interoperability with JMS and JNDI providers, the <code><a shape="rect" class="external-link" href="http://jmsaddress" rel="nofollow">jms:address</a></code> element has a child element, <code>jms:JMSNamingProperties</code>, that allows you to specify the values used to populate the properties used when connecting to the JNDI provider. The <code>jms:JMSNamingProperties</code> ele
 ment has two attributes: <code>name</code> and <code>value</code>. The <code>name</code> attribute specifies the name of the property to set. The <code>value</code> attribute specifies the value for the specified property. The <code>jms:JMSNamingProperties</code> element can also be used for specification of provider specific properties.<br clear="none"> The following is a list of common JNDI properties that can be set:</p><ol><li><code>java.naming.factory.initial</code></li><li><code>java.naming.provider.url</code></li><li><code>java.naming.factory.object</code></li><li><code>java.naming.factory.state</code></li><li><code>java.naming.factory.url.pkgs</code></li><li><code>java.naming.dns.url</code></li><li><code>java.naming.authoritative</code></li><li><code>java.naming.batchsize</code></li><li><code>java.naming.referral</code></li><li><code>java.naming.security.protocol</code></li><li><code>java.naming.security.authentication</code></li><li><code>java.naming.security.principal</cod
 e></li><li><code>java.naming.security.credentials</code></li><li><code>java.naming.language</code></li><li><code>java.naming.applet</code></li></ol><p>For more details on what information to use in these attributes, check your JNDI provider's documentation and consult the Java API reference material.</p><h4 id="CXF2.xJMSconfiguration(removedinCXF3)-Usinganamedreplydestination">Using a named reply destination</h4><p>By default, CXF endpoints using JMS create a temporary queue for sending replies back and forth. You can change this behavior by setting the <code>jndiReplyDestinationName</code> attribute in the endpoint's contract. A client endpoint will listen for replies on the specified destination and it will specify the value of the attribute in the <code>ReplyTo</code> field of all outgoing requests. A service endpoint will use the value of the <code>jndiReplyDestinationName</code> attribute as the location for placing replies if there is no destination specified in the request's 
 <code>ReplyTo</code> field.</p><p>A static reply queue can not be shared by several instances of the service client. Please use a dynamic reply queue or different queue names per instance instead.</p><p>The following example shows an example of a JMS WSDL port specification.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>JMS WSDL Port Specification</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;service name="JMSService"&gt;
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;service name="JMSService"&gt;
   &lt;port binding="tns:Greeter_SOAPBinding" name="SoapPort"&gt;
     &lt;jms:address jndiConnectionFactoryName="ConnectionFactory"
                  jndiDestinationName="dynamicQueues/test.cxf.jmstransport"&gt;
@@ -143,7 +143,7 @@ Apache CXF -- CXF 2.x JMS configuration
 <pre>{WSDLNamespace}WSDLPortName.jms-destination
 </pre>
 </div></div><p>.</p></li></ul><h4 id="CXF2.xJMSconfiguration(removedinCXF3)-Theaddresselement.1">The <code>address</code> element</h4><p>JMS connection information is specified by adding a <code><a shape="rect" class="external-link" href="http://jmsaddress" rel="nofollow">jms:address</a></code> child to the base configuration element. The <code><a shape="rect" class="external-link" href="http://jmsaddress" rel="nofollow">jms:address</a></code> element used in the configuration file is identical to the one used in the WSDL file. Its attributes are listed in the <a shape="rect" href="cxf-2x-jms-configuration-removed-in-cxf-3.html">address element's attribute table</a>. Like the <a shape="rect" class="external-link" href="http://jmsaddress" rel="nofollow">jms:address</a> element in the WSDL file, the <a shape="rect" class="external-link" href="http://jmsaddress" rel="nofollow">jms:address</a> configuration element also has a <code>jms:JMSNamingProperties</code> child element that is us
 ed to specify additional information used to connect to a JNDI provider.</p><h4 id="CXF2.xJMSconfiguration(removedinCXF3)-Example">Example</h4><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Addressing Information a Configuration File</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ct="http://cxf.apache.org/configuration/types"
        xmlns:jms="http://cxf.apache.org/transports/jms"
@@ -170,7 +170,7 @@ Apache CXF -- CXF 2.x JMS configuration
 &lt;/beans&gt;
 </pre>
 </div></div><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-ConsumerEndpointConfiguration">Consumer Endpoint Configuration</h3><p>JMS consumer endpoints specify the type of messages they use. JMS consumer endpoint can use either a JMS <code>ObjectMessage</code> or a JMS <code>TextMessage</code>. When using an <code>ObjectMessage</code> the consumer endpoint uses a <code>byte[]</code> as the method for storing data into and retrieving data from the JMS message body. When messages are sent, the message data, including any formating information, is packaged into a <code>byte[]</code> and placed into the JMS message body before it is placed on the wire. When messages are received, the consumer endpoint will attempt to unmarshall the data stored in the JMS body as if it were packed in a <code>byte[]</code>.</p><p>When using a <code>TextMessage</code>, the consumer endpoint uses a string as the method for storing and retrieving data from the JMS message body. When messages are sent, the mes
 sage information, including any format-specific information, is converted into a string and placed into the JMS message body. When messages are received the consumer endpoint will attempt to unmashall the data stored in the JMS message body as if it were packed into a string.</p><p>When native JMS applications interact with CXF consumers, the JMS application is responsible for interpreting the message and the formatting information. For example, if the CXF contract specifies that the binding used for a JMS endpoint is SOAP, and the messages are packaged as <code>TextMessage</code>, the receiving JMS application will get a text message containing all of the SOAP envelope information.</p><p>Consumer endpoint can be configured by both XML configuration and via WSDL.</p><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-UsingConfiguration.1">Using Configuration</h3><h4 id="CXF2.xJMSconfiguration(removedinCXF3)-Specifyingthemessagetype">Specifying the message type</h4><p>You can specify the m
 essage type supported by the consumer endpoint using a <code><a shape="rect" class="external-link" href="http://jmsruntimePolicy" rel="nofollow">jms:runtimePolicy</a></code> element that has a single attribute:</p><ul><li><code>messageType</code> - Specifies how the message data will be packaged as a JMS message. <code>text</code> specifies that the data will be packaged as a <code>TextMessage</code>. <code>binary</code> specifies that the data will be packaged as an <code>ObjectMessage</code>.</li></ul><p>The following example shows a configuration entry for configuring a JMS consumer endpoint.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Configuration for a JMS Consumer Endpoint</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ct="http://cxf.apache.org/configuration/types"
        xmlns:jms="http://cxf.apache.org/transports/jms"
@@ -193,7 +193,7 @@ Apache CXF -- CXF 2.x JMS configuration
 &lt;/beans&gt;
 </pre>
 </div></div><p>The id on the <code><a shape="rect" class="external-link" href="http://jmsconduit" rel="nofollow">jms:conduit</a></code> is in the form of {<code><em>WSDLNamespace</em>}<em>WSDLPortName</em>.jms-conduit</code>. This provides CXF with the information so that it can associate the configuration with your service's endpoint.</p><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-UsingWSDL.1">Using WSDL</h3><p>The type of messages accepted by a JMS consumer endpoint is configured using the optional <code><a shape="rect" class="external-link" href="http://jmsclient" rel="nofollow">jms:client</a></code> element. The <code><a shape="rect" class="external-link" href="http://jmsclient" rel="nofollow">jms:client</a></code> element is a child of the WSDL port element and has one attribute:</p><ul><li><code>messageType</code> - Specifies how the message data will be packaged as a JMS message. <code>text</code> specifies that the data will be packaged as a <code>TextMessage</code>. <code
 >binary</code> specifies that the data will be packaged as an ObjectMessage.</li></ul><h2 id="CXF2.xJMSconfiguration(removedinCXF3)-ServiceEndpointConfiguration">Service Endpoint Configuration</h2><p>JMS service endpoints have a number of behaviors that are configurable in the contract. These include:</p><ul><li>how messages are correlated</li><li>the use of durable subscriptions</li><li>if the service uses local JMS transactions</li><li>the message selectors used by the endpoint</li></ul><p>Service endpoints can be configure in one of two ways:</p><ul><li>Configuration</li><li>WSDL</li></ul><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-UsingConfiguration.2">Using Configuration</h3><h4 id="CXF2.xJMSconfiguration(removedinCXF3)-Specifyingconfigurationdata">Specifying configuration data</h4><p>Using the <code><a shape="rect" class="external-link" href="http://jmsdestination" rel="nofollow">jms:destination</a></code> elements you can configure your service's endpoint. You can specify t
 he service endpoint's behaviors using the <code><a shape="rect" class="external-link" href="http://jmsruntimePolicy" rel="nofollow">jms:runtimePolicy</a></code> element that has a the following attributes:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Attribute</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>useMessageIDAsCorrealationID</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies whether the JMS broker will use the message ID to correlate messages. The default is <code>false</code>.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>durableSubscriberName</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the name used to register a durable subscription.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>mes
 sageSelector</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the string value of a message selector to use. For more information on the syntax used to specify message <br clear="none" class="atl-forced-newline"> selectors, see the JMS 1.1 specification.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>transactional</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies whether the local JMS broker will create transactions around message processing. The default is <code>false</code>.</p></td></tr></tbody></table></div><p>The following example shows a CXF configuration entry for configuring a JMS service endpoint.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Configuration for a JMS Service Endpoint</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ct="http://cxf.apache.org/configuration/types"
        xmlns:jms="http://cxf.apache.org/transports/jms"
@@ -220,21 +220,21 @@ Apache CXF -- CXF 2.x JMS configuration
 &lt;/beans&gt;
 </pre>
 </div></div><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-UsingWSDL.2">Using WSDL</h3><p>Service endpoint behaviors are configured using the optional <code><a shape="rect" class="external-link" href="http://jmsserver" rel="nofollow">jms:server</a></code> element. The <code><a shape="rect" class="external-link" href="http://jmsserver" rel="nofollow">jms:server</a></code> element is a child of the WSDL <code>port</code> element and has the following attributes:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Attribute</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>useMessageIDAsCorrealationID</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies whether JMS will use the message ID to correlate messages. The default is <code>false</code>.</p></td></tr><tr><td colspan="1" rowspan="1" class="con
 fluenceTd"><p><code>durableSubscriberName</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the name used to register a durable subscription.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>messageSelector</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the string value of a message selector to use. For more information on the syntax used to specify message <br clear="none" class="atl-forced-newline"> selectors, see the JMS 1.1 specification.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>transactional</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies whether the local JMS broker will create transactions around message processing. The default is <code>false</code>. Currently, this is not supported by the runtime.</p></td></tr></tbody></table></div><h2 id="CXF2.xJMSconfiguration(removedinCXF3)-JMSRuntimeConfiguration">JMS Runtime Configuration</h2>
 <p>In addition to configuring the externally visible aspects of your JMS endpoint, you can also configure aspects of its internal runtime behavior. There are three types of runtime configuration:</p><ul><li>Session pool configuration (common to both services and consumers)</li><li>Consumer specific configuration</li><li>Service specific configuration</li></ul><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-SessionPoolConfiguration">Session Pool Configuration</h3><p>You configure an endpoint's JMS session pool using the <code><a shape="rect" class="external-link" href="http://jmssessionPoolConfig" rel="nofollow">jms:sessionPoolConfig</a></code> element. This property allows you to set a high and low water mark for the number of JMS sessions an endpoint will keep pooled. The endpoint is guaranteed to maintain a pool of sessions equal to the low water mark and to never pool more sessions than specified by the high water mark.<br clear="none"> The <code><a shape="rect" class="external-lin
 k" href="http://jmssessionPool" rel="nofollow">jms:sessionPool</a></code> element's attributes, listed below, specify the high and low water marks for the endpoint's JMS session pool.</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Attribute</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>lowWaterMark</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the minimum number of JMS sessions pooled by the endpoint. The default is 20.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>highWaterMark</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the maximum number of JMS sessions pooled by the endpoint. The default is 500.</p></td></tr></tbody></table></div><p>The following example shows an example of configuring the session pool for a CXF JMS
  service endpoint.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>JMS Session Pool Configuration</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;jms:destination 
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;jms:destination 
    name="{http://cxf.apache.org/jms_endpit}HelloWorldJMSPort.jms-destination"&gt;
 ...
   &lt;jms:sessionPool lowWaterMark="10" highWaterMark="5000" /&gt;
 &lt;/jms:destination&gt;
 </pre>
 </div></div><p>The <code><a shape="rect" class="external-link" href="http://jmssessionPool" rel="nofollow">jms:sessionPool</a></code> element can also be used within a <code><a shape="rect" class="external-link" href="http://jmsconduit" rel="nofollow">jms:conduit</a></code>.</p><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-ConsumerSpecificRuntimeConfiguration">Consumer Specific Runtime Configuration</h3><p>The JMS consumer configuration allows you to specify two runtime behaviors:</p><ul><li>the number of milliseconds the consumer will wait for a response.</li><li>the number of milliseconds a request will exist before the JMS broker can remove it.</li></ul><p>You use the <code><a shape="rect" class="external-link" href="http://jmsclientConfig" rel="nofollow">jms:clientConfig</a></code> element to set JMS consumer runtime behavior. This element's attributes, listed in the following table, specify the configuration values for consumer runtime behavior.</p><div class="table-wrap"><tabl
 e class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Attribute</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>clientReceiveTimeout</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the amount of time, in milliseconds, that the endpoint will wait for a response before it times out and issues an exception. The default value is 2000.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>messageTimeToLive</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the amount of time, in milliseconds, that a request can remain unrecieved before the JMS broker can delete it. The default value is 0 which specifies that the message can never be deleted.</p></td></tr></tbody></table></div><p>The following example shows a configuration fragment that sets the consumer endpoint's request lifetime 
 to 500 milliseconds and its timeout value to 500 milliseconds.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>JMS Consumer Endpoint Runtime Configuration</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;jms:conduit name="{http://cxf.apache.org/jms_endpt}HelloWorldJMSPort.jms-conduit"&gt;
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;jms:conduit name="{http://cxf.apache.org/jms_endpt}HelloWorldJMSPort.jms-conduit"&gt;
 ...
   &lt;jms:clientConfig clientReceiveTimeout="500"
                     messageTimeToLive="500" /&gt;
 &lt;/jms:conduit&gt;
 </pre>
 </div></div><h3 id="CXF2.xJMSconfiguration(removedinCXF3)-ServiceSpecificRuntimeConfiguration">Service Specific Runtime Configuration</h3><p>The JMS service configuration allows you to specify to runtime behaviors:</p><ul><li>the amount of time a response message can remain unreceived before the JMS broker can delete it.</li><li>the client identifier used when creating and accessing durable subscriptions.</li></ul><p>The <code><a shape="rect" class="external-link" href="http://jmsserverConfig" rel="nofollow">jms:serverConfig</a></code> element is used to specify the service runtime configuration. This element's attributes, listed below, specify the configuration values that control the service's runtime behavior.</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Attribute</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><c
 ode>messageTimeToLive</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the amount of time, in milliseconds, that a response can remain unread before the JMS broker is allowed to delete it. The default is 0 which specifies that the message can live forever.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>durableSubscriptionClientId</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the client identifier the endpoint uses to create and access durable subscriptions.</p></td></tr></tbody></table></div><p>The following example shows a configuration fragment that sets the service endpoint's response lifetime to 500 milliseconds and its durable subscription client identifier to <code>jms-test-id</code>.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>JMS Service Endpoint Runtime Configuration</b></div><div class="codeContent
  panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;jms:destination id="{http://cxf.apache.org/jms_endpt}HelloWorldJMSPort.jms-destination"&gt;
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;jms:destination id="{http://cxf.apache.org/jms_endpt}HelloWorldJMSPort.jms-destination"&gt;
   &lt;jms:address ... &gt;
     ...
   &lt;/jms:address&gt;

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 Wed Sep 13 15:05:52 2017
@@ -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.rbtoc1505311230758 {padding: 0px;}
-div.rbtoc1505311230758 ul {list-style: outline;margin-left: 0px;}
-div.rbtoc1505311230758 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1505314941124 {padding: 0px;}
+div.rbtoc1505314941124 ul {list-style: outline;margin-left: 0px;}
+div.rbtoc1505314941124 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1505311230758">
+/*]]>*/</style></p><div class="toc-macro rbtoc1505314941124">
 <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&amp;Interceptors">Messaging &amp; 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>
@@ -134,13 +134,13 @@ div.rbtoc1505311230758 li {margin-left:
 
 
 
-<span class="gliffy-container" id="gliffy-container-25591945-3741" 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-1842" data-fullwidth="1269" data-ceoid="44806" data-edit="${diagramEditLink.getLinkUrl()}" data-full="${diagramZoomLink.getLinkUrl()}" data-filename="MessageFlowOnClientSide">
 
-    <map id="gliffy-map-25591945-1563" name="gliffy-map-25591945-1563"></map>
+    <map id="gliffy-map-25591945-9232" name="gliffy-map-25591945-9232"></map>
 
-    <img class="gliffy-image" id="gliffy-image-25591945-3741" 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&amp;modificationDate=1298215366000&amp;api=v2" alt="MessageFlowOnClientSide" usemap="#gliffy-map-25591945-1563">
+    <img class="gliffy-image" id="gliffy-image-25591945-1842" 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&amp;modificationDate=1298215366000&amp;api=v2" alt="MessageFlowOnClientSide" usemap="#gliffy-map-25591945-9232">
 
-    <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591945-3741" name="gliffy-dynamic-map-25591945-3741"></map>
+    <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591945-1842" name="gliffy-dynamic-map-25591945-1842"></map>
 </span>
 
 
@@ -149,18 +149,18 @@ div.rbtoc1505311230758 li {margin-left:
 
 
 
-<span class="gliffy-container" id="gliffy-container-25591953-3149" 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-6810" data-fullwidth="1222" data-ceoid="44806" data-edit="${diagramEditLink.getLinkUrl()}" data-full="${diagramZoomLink.getLinkUrl()}" data-filename="MessageFlowOnServerSide">
 
-    <map id="gliffy-map-25591953-553" name="gliffy-map-25591953-553"></map>
+    <map id="gliffy-map-25591953-2558" name="gliffy-map-25591953-2558"></map>
 
-    <img class="gliffy-image" id="gliffy-image-25591953-3149" 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&amp;modificationDate=1298310696000&amp;api=v2" alt="MessageFlowOnServerSide" usemap="#gliffy-map-25591953-553">
+    <img class="gliffy-image" id="gliffy-image-25591953-6810" 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&amp;modificationDate=1298310696000&amp;api=v2" alt="MessageFlowOnServerSide" usemap="#gliffy-map-25591953-2558">
 
-    <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591953-3149" name="gliffy-dynamic-map-25591953-3149"></map>
+    <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591953-6810" name="gliffy-dynamic-map-25591953-6810"></map>
 </span>
 
 
 </p><p>Server Side</p><h3 id="CXFArchitecture-Front-ends">Front-ends</h3><p>Front-ends provide a programming model to interact with CXF. JAX-WS, JAX-RS, Simple and Javascript front-end APIs are provided by CXF . Each implementation is cleanly separated from the rest of CXF, just like the bindings and the core. Front-ends provide functionality through interceptors that are added to Services and Endpoints. See also <a shape="rect" href="frontends.html">Front-ends</a></p><h3 id="CXFArchitecture-Messaging&amp;Interceptors">Messaging &amp; Interceptors</h3><p>CXF is built on a generic messaging layer comprised of Messages, Interceptors, and InterceptorChains. Interceptors are the fundamental unit of functionality. By dividing up how messages are processed and sent, this gives CXF a very flexible architecture. It can be reconfigured at any point in the processing. This also gives CXF the ability to pause &amp; resume interceptor chains.</p><p>Interceptors have a method, <code>handleMessag
 e</code>, which allows them to act on the Message.These Interceptors can then be built up into chains of interceptors, straightforwardly called InterceptorChains. Some examples include:</p><ul><li>An interceptor which parses just the headers of a SOAP message into DOM elements</li><li>A WS-Security interceptor which decrypts or authenticates an incoming message.</li><li>An outgoing data binding interceptor which serializes the result</li></ul><p>Interceptors are uni-directional and are inherently unaware of whether they are dealing with a request, response, or fault.</p><h4 id="CXFArchitecture-PhaseInterceptors">Phase Interceptors</h4><p>CXF provides an <code>InterceptorChain</code> implementation called the <code>PhaseInterceptorChain</code>. When Interceptors are added to the chain, they are grouped into ordered phases.&#160; A <code>PhaseInterceptor</code> may provide guidance as to how it is to be ordered within the phase.</p><p>Let us take a hypothetical simplified example (NOT
 E: these phases and interceptors don't necessarily exist in CXF). Let us say we are parsing a SOAP message. We may want to have two phases. First, a dispatch phase which parses the soap headers and determines which service to route the Message to. Second, an unmarshal phase which binds the SOAP body to JAXB objects. In the first dispatch phase we could implement this via two interceptors, first a ReadHeadersInterceptor which parses the headers and second a WS-AddressingInInterceptor which determines which service we're invoking from the WS-Addressing header. In the second unmarshal phase, we have just a single JAXBUnmarshallerIntercptor. Both the <code>ReadHeadersInterceptor</code> and <code>AddressingInInterceptor</code> would tell the <code>PhaseInterceptorChain</code> they are in the "dispatch" phase by returning "dispatch" when <code>getPhase()</code> is called. Additionally, the <code>ReadHeadersInterceptor</code> could specify that it wants to run before the <code>AddressingIn
 Interceptor</code> by returning the interceptor id when <code>Interceptor.getBefore()</code> is called.</p><p>Before it was mentioned how chains were very dynamic and flexible. In our above example, we could add interceptors specific to that service once it is resolved. Or we could pause the chain once while we wait for some external chain, like an asynchronous service response.</p><h4 id="CXFArchitecture-FaultHandling">Fault Handling</h4><p>At any point during processing, an interceptor may throw a Fault, or a derivative of a Fault like the <code>SoapFault</code>. This will cause the chain to stop invoking and unwind it. Unwinding consists of calling handleFault on each interceptor that was invoked in reverse order.</p><p>InterceptorChains have the concept of a fault observer. Once the chain is unwound, the fault interceptor is invoked with the message that caused the fault. The fault observer may trigger a new chain which then invokes a specified set of interceptors meant to handl
 e faults.</p><h4 id="CXFArchitecture-Exchanges">Exchanges</h4><p>In addition to the concept of a Message, there is the concept of the <code>Exchange</code>. The exchange class holds a references to the in, out and fault messages for the current message exchange.</p><p>It also holds properties specific to the exchange, and not just the message. For instance the <code>Exchange</code> holds the <code>Service</code> that is current being invoked in it.</p><h4 id="CXFArchitecture-ReentrantInterceptorChains">Reentrant InterceptorChains</h4><p>An interesting feature of the <code>PhaseInterceptorChain</code> is that it is reentrant. This can be powerful and slightly dangerous. This feature is only used in CXF during the sending of an outgoing message, The <code>SoapOutInterceptor</code> is the best example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">public void handleMessage(Message m) {
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">public void handleMessage(Message m) {
   writeSoapEnvelopeStart();
   writeSoapBodyStart();
 
@@ -172,11 +172,11 @@ div.rbtoc1505311230758 li {margin-left:
 }
 </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">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">Set&lt;URI&gt; getRoles();
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">Set&lt;URI&gt; getRoles();
 Set&lt;QName&gt; getUnderstoodHeaders();
 </pre>
 </div></div><p>These inform the SOAP interceptors as to what headers and roles the particular SOAP interceptor understands.</p><p>It has many interceptors designed to handle SOAP messages:</p><ol><li><code>StaxInInterceptor</code>: Creates an <code>XMLStreamReader</code> from an incoming <code>InputStream</code></li><li><code>ReadHeadersInterceptor</code>: Reads the headers into the <code>SoapMessage</code></li><li><code>MustUnderstandInterceptor</code>: Checks the <code>MustUnderstand</code> attributes of all the headers against all the <code>SoapInterceptor</code>'s <code>getUnderstoodHeaders</code> method.</li><li><code>SoapOutInterceptor</code>:</li></ol><h4 id="CXFArchitecture-AdditionalBindings">Additional Bindings</h4><p>Other bindings include REST/HTTP binding, pure XML binding, and the CORBA binding.</p><h3 id="CXFArchitecture-Transports">Transports</h3><p>CXF includes its own transport abstraction layer to hide transport specific details from the binding and front end laye
 rs. Currently supported transports include: HTTP, HTTPs, HTTP-Jetty, HTTP-OSGI, Servlet, local, JMS, In-VM and many others via the Camel transport for CXF such as SMTP/POP3, TCP and Jabber. Learn more about transports <a shape="rect" href="http://cxf.apache.org/docs/transports.html">here</a>.</p><h4 id="CXFArchitecture-Conduits">Conduits</h4><p>Conduits provide the basis for outgoing message sending. A <code>Conduit</code> is created from a <code>ConduitInitiator</code>. Sending a message is a multistep pocess:</p><ol><li>Call conduit.prepare(message): this starts the message sending. At this point a <code>Conduit</code> may initiate a connection and set the OutputStream for the outgoing message.</li><li>Writing of the actual message to the <code>OutputStream</code></li><li>Call to <code>conduit.close(message)</code>: this closes and disposes of any existing resources for the message sending.<br clear="none"> A message sender may also register a <code>MessageObserver</code> with the
  Conduit. If the <code>Conduit</code> is synchronous, the <code>MessageObserver</code> will be notified once a response has been received.</li></ol><h4 id="CXFArchitecture-Destinations">Destinations</h4><p>Destinations are the basis for receiving incoming messages. A destination is created from a <code>DestinationFactory</code>:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">DestinationFactoryManager dfManager = bus.getExtension(DestinationFactoryManager.class);
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">DestinationFactoryManager dfManager = bus.getExtension(DestinationFactoryManager.class);
 
 // Find a DestinationFactory for the SOAP HTTP transport
 DestinationFactory df = dfManager.getDestinationFactory("http://schemas.xmlsoap.org/wsdl/soap/http");
@@ -186,7 +186,7 @@ EndpointInfo endpointInfo = ...;
 Destination destination = df.getDestination(endpointInfo);
 </pre>
 </div></div><p>MessageObservers can then be registered with Destinations. These listen for incoming messages:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">MessageObserver myObserver = ...;
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">MessageObserver myObserver = ...;
 destination.setMessageObserver(myObserver);
 </pre>
 </div></div><p>The most common <code>MessageObserver</code> used in CXF is the <code>ChainInitiationObserver</code>. This takes the incoming message, creates a message Exchange &amp; <code>PhaseInterceptorChain</code>, then starts the chain.</p><h3 id="CXFArchitecture-AJAX-WSexample">A JAX-WS example</h3><p>Here's a small example of what might happen when we publish a service via the JAX-WS <code>Endpoint.publish()</code> method.</p><ol><li>Call to <code>Endpoint.publish("http://localhost/service", myService)</code></li><li>The <code>EndpointImpl</code> creates a Service from the <code>myService</code> object using the <code>JaxWsServiceFactoryBean</code> using the class and/or WSDL</li><li>An <code>EndpointInfo</code> is created for the <code>Endpoint.publish</code> URL</li><li>A <code>JaxWsEndpointImpl</code> is created from the <code>EndpointInfo</code>. This contains the JAX-WS endpoint specific interceptors</li><li>The <code>JaxWsEndpointImpl</code> creates a <code>Binding</cod
 e> and <code>Destination</code> to listen on.</li></ol><h2 id="CXFArchitecture-Dependencies">Dependencies</h2><p><a shape="rect" href="http://cxf.apache.org/docs/cxf-dependency-graphs.html">CXF's dependencies</a></p><h2 id="CXFArchitecture-Quality">Quality</h2><p>CXF's Software Quality approach is detailed <a shape="rect" href="http://cxf.apache.org/coding-guidelines.html">here</a>.</p><h3 id="CXFArchitecture-References">References</h3><ul><li><a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Software_architecture" rel="nofollow">Software Architecture</a>, <em>Wikipedia</em></li><li><a shape="rect" class="external-link" href="http://www.ecs.csun.edu/~rlingard/COMP684/Example2SoftArch.htm#Logical%20View" rel="nofollow">Sample S/W Architecture Document</a>, <em>Rational Software Corporation</em></li><li><a shape="rect" class="external-link" href="http://www.oreillynet.com/xml/blog/2006/03/documenting_your_software_arch.html" rel="nofollow">Documenting your Softw
 are Architecture</a>, <em>by Jim Alateras</em> (March 2006)</li></ul></div>

Modified: websites/production/cxf/content/docs/cxf-oauth-10.html
==============================================================================
--- websites/production/cxf/content/docs/cxf-oauth-10.html (original)
+++ websites/production/cxf/content/docs/cxf-oauth-10.html Wed Sep 13 15:05:52 2017
@@ -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/shBrushJava.js'></script>
 <script src='/resources/highlighter/scripts/shBrushBash.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
   SyntaxHighlighter.all();
@@ -138,7 +138,7 @@ Apache CXF -- CXF OAuth 1.0
 
 <p>Configuration is exatcly this same as for every JAX-RS service:</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 &lt;!-- Publish OAuth endpoints--&gt;
 &#160;&#160; &#160;&lt;jaxrs:server id="oauthServer" address="/oauth/"&gt;
 &#160;&#160; &#160; &#160; &#160;&lt;jaxrs:serviceBeans&gt;
@@ -166,7 +166,7 @@ Apache CXF -- CXF OAuth 1.0
 <p>To make that transparent to the developers, CXF uses:</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 org.apache.cxf.auth.oauth.provider.OAuthDataProvider
 </pre>
 </div></div>
@@ -174,7 +174,7 @@ org.apache.cxf.auth.oauth.provider.OAuth
 
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 org.apache.cxf.auth.oauth.provider.MemoryOauthDataProvider
 </pre>
 </div></div>
@@ -182,7 +182,7 @@ org.apache.cxf.auth.oauth.provider.Memor
 <p>that is located in core OAuth module and&#160;</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 org.apache.cxf.auth.oauth.demo.server.oauth.SampleOAuthDataProvider
 </pre>
 </div></div>
@@ -226,7 +226,7 @@ Client need to attach access token with
 <p>OAuthSecurityFilter</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 org.apache.cxf.auth.oauth.interceptors.OAuthSecurityFilter
 </pre>
 </div></div>
@@ -245,14 +245,14 @@ org.apache.cxf.auth.oauth.interceptors.O
 
 <p>The only thing that needs to be done is adding</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 org.apache.cxf.auth.oauth.integration.spring.security.SpringOAuthAuthenticationFilter
 </pre>
 </div></div>
 <p>configuration in web.xml file <strong>following</strong> OAuthSecurityFilter. SpringOAuthAuthenticationFilter initializes SpringSecurityContext and allows to benefit from Spring Security framework.<br clear="none">
 Sample JAX-RS service could looks like:</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 @Path("/")
 public class SampleResourceProvider {
 

Modified: websites/production/cxf/content/docs/data-binding-architecture.html
==============================================================================
--- websites/production/cxf/content/docs/data-binding-architecture.html (original)
+++ websites/production/cxf/content/docs/data-binding-architecture.html Wed Sep 13 15:05:52 2017
@@ -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/shBrushJava.js'></script>
 <script src='/resources/highlighter/scripts/shBrushBash.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
   SyntaxHighlighter.all();
@@ -138,7 +138,7 @@ Apache CXF -- Data Binding Architecture
 <p>Each data binding supports one or more formats for the data in transit. A 'format' is a Java representation of XML. CXF works, primarily, with STaX. Thus, all data bindings must support XMLStreamReader and XMLStreamWriter as formats. Some interceptors expect to be able to read or write DOM Nodes. Thus, new data bindings should also support this format. Data bindings advertise their supported data formats via their implementation of two functions from DataBinding, e.g.:</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
    public Class&lt;?&gt;[] getSupportedReaderFormats() {
         return new Class[] {XMLStreamReader.class, Node.class};
     }
@@ -153,7 +153,7 @@ Apache CXF -- Data Binding Architecture
 
 <p>All the work of mapping is done by objects that implement DataReader&lt;Format&gt; and DataWriter&lt;Format&gt;, where 'Format' is a representation class as defined above. CXF code obtains readers and writers from data binding objects via </p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 &lt;T&gt; DataReader&lt;T&gt; createReader(Class&lt;T&gt; cls); 
 &lt;T&gt; DataWriter&lt;T&gt; createWriter(Class&lt;T&gt; cls);
 </pre>
@@ -161,7 +161,7 @@ Apache CXF -- Data Binding Architecture
 
 <p>Such a call might look like:</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 DataReader&lt;XMLStreamReader&gt; reader = binding.createReader(XMLStreamReader.class);
 </pre>
 </div></div>

Modified: websites/production/cxf/content/docs/debugging-and-logging.html
==============================================================================
--- websites/production/cxf/content/docs/debugging-and-logging.html (original)
+++ websites/production/cxf/content/docs/debugging-and-logging.html Wed Sep 13 15:05:52 2017
@@ -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/shBrushJava.js'></script>
 <script src='/resources/highlighter/scripts/shBrushBash.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
   SyntaxHighlighter.all();
@@ -118,7 +118,7 @@ Apache CXF -- Debugging and Logging
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><ul class="childpages-macro"><li><a shape="rect" href="general-cxf-logging.html">General CXF Logging</a></li><li><a shape="rect" href="message-logging.html">Message Logging</a></li><li><a shape="rect" href="old-message-logging.html">Old Message Logging</a></li><li><a shape="rect" href="atom-logging.html">ATOM Logging</a></li></ul><h1 id="DebuggingandLogging-DebuggingTools">Debugging Tools</h1><h2 id="DebuggingandLogging-EclipseIDE">Eclipse IDE</h2><p>See this <a shape="rect" class="external-link" href="https://web-gmazza.rhcloud.com/blog/entry/eclipse-debug-web-services" rel="nofollow">blog entry</a> for information on debugging web services using Eclipse. Note this is primarily for tracing/debugging source code; you will probably still want to use one of the tools below to capture network traffic, view SOAP requests and responses, etc.</p><h2 id="DebuggingandLogging-NetBeansIDE">NetBeans IDE</h2><p>NetBeans include a <a shape="rect" class="external-link"
  href="http://www.netbeans.org/features/java/debugger.html" rel="nofollow">debugger</a>,&#160;profiler, and an HTTP monitor that can assist in troubleshooting SOA applications.</p><h2 id="DebuggingandLogging-tcpmonplus">tcpmonplus</h2><p><a shape="rect" class="external-link" href="https://sourceforge.net/projects/tcpmonplus/" rel="nofollow">tcpmonplus</a> allows you to easily view messages as they go back and forth on the wire.</p><h2 id="DebuggingandLogging-WSMonitor">WSMonitor</h2><p><a shape="rect" class="external-link" href="https://java.net/projects/wsmonitor/sources/svn/show/trunk/wsmonitor?rev=97" rel="nofollow">WSMonitor</a> in another option to Tcpmon with slightly more functionality.</p><h2 id="DebuggingandLogging-NetSniffer">NetSniffer</h2><p><a shape="rect" class="external-link" href="http://www.miray.de/products/sat.netsniffer.html" rel="nofollow">NetSniffer</a> makes it possible to track the network traffic between arbitrary devices within a LAN segment.</p><h2 id="Deb
 uggingandLogging-Wireshark">Wireshark</h2><p><a shape="rect" class="external-link" href="http://www.wireshark.org/" rel="nofollow">Wireshark</a>, a network packet analyzer, is useful for following the routing of SOAP messages. It can also help when you are getting an HTML error message from the server that your CXF client cannot normally process, by allowing you to see the non-SOAP error message.</p><h2 id="DebuggingandLogging-SOAPUI">SOAP UI</h2><p><a shape="rect" class="external-link" href="http://soapui.org" rel="nofollow">SOAP UI</a> can also be used for debugging. In addition to viewing messages, it allows you send messages and load test your services. It also has plugins for the <a shape="rect" class="external-link" href="http://soapui.org/IDE-Plugins/eclipse-plugin.html" rel="nofollow">Eclipse IDE</a>, <a shape="rect" class="external-link" href="http://www.soapui.org/IDE-Plugins/netbean.html" rel="nofollow">NetBeans IDE</a> and <a shape="rect" class="external-link" href="http
 ://www.soapui.org/IDE-Plugins/intellij.html" rel="nofollow">IntelliJ IDEA</a>.</p><h1 id="DebuggingandLogging-OtherHelpfulTools">Other Helpful Tools</h1><h2 id="DebuggingandLogging-WSDLViewer">WSDL Viewer</h2><p><a shape="rect" class="external-link" href="http://tomi.vanek.sk/index.php?page=wsdl-viewer" rel="nofollow">WSDL Viewer</a> is a small tool to visualize web-services in a more intuitive way.</p><h1 id="DebuggingandLogging-SOAPFaultfordebugging">SOAP Fault for debugging</h1><h2 id="DebuggingandLogging-Stacktraceinfaultdetails">Stack trace in fault details</h2><p>CXF supports the ability to put server stack trace information into the fault message fault details, if you enable the option of 'faultStackTraceEnabled'. It is useful for debugging if the soap fault message is not defined in the WSDL operation.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;jaxws:endpoint id="server" address="http://localhost:9002/TestMessage" 
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;jaxws:endpoint id="server" address="http://localhost:9002/TestMessage" 
    wsdlURL="ship.wsdl"
    endpointName="s:TestSoapEndpoint"
    serviceName="s:TestService"
@@ -129,7 +129,7 @@ Apache CXF -- Debugging and Logging
 &lt;/jaxws:endpoint&gt;
 </pre>
 </div></div><h2 id="DebuggingandLogging-Showingthecauseexceptionmessage">Showing the cause exception message</h2><p>CXF doesn't show the cause exception message in the fault message due to security consideration. However, this could potentially cause some trouble on the client side, as the client will not be able to see what the real cause of the exception is. You can let the CXF server return the fault message with the embedded cause exception message by enabling the option of 'exceptionMessageCauseEnabled' like this:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;jaxws:endpoint id="server" address="http://localhost:9002/TestMessage" 
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">&lt;jaxws:endpoint id="server" address="http://localhost:9002/TestMessage" 
    wsdlURL="ship.wsdl"
    endpointName="s:TestSoapEndpoint"
    serviceName="s:TestService"

Modified: websites/production/cxf/content/docs/defining-contract-first-webservices-with-wsdl-generation-from-java.html
==============================================================================
--- websites/production/cxf/content/docs/defining-contract-first-webservices-with-wsdl-generation-from-java.html (original)
+++ websites/production/cxf/content/docs/defining-contract-first-webservices-with-wsdl-generation-from-java.html Wed Sep 13 15:05:52 2017
@@ -32,9 +32,9 @@
 <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/shBrushJava.js'></script>
-<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
 <script src='/resources/highlighter/scripts/shBrushBash.js'></script>
+<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
   SyntaxHighlighter.all();
@@ -136,7 +136,7 @@ Apache CXF -- Defining Contract first we
 <h3 id="DefiningContractfirstwebserviceswithwsdlgenerationfromjava-Customerdatatype">Customer datatype</h3>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 package com.example.customerservice;
 
 @XmlAccessorType( XmlAccessType.FIELD )
@@ -157,7 +157,7 @@ public class Customer {
 
 <p>Shows how enumerations are handled:</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 package com.example.customerservice;
 
 public enum CustomerType {
@@ -170,7 +170,7 @@ public enum CustomerType {
 
 <p>&#160;Defining Exceptions is a little tricky as the default behaviour is to create Exception_Exception classes in the later generated Java code. So we have to use the @WebFault annotation to give the Bean for the data a name that is separate from the Exception name.</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 package com.example.customerservice;
 
 @WebFault(name="NoSuchCustomer")
@@ -188,7 +188,7 @@ public class NoSuchCustomerException ext
 <h3 id="DefiningContractfirstwebserviceswithwsdlgenerationfromjava-Servicedefinition">Service definition</h3>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 package com.example.customerservice;
 
 @WebService
@@ -208,7 +208,7 @@ public interface CustomerService {
 
 <p>You can <a shape="rect" href="defining-contract-first-webservices-with-wsdl-generation-from-java.data/CustomerService.wsdl?version=2&amp;modificationDate=1219326152000&amp;api=v2" data-linked-resource-id="59672633" data-linked-resource-version="2" data-linked-resource-type="attachment" data-linked-resource-default-alias="CustomerService.wsdl" data-linked-resource-content-type="application/wsdl+xml" data-linked-resource-container-id="93162" data-linked-resource-container-version="15">download the wsdl this example creates here</a>.</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 &lt;xs:complexType name="customer"&gt;
     &lt;xs:sequence&gt;
         &lt;xs:element minOccurs="0" name="name" type="xs:string"/&gt;
@@ -232,7 +232,7 @@ public interface CustomerService {
 
 <p>The enumeration customerType is described as a simple type with a restriction:</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 &lt;xs:simpleType name="customerType"&gt;
     &lt;xs:restriction base="xs:string"&gt;
         &lt;xs:enumeration value="PRIVATE"/&gt;
@@ -246,7 +246,7 @@ public interface CustomerService {
 
 <p>The Exception we defined is generated as a complexType with the defined details and a message for the fault. It is important here that the Element and the Message have different names. We ensure this by using the @Webfault Annotation above. Else the later Java Code generation will produce an ugly Exception name NoSuchCustomerException_Exception.</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
 &lt;xs:element name="NoSuchCustomer" type="tns:NoSuchCustomer"/&gt;
 &lt;xs:complexType name="NoSuchCustomer"&gt;
     &lt;xs:sequence&gt;



Mime
View raw message