cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dk...@apache.org
Subject svn commit: r1018074 [23/31] - in /websites/production/cxf/content: ./ 2008/04/28/ 2008/06/20/ 2008/10/23/ 2009/02/10/ 2009/08/04/ cache/ docs/
Date Tue, 12 Sep 2017 19:09:50 GMT
Modified: websites/production/cxf/content/docs/servlet-transport.html
==============================================================================
--- websites/production/cxf/content/docs/servlet-transport.html (original)
+++ websites/production/cxf/content/docs/servlet-transport.html Tue Sep 12 19:09:41 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/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
   SyntaxHighlighter.all();
@@ -118,7 +118,7 @@ Apache CXF -- Servlet Transport
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><h1 id="ServletTransport-Settingupyourweb.xml">Setting up your web.xml</h1><p>To create services that use this transport you can either use the CXF APIs (for example, see <a shape="rect" href="developing-a-service.html">JAX-WS</a>) or create an XML file which registers services for you.</p><h2 id="ServletTransport-PublishinganendpointfromXML">Publishing an endpoint from XML</h2><p>CXF uses <a shape="rect" href="configuration.html">Spring</a> to provide XML configuration of services. This means that first we'll want to load Spring via a Servlet listener and tell it where our XML configuration file is:</p><p>Next, you'll need to add CXFServlet to your web.xml:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt;
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt;
 &lt;!DOCTYPE web-app
     PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
     "http://java.sun.com/dtd/web-app_2_3.dtd"&gt;
@@ -153,7 +153,7 @@ Apache CXF -- Servlet Transport
 &lt;/web-app&gt;
 </pre>
 </div></div><p>Alternatively, you can point to the configuration file using a CXFServlet init parameter :</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt;
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;?xml version="1.0" encoding="ISO-8859-1"?&gt;
 &lt;!DOCTYPE web-app
     PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
     "http://java.sun.com/dtd/web-app_2_3.dtd"&gt;
@@ -180,7 +180,7 @@ Apache CXF -- Servlet Transport
 &lt;/web-app&gt;
 </pre>
 </div></div><p>The next step is to actually write the configuration file:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:jaxrs="http://cxf.apache.org/jaxrs"
@@ -208,7 +208,7 @@ Apache CXF -- Servlet Transport
 &lt;/beans&gt;
 </pre>
 </div></div><p>Here we're creating a JAX-WS endpoint based on our implementation class, GreeterImpl.</p><p><strong>NOTE:</strong> We're publishing endpoints "http://localhost/mycontext/services/Greeter1" and "http://localhost/mycontext/services/GreeterRest", but we set jaxws:endpoint/@address and jaxrs:server/@address to relative values such as "/Greeter1" "/GreeterRest".</p><h2 id="ServletTransport-SupportforAsynchronousRequests">Support for Asynchronous Requests</h2><p>Enable an 'async-supported' servlet property if you work with Servlet3 API containers and need to support asynchronous requests:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;servlet&gt;
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;servlet&gt;
     &lt;servlet-name&gt;CXFServlet&lt;/servlet-name&gt;
     &lt;display-name&gt;CXF Servlet&lt;/display-name&gt;
     &lt;servlet-class&gt;
@@ -223,7 +223,7 @@ Apache CXF -- Servlet Transport
 &lt;/servlet&gt;
 </pre>
 </div></div><h2 id="ServletTransport-Redirectingrequestsandservingthestaticcontent">Redirecting requests and serving the static content</h2><p>Starting from CXF 2.2.5 it is possible to configure CXFServlet to redirect current requests to other servlets or serve the static resources.</p><p>"redirects-list" init parameter can be used to provide a space separated list of URI patterns; if a given request URI matches one of the patterns then CXFServlet will try to find a RequestDispatcher using the pathInfo of the current HTTP request and will redirect the request to it.</p><p>"redirect-servlet-path" can be used to affect a RequestDispatcher lookup, if specified then it will concatenated with the pathInfo of the current request.</p><p>"redirect-servlet-name" init parameter can be used to enable a named RequestDispatcher look-up, after one of the URI patterns in the "redirects-list" has matched the current request URI.</p><p>"static-resources-list" init parameter can be used to provide a 
 space separated list of static resource such as html, css, or pdf files which CXFServlet will serve directly.</p><p>One can have requests redirected to other servlets or JSP pages.</p><p>CXFServlets serving both JAXWS and JAXRS based endpoints can avail of this feature.</p><p>For example, please see this <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/resources/jaxrs_dispatch/WEB-INF/web.xml">web.xml</a>.</p><p>The "http://localhost:9080/the/bookstore1/books/html/123" request URI will initially be matched by the CXFServlet given that it has a more specific URI pattern than the RedirectCXFServlet. After a current URI has reached a jaxrs:server endpoint, the response will be redirected by the JAXRS <a shape="rect" href="http://cxf.apache.org/docs/jax-rs.html#JAX-RS-WithRequestDispatcherProvider">RequestDispatcherProvider</a> to a "/book.html" address, see "dispatchProvider1" bean <a shape="rect" class="external-link" href="
 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=systests/jaxrs/src/test/resources/jaxrs_dispatch/WEB-INF/web.xml;h=a2212337bd6a9ed7a212b21a6826850581601121;hb=HEAD">here</a>.</p><p>Next, the request URI "/book.html" will be handled by RedirectCXFServlet. Note that a uri pattern can be a regular expression. This servlet redirects the request further to a RequestDispatcher capable of handling a "/static/book.html".</p><p>Finally, DefaultCXFServlet serves a requested book.html.</p><h2 id="ServletTransport-Servingwelcomepages">Serving welcome pages</h2><p>Starting from CXF 2.5.5 and 2.6.2 it is possible to configure CXFServlet to serve welcome pages in a number of ways.</p><p>For example, lets assume we have a web application called "webapp" which has a root resource called "index.html". For CXFServlet to support both "/webapp" and "/webapp/index.html" requests returning "index.html", while letting all other requests to proceed to the actual endpoints, the following can be do
 ne.</p><p>Option1. Delegating to Default Servlet</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;servlet&gt;
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;servlet&gt;
    &lt;servlet-name&gt;CXFServlet&lt;/servlet-name&gt;
    &lt;display-name&gt;CXF Servlet&lt;/display-name&gt;
    &lt;servlet-class&gt;
@@ -259,7 +259,7 @@ Apache CXF -- Servlet Transport
 &lt;/welcome-file-list&gt;
 </pre>
 </div></div><p>Note that the redirects-list parameter has two space separated values, "/" and "index.html". The request attribute 'javax.servlet.include.request_uri' might need to be set for the underlying container like Jetty to successfully read "index.html".</p><p>Option2. Using CXFServlet itself to read index.html</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;servlet&gt;
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;servlet&gt;
    &lt;servlet-name&gt;CXFServlet&lt;/servlet-name&gt;
    &lt;display-name&gt;CXF Servlet&lt;/display-name&gt;
    &lt;servlet-class&gt;
@@ -281,7 +281,7 @@ Apache CXF -- Servlet Transport
 &lt;/servlet-mapping&gt;
 </pre>
 </div></div><h2 id="ServletTransport-PublishinganendpointwiththeAPI">Publishing an endpoint with the API</h2><p>Once your Servlet is registered in your web.xml, you should set the default bus with CXFServlet's bus to make sure that CXF uses it as its HTTP Transport. Simply publish with the related path "Greeter" and your service should appear at the address you specify:</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;">import javax.xml.ws.Endpoint;
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">import javax.xml.ws.Endpoint;
 import org.apache.cxf.Bus;
 import org.apache.cxf.BusFactory;
 import org.apache.cxf.transport.servlet.CXFServlet;
@@ -293,7 +293,7 @@ BusFactory.setDefaultBus(bus);
 Endpoint.publish("/Greeter", new GreeterImpl());
 </pre>
 </div></div><p>The one thing you must ensure is that your CXFServlet is set up to listen on that path. Otherwise the CXFServlet will never receive the requests.</p><p><strong>NOTE:</strong></p><p>Endpoint.publish(...) is a JAX-WS API for publishing JAX-WS endpoints. Thus, it would require the JAX-WS module and APIs to be present. If you are not using JAX-WS or want more control over the published endpoint properties, you should replace that call with the proper calls to the appropriate ServerFactory.</p><p>Since CXFServlet know nothing about the web container listening port and the application context path, you need to specify the relative path instead of the full http address.</p><h2 id="ServletTransport-UsingtheservlettransportwithoutSpring">Using the servlet transport without Spring</h2><p>A user who doesn't want to touch any Spring stuff could also publish the endpoint with CXF servlet transport. First you should extend the CXFNonSpringServlet and then override the method loadBu
 s, e.g.:</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;">import javax.xml.ws.Endpoint;
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">import javax.xml.ws.Endpoint;
 ...  
   
     @Override
@@ -314,7 +314,7 @@ Endpoint.publish("/Greeter", new Greeter
     }
 </pre>
 </div></div><p>If you are using the Jetty as the embedded servlet engine, you could publish endpoint like this:</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;">import javax.xml.ws.Endpoint;
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">import javax.xml.ws.Endpoint;
 ...
 
         // Setup the system properties to use the CXFBusFactory not the SpringBusFactory
@@ -356,11 +356,11 @@ Endpoint.publish("/Greeter", new Greeter
         }
 </pre>
 </div></div><h2 id="ServletTransport-AccessingtheMessageContextand/orHTTPRequestandResponse">Accessing the MessageContext and/or HTTP Request and Response</h2><p>Sometimes you'll want to access more specific message details in your service implementation. One example might be accessing the actual request or response object itself. This can be done using the WebServiceContext object.</p><p>First, declare a private field for the <a shape="rect" class="external-link" href="http://java.sun.com/javase/6/docs/api/javax/xml/ws/WebServiceContext.html" rel="nofollow">WebServiceContext</a> in your service implementation, and annotate it as a resource:</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;">@Resource
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">@Resource
 private WebServiceContext context;
 </pre>
 </div></div><p>Then, within your implementing methods, you can access the MessageContext, HttpServletRequest, and HttpServletResponse as follows:</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;">import javax.servlet.http.HttpServletRequest;
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.HttpServletResponse;
 import javax.xml.ws.handler.MessageContext;
 import org.apache.cxf.transport.http.AbstractHTTPDestination;

Modified: websites/production/cxf/content/docs/simple-frontend-configuration.html
==============================================================================
--- websites/production/cxf/content/docs/simple-frontend-configuration.html (original)
+++ websites/production/cxf/content/docs/simple-frontend-configuration.html Tue Sep 12 19:09:41 2017
@@ -119,7 +119,7 @@ Apache CXF -- Simple Frontend Configurat
 <div id="ConfluenceContent"><h1 id="SimpleFrontendConfiguration-ConfigurewithSpringforthesimplefrontendserver">Configure with Spring for the simple front end server</h1>
 <p>You can configure the CXF simple front end server endpoint by using the &lt;simple:server&gt; tag in spring. </p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:simple="http://cxf.apache.org/simple"
@@ -147,7 +147,7 @@ http://cxf.apache.org/simple http://cxf.
 
 <p>Here is a more advanced example which shows how to provide interceptors and properties:</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:simple="http://cxf.apache.org/simple"
@@ -187,7 +187,7 @@ http://cxf.apache.org/simple http://cxf.
 <h1 id="SimpleFrontendConfiguration-ConfigurewithSpringforthesimplefrontendclient">Configure with Spring for the simple front end client</h1>
 <p>You could use the &lt;simple:client&gt; element to configure the simple front end client, you can use the spring's getBean API to get the client instance from the application context.</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:simple="http://cxf.apache.org/simple"
@@ -217,7 +217,7 @@ http://cxf.apache.org/simple http://cxf.
 
 <p>Here is a more advanced example which shows how to provide interceptors and properties:</p>
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:simple="http://cxf.apache.org/simple"

Modified: websites/production/cxf/content/docs/simple-frontend.html
==============================================================================
--- websites/production/cxf/content/docs/simple-frontend.html (original)
+++ websites/production/cxf/content/docs/simple-frontend.html Tue Sep 12 19:09:41 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/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
   SyntaxHighlighter.all();
@@ -146,7 +146,7 @@ Apache CXF -- Simple Frontend
 
 <p>First you'll want to create your service class:</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;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 public interface HelloWorld {
   String sayHi(String text);
 }
@@ -158,7 +158,7 @@ public interface HelloWorld {
 
 <p>We'll also need an implementation class:</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;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 public class HelloWorldImpl implements HelloWorld {
   public String sayHi(String text) {
     return "Hello " + text;
@@ -169,7 +169,7 @@ public class HelloWorldImpl implements H
 
 <p>And now we'll want to create a Server from this</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;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 import org.apache.cxf.frontend.ServerFactoryBean;
 ...
 
@@ -191,7 +191,7 @@ svrFactory.create();
 <p>You'll also want to create a client for your service. CXF includes a ClientProxyFactoryBean which will create a Java proxy for you from your interface which will invoke the service.</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;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 import demo.hw.server.HelloWorld;
 import org.apache.cxf.frontend.ClientProxyFactoryBean;
 ...
@@ -214,7 +214,7 @@ own application context.</p>
 <p>Here's an example cxf-servlet.xml with simple front end endpoint configuration. If you use your own application context, you'll need to import the soap extension and http servlet extension. </p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:simple="http://cxf.apache.org/simple"

Modified: websites/production/cxf/content/docs/soap-11.html
==============================================================================
--- websites/production/cxf/content/docs/soap-11.html (original)
+++ websites/production/cxf/content/docs/soap-11.html Tue Sep 12 19:09:41 2017
@@ -32,6 +32,7 @@
 <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>
   SyntaxHighlighter.defaults['toolbar'] = false;
@@ -140,7 +141,7 @@ Apache CXF -- SOAP 1.1
 <p>If your system had an interface that took orders and offered a single operation to process the orders it would be defined in a WSDL document similar to the one shown below.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Ordering System Interface</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;definitions name="widgetOrderForm.wsdl"
     targetNamespace="http://widgetVendor.com/widgetOrderForm"
@@ -176,7 +177,7 @@ Apache CXF -- SOAP 1.1
 <p>The SOAP binding generated for orderWidgets is shown below.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Binding for orderWidgets</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;binding name="orderWidgetsBinding" type="tns:orderWidgets"&gt;
   &lt;soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/&gt;
     &lt;operation name="placeWidgetOrder"&gt;
@@ -208,7 +209,7 @@ Apache CXF -- SOAP 1.1
 <p>The syntax for defining a SOAP header is shown in <strong>SOAP Header Syntax</strong>. The <code>message</code> attribute of <code>soap:header</code> is the qualified name of the message from which the part being inserted into the header is taken. The <code>part</code> attribute is the name of the message part inserted into the SOAP header. Because SOAP headers are always document style, the WSDL message part inserted into the SOAP header must be defined using an element. Together the message and the part attributes fully describe the data to insert into the SOAP header.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>SOAP Header Syntax</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;binding name="headwig"&gt;
   &lt;soap:binding style="document"
                 transport="http://schemas.xmlsoap.org/soap/http"/&gt;
@@ -238,7 +239,7 @@ Apache CXF -- SOAP 1.1
 <p><strong>SOAP 1.1 Binding with a SOAP Header</strong> shows a modified version of the orderWidgets service shown in <strong>Ordering System Interface</strong>. This version has been modified so that each order has an <code>xsd:base64binary</code> value placed in the SOAP header of the request and response. The SOAP header is defined as being the <code>keyVal</code> part from the <code>widgetKey</code> message. In this case you would be responsible for adding the SOAP header in your application logic because it is not part of the input or output message.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>SOAP 1.1 Binding with a SOAP Header</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;definitions name="widgetOrderForm.wsdl"
     targetNamespace="http://widgetVendor.com/widgetOrderForm"
@@ -303,7 +304,7 @@ Apache CXF -- SOAP 1.1
 <p>You could modify <strong>SOAP 1.1 Binding with a SOAP Header</strong> so that the header value was a part of the input and output messages as shown in <strong>SOAP 1.1 Binding for orderWidgets with a SOAP Header</strong>. In this case <code>keyVal</code> is a part of the input and output messages. In the <code>soap:body</code> element's parts attribute specifies that <code>keyVal</code> is not to be inserted into the body. However, it is inserted into the SOAP header.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>SOAP 1.1 Binding for orderWidgets with a SOAP Header</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;definitions name="widgetOrderForm.wsdl"
     targetNamespace="http://widgetVendor.com/widgetOrderForm"

Modified: websites/production/cxf/content/docs/soap-12.html
==============================================================================
--- websites/production/cxf/content/docs/soap-12.html (original)
+++ websites/production/cxf/content/docs/soap-12.html Tue Sep 12 19:09:41 2017
@@ -32,6 +32,7 @@
 <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>
   SyntaxHighlighter.defaults['toolbar'] = false;
@@ -140,7 +141,7 @@ Apache CXF -- SOAP 1.2
 <p>If your system had an interface that took orders and offered a single operation to process the orders it would be defined in a WSDL fragment similar to the one shown in <strong>Ordering System Interface</strong>.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Ordering System Interface</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;definitions name="widgetOrderForm.wsdl"
     targetamespace="http://widgetVendor.com/widgetOrderForm"
@@ -176,7 +177,7 @@ Apache CXF -- SOAP 1.2
 <p>The SOAP binding generated for orderWidgets is shown in <strong>SOAP 1.2 Binding for orderWidgets</strong>.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>SOAP 1.2 Binding for orderWidgets</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;binding name="orderWidgetsBinding" type="tns:orderWidgets"&gt;
   &lt;wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/&gt;
     &lt;operation name="placeWidgetOrder"&gt;
@@ -208,7 +209,7 @@ Apache CXF -- SOAP 1.2
 <p>The syntax for defining a SOAP header is shown in <strong>SOAP 1.2 Header Syntax</strong>.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>SOAP 1.2 Header Syntax</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;binding name="headwig"&gt;
   &lt;wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/&gt;
     &lt;operation name="weave"&gt;
@@ -243,7 +244,7 @@ Apache CXF -- SOAP 1.2
 <p><strong>SOAP 1.2 Binding with a SOAP Header</strong> shows a modified version of the orderWidgets service shown in <strong>Ordering System Interface</strong>. This version has been modified so that each order has an <code>xsd:base64binary</code> value placed in the header of the request and response. The header is defined as being the keyVal part from the widgetKeymessage. In this case you would be responsible for adding the application logic to create the header because it is not part of the input or output message.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>SOAP 1.2 Binding with a SOAP Header</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;definitions name="widgetOrderForm.wsdl"
     targetNamespace="http://widgetVendor.com/widgetOrderForm"
@@ -308,7 +309,7 @@ Apache CXF -- SOAP 1.2
 <p>You could modify <strong>SOAP 1.2 Binding with a SOAP Header</strong> so that the header value was a part of the input and output messages as shown in <strong>SOAP 1.2 Binding for orderWidgets with a SOAP Header</strong>. In this case keyVal is a part of the input and output messages. In the <code>wsoap12:body</code> elements the <code>parts</code> attribute specifies that keyVal is not to be inserted into the body. However, it is inserted into the header.</p>
 
 <div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>SOAP 1.2 Binding for orderWidgets with a SOAP Header</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">
 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;definitions name="widgetOrderForm.wsdl"
     targetNamespace="http://widgetVendor.com/widgetOrderForm"

Modified: websites/production/cxf/content/docs/soap-over-jms-10-support.html
==============================================================================
--- websites/production/cxf/content/docs/soap-over-jms-10-support.html (original)
+++ websites/production/cxf/content/docs/soap-over-jms-10-support.html Tue Sep 12 19:09:41 2017
@@ -32,8 +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/shBrushBash.js'></script>
 <script src='/resources/highlighter/scripts/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
 <script src='/resources/highlighter/scripts/shBrushPlain.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
@@ -119,16 +120,16 @@ Apache CXF -- SOAP over JMS 1.0 support
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p>The <a shape="rect" href="jms-transport.html">JMS Transport</a> offers an alternative messaging mechanism to SOAP over HTTP. SOAP over JMS offers more reliable and scalable messaging support than SOAP over HTTP. The <a shape="rect" class="external-link" href="http://www.w3.org/TR/soapjms/" rel="nofollow">SOAP over JMS specification</a> is aimed at a set of standards for the transport of SOAP messages over JMS. Its main purpose is to ensure interoperability between the implementations of different Web services vendors. CXF supports and is compliant with this specification.</p><h2 id="SOAPoverJMS1.0support-SOAPoverJMSNamespace">SOAP over JMS Namespace</h2><h3 id="SOAPoverJMS1.0support-JMSURI">JMS URI</h3><p>JMS endpoints need to know the address information for establishing connections to the proper destination. SOAP over JMS implements the <a shape="rect" class="external-link" href="http://tools.ietf.org/id/draft-merrick-jms-uri-06.txt" rel="nofollow">U
 RI Scheme for Java Message Service 1.0</a>.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>JMS URI Scheme</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: text; gutter: false; theme: Default" style="font-size:12px;">jms:&lt;variant&gt;:&lt;destination name&gt;?param1=value1&amp;param2=value2</pre>
+<pre class="brush: text; gutter: false; theme: Confluence" style="font-size:12px;">jms:&lt;variant&gt;:&lt;destination name&gt;?param1=value1&amp;param2=value2</pre>
 </div></div><h3 id="SOAPoverJMS1.0support-Variants">Variants</h3><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh">Prefix</th><th colspan="1" rowspan="1" class="confluenceTh">Description</th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><strong>jndi</strong></td><td colspan="1" rowspan="1" class="confluenceTd">Destination name is a jndi queue name</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><strong>jndi-topic</strong></td><td colspan="1" rowspan="1" class="confluenceTd">Destination name is a jndi topic name</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><strong>queue</strong></td><td colspan="1" rowspan="1" class="confluenceTd">Destination is a queue name resolved using JMS</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><strong>topic</strong></td><td colspan="1" rowspan="1" class="confluenceTd">Destination is a topic name resolved using JMS</td></tr></tbody></
 table></div><p>Further parameters can be added as query parameters in the URI.</p><p>For example:</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;">jms:jndi:SomeJndiNameForDestination?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&amp;jndiURL=tcp://localhost:61616&amp;priority=3
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">jms:jndi:SomeJndiNameForDestination?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&amp;jndiURL=tcp://localhost:61616&amp;priority=3
 jms:queue:ExampleQueueName?timeToLive=1000
 </pre>
 </div></div><h3 id="SOAPoverJMS1.0support-JMSparameters">JMS parameters</h3><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Query Parameter</p></th><th colspan="1" rowspan="1" class="confluenceTh">From <br clear="none">Version</th><th colspan="1" rowspan="1" class="confluenceTh"><p>DefaultValue</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">conduitIdSelectorPrefix</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">If set then this string will be the prefix for all correlation ids the conduit creates and also be used in the selector for listening to replies</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>deliveryMode</p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td co
 lspan="1" rowspan="1" class="confluenceTd"><p>PERSISTENT</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>NON_PERSISTENT messages will kept only in memory <br clear="none"> PERSISTENT messages will be saved to disk</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">durableSubscriptionClientId</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.1</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">Optional Client identifier for the connection. The purpose is to associate a connection with a state maintained on behalf of the client by a provider. The only such state identified by the JMS API is that required to support durable subscriptions.</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">durableSubscriptionName</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"
 >&#160;</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>jndiConnectionFactoryName</p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p>ConnectionFactory</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>jndiInitialContextFactory</p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the fully qualified Java class name of the "InitialContextFactory" implementation class to use.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">jndiTransactionManagerName</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rowspan="1" class="confluenceTd">
 &#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p>Name of the JTA TransactionManager. Will be searched in spring, blueprint and jndi.<br clear="none"> If a transaction manager is found then JTA transactions will be enabled. See details below.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>jndiURL</p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the JNDI provider URL</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">jndi-*</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">Additional parameters for a JNDI provider</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">messageType</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rows
 pan="1" class="confluenceTd">byte</td><td colspan="1" rowspan="1" class="confluenceTd">JMS message type used by CXF (byte, text or binary)</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">password</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">Password for creating the connection. Using this in the URI is discouraged</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">priority</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rowspan="1" class="confluenceTd">4</td><td colspan="1" rowspan="1" class="confluenceTd">Priority for the messages. See your JMS provider documentation for details. Values range from 0 to 9 where 0 is lowest priority</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>replyToName</p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" c
 lass="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies the JNDI name bound to the JMS destinations where replies are sent</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">receiveTimeout</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rowspan="1" class="confluenceTd">60000</td><td colspan="1" rowspan="1" class="confluenceTd">Timeout in milliseconds the client waits for a reply in case of request / repy exchanges</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">reconnectOnException</td><td colspan="1" rowspan="1" class="confluenceTd"><p>deprecated</p><p>in 3.0.0</p></td><td colspan="1" rowspan="1" class="confluenceTd">true</td><td colspan="1" rowspan="1" class="confluenceTd">Should the transport reconnect in case of exceptions. From version 3.0.0 on the transport will always reconnect in case of exceptions</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">sessionTransa
 cted</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rowspan="1" class="confluenceTd">false</td><td colspan="1" rowspan="1" class="confluenceTd">Set to true for resource local transactions. Do not set if you use JTA</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>timeToLive</p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p>0</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Time (in ms) after which the message will be discarded by the jms provider</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">topicReplyToName</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">Reply to messages on a topic with this name. Depending on the variant this is either&#160; a jndi or jms name.</td></tr><tr><td colspan="1" rowspan="1" class="co
 nfluenceTd">useConduitIdSelector</td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rowspan="1" class="confluenceTd">true</td><td colspan="1" rowspan="1" class="confluenceTd"><p>Each conduit is assigned with a UUID. If set to true this conduit id will be the prefix for all correlation ids. This allows several endpoints to</p><p>share a JMS queue or topic</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>username</p></td><td colspan="1" rowspan="1" class="confluenceTd">3.0.0</td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Username for creating the connection</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">concurrentConsumers</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">1</td><td colspan="1" rowspan="1" class="confluenceTd">Number of consumers listening queue concurrently</td></tr
 ></tbody></table></div><p>Some of these attributes are specified in the <a shape="rect" class="external-link" href="http://tools.ietf.org/id/draft-merrick-jms-uri-06.txt" rel="nofollow">JMS URI specification</a>.</p><h2 id="SOAPoverJMS1.0support-WSDLExtension">WSDL Extension</h2><p>The WSDL extensions for defining a JMS endpoint use a special namespace. In order to use the JMS WSDL 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="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">xmlns:soapjms="http://www.w3.org/2010/soapjms/"
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">xmlns:soapjms="http://www.w3.org/2010/soapjms/"
 </pre>
 </div></div><p>Various JMS properties may be set in three places in the WSDL &#8212; the binding, the service, and the port. Values specified at the service will propagate to all ports. Values specified at the binding will propagate to all ports using that binding. <br clear="none"> For example, if the <strong>jndiInitialContextFactory</strong> is indicated for a service, it will be used for all of the port elements it contains.</p><p>JMS Properties. For details refer to the URI query parameters with the same name:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Name</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>deliveryMode</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>jndiConnectionFactoryName</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>jndiInitialContextFactory</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>jndiURL</
 p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>replyToName</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>priority</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>timeToLive</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>jndiContextParameter</p></td></tr></tbody></table></div><p>Here is an example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Ways to define a Service with JMS transport</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;wsdl11:binding name="exampleBinding"&gt;
+<pre class="brush: xml; gutter: false; theme: Confluence" style="font-size:12px;">&lt;wsdl11:binding name="exampleBinding"&gt;
   &lt;soapjms:jndiContextParameter name="name" value="value" /&gt;
   &lt;soapjms:jndiConnectionFactoryName&gt;ConnectionFactory&lt;/soapjms:jndiConnectionFactoryName&gt;
   &lt;soapjms:jndiInitialContextFactory&gt;org.apache.activemq.jndi.ActiveMQInitialContextFactory&lt;/soapjms:jndiInitialContextFactory&gt;
@@ -150,7 +151,7 @@ jms:queue:ExampleQueueName?timeToLive=10
 &lt;/wsdl11:service&gt;
 </pre>
 </div></div><p>If a property is specified at multiple levels, the setting at the most granular level takes precedence (port first, then service, then binding). In the above example, notice the timeToLive property &#8212; for the quickPort port, the value will be 10ms (specified at the port level). For the slowPort port, the value will be 100ms (specified at the service level). In this example, the setting in the binding will always be overridden.</p><h2 id="SOAPoverJMS1.0support-WSDLUsage">WSDL Usage</h2><p>For this example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Greeter Service with JMS transaport</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;wsdl:definitions name="JMSGreeterService"  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://cxf.apache.org/jms_greeter" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:x1="http://cxf.apache.org/jms_greeter/types" xmlns:soapjms="http://www.w3.org/2010/soapjms/" name="JMSGreeterService" targetNamespace="http://cxf.apache.org/jms_greeter"&gt;
+<pre class="brush: xml; gutter: false; theme: Confluence" style="font-size:12px;">&lt;wsdl:definitions name="JMSGreeterService"  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://cxf.apache.org/jms_greeter" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:x1="http://cxf.apache.org/jms_greeter/types" xmlns:soapjms="http://www.w3.org/2010/soapjms/" name="JMSGreeterService" targetNamespace="http://cxf.apache.org/jms_greeter"&gt;
     ...
 	&lt;wsdl:binding name="JMSGreeterPortBinding" type="tns:JMSGreeterPortType"&gt;
 		&lt;soap:binding style="document" transport="http://www.w3.org/2010/soapjms/" /&gt;
@@ -181,7 +182,7 @@ jms:queue:ExampleQueueName?timeToLive=10
 &lt;/wsdl:definitions&gt;
 </pre>
 </div></div><ul><li>The transport URI (<a shape="rect" class="external-link" href="http://www.w3.org/2010/soapjms/" rel="nofollow">http://www.w3.org/2010/soapjms/</a>) is defined in the &lt;soap:binding&gt;.</li><li>The jms: URI is defined in the &lt;soap:address&gt;</li><li>The extension properties are in the &lt;soap:binding&gt;</li></ul><h2 id="SOAPoverJMS1.0support-Defineserviceendpointorproxyinspringorblueprint">Define service endpoint or proxy in spring or blueprint</h2><p>The JAXWS endpoint or proxy can be defined like in the SOAP/HTTP case. Just use a jms: uri like described above.</p><p>In CXF 3 it is possible to omit the jndi settings. Just specify an endpoint like this:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Endpoint in spring</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;bean id="ConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"&gt;
+<pre class="brush: xml; gutter: false; theme: Confluence" style="font-size:12px;">&lt;bean id="ConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"&gt;
   &lt;property name="brokerURL" value="tcp://localhost:61616"/&gt;
 &lt;/bean&gt;
 &lt;jaxws:endpoint id="CustomerService"
@@ -189,7 +190,7 @@ jms:queue:ExampleQueueName?timeToLive=10
   implementor="com.example.customerservice.impl.CustomerServiceImpl"&gt;
 &lt;/jaxws:endpoint&gt;</pre>
 </div></div><p>or a Client like this:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Proxy in spring</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;bean id="ConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"&gt;
+<pre class="brush: xml; gutter: false; theme: Confluence" style="font-size:12px;">&lt;bean id="ConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"&gt;
   &lt;property name="brokerURL" value="tcp://localhost:61616"/&gt;
 &lt;/bean&gt;
 &lt;jaxws:client id="CustomerService"
@@ -197,7 +198,7 @@ jms:queue:ExampleQueueName?timeToLive=10
   serviceClass="com.example.customerservice.CustomerService"&gt;
 &lt;/jaxws:client&gt;</pre>
 </div></div><p>The connection factory will be looked up as a bean in the context. By default the name "ConnectionFactory" is assumed but it can be configured using the jndiConnectionFactoryName uri parameter.</p><p>Alternatively the connection factory can be set using the ConnectionFactoryFeature.</p><h2 id="SOAPoverJMS1.0support-PublishingaservicewiththeJAVAAPI">Publishing a service with the JAVA API</h2><p>Developers who don't wish to modify the WSDL file can also publish the endpoint information using Java code. For CXF's SOAP over JMS implementation you can write the following:</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;">  // You just need to set the address with JMS URI
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">  // You just need to set the address with JMS URI
   String address = "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue3"
       + "?jndiInitialContextFactory"
       + "=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
@@ -217,7 +218,7 @@ jms:queue:ExampleQueueName?timeToLive=10
   ep.getFeatures().add(new ConnectionFactoryFeature(cf));
   ep.publish("jms:queue:test.cxf.jmstransport.queue?timeToLive=1000");</pre>
 </div></div><p>NOTE: For tests it can be useful to create an embedded broker like this:</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;">    public final void run() {
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">    public final void run() {
         try {             
             broker = new BrokerService();
             broker.setPersistent(false);
@@ -235,7 +236,7 @@ jms:queue:ExampleQueueName?timeToLive=10
     }
 </pre>
 </div></div><h2 id="SOAPoverJMS1.0support-ConsumetheservicewiththeAPI">Consume the service with the API</h2><p>Sample code to consume a SOAP-over-JMS service is as follows:</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;">    public void invoke() throws Exception {
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">    public void invoke() throws Exception {
         // You just need to set the address with JMS URI
         String address = "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue3"
             + "?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
@@ -257,7 +258,7 @@ jms:queue:ExampleQueueName?timeToLive=10
   ConnectionFactoryFeature cff = new ConnectionFactoryFeature(cf);
   Greeter greeter = service.getPort(portName, Greeter.class, cff); // Connection Factory can be set as a feature in CXF &gt;= 3.0.0 </pre>
 </div></div><p>If you specify queue or topic as variant and use cxf &gt;= 3.0.0 then the jndi settings are not necessary.</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;">svrFactory.setAddress("jms:queue:test.cxf.jmstransport.queue?timeToLive=1000");
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">svrFactory.setAddress("jms:queue:test.cxf.jmstransport.queue?timeToLive=1000");
 // For CXF &gt;= 3.0.0
 svrFactory.setFeatures(Collections.singletonList(new ConnectionFactoryFeature(cf)));</pre>
 </div></div><p>In this case case the connection factory is supplied using a feature. For CXF 2.x the connection factory can only be supplied using jndi.</p><p>&#160;</p></div>

Modified: websites/production/cxf/content/docs/springboot.html
==============================================================================
--- websites/production/cxf/content/docs/springboot.html (original)
+++ websites/production/cxf/content/docs/springboot.html Tue Sep 12 19:09:41 2017
@@ -119,11 +119,11 @@ Apache CXF -- SpringBoot
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1505159705599 {padding: 0px;}
-div.rbtoc1505159705599 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1505159705599 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1505243006988 {padding: 0px;}
+div.rbtoc1505243006988 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1505243006988 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1505159705599">
+/*]]>*/</style></p><div class="toc-macro rbtoc1505243006988">
 <ul class="toc-indentation"><li><a shape="rect" href="#SpringBoot-SpringBootCXFJAX-WSStarter">Spring Boot CXF JAX-WS Starter</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#SpringBoot-Features">Features</a></li><li><a shape="rect" href="#SpringBoot-Setup">Setup</a></li><li><a shape="rect" href="#SpringBoot-AdditionalConfiguration">Additional Configuration</a></li><li><a shape="rect" href="#SpringBoot-APIDocumentation">API Documentation</a></li><li><a shape="rect" href="#SpringBoot-ServiceRegistryPublication">Service Registry Publication</a></li><li><a shape="rect" href="#SpringBoot-Examples">Examples</a></li></ul>
 </li><li><a shape="rect" href="#SpringBoot-SpringBootCXFJAX-RSStarter">Spring Boot CXF&#160;JAX-RS Starter</a>

Modified: websites/production/cxf/content/docs/standalone-http-transport.html
==============================================================================
--- websites/production/cxf/content/docs/standalone-http-transport.html (original)
+++ websites/production/cxf/content/docs/standalone-http-transport.html Tue Sep 12 19:09:41 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/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
 <script>
   SyntaxHighlighter.defaults['toolbar'] = false;
   SyntaxHighlighter.all();
@@ -118,7 +118,7 @@ Apache CXF -- Standalone HTTP Transport
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><h1 id="StandaloneHTTPTransport-ConfiguringSSL">Configuring SSL</h1><p>To configure the standalone HTTP transport to use SSL, you'll need to add an &lt;http:destination&gt; definition to your XML configuration file. See the <a shape="rect" href="configuration.html">Configuration</a> guide to learn how to supply your own XML configuration file to CXF. If you are already using Spring, this can be added to your existing beans definitions. For more information about configuring TLS, see the <a shape="rect" href="https://cwiki.apache.org/confluence/display/CXF20DOC/TLS+Configuration">Configuring TLS</a> page.</p><p>Destinations in CXF are responsible for listening for server side requests.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">&lt;beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:sec="http://cxf.apache.org/configuration/security"
   xmlns:http="http://cxf.apache.org/transports/http/configuration"
@@ -168,7 +168,7 @@ Apache CXF -- Standalone HTTP Transport
 &lt;/bean&gt; 
 </pre>
 </div></div><h1 id="StandaloneHTTPTransport-Addthestaticcontentpagesintothejettyserver">Add the static content pages into the jetty server</h1><p>The CXF standalone http transport is based on the jetty server. The code below shows how to get the jetty server from the destination and how to add the static content path to the jetty server.</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;">    // get the jetty server form the destination
+<pre class="brush: bash; gutter: false; theme: Confluence" style="font-size:12px;">    // get the jetty server form the destination
     EndpointInfo ei = new EndpointInfo();
     ei.setAddress(serviceFactory.getAddress());
     Destination destination = df.getDestination(ei);

Modified: websites/production/cxf/content/docs/standardized-authentication-authorization.html
==============================================================================
--- websites/production/cxf/content/docs/standardized-authentication-authorization.html (original)
+++ websites/production/cxf/content/docs/standardized-authentication-authorization.html Tue Sep 12 19:09:41 2017
@@ -117,7 +117,7 @@ Apache CXF -- Standardized Authenticatio
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p>&#160;</p><p>&#160;</p><p>&#160;</p><div class="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body">Ideas / Proposal</div></div><p>&#160;</p><p>CXF already supports a wide range of authentication and authorization approaches. Unfortunately they are all configured differently and do not integrate well with each other.</p><p>So the idea is to create one standardized authentication / authorization flow in CXF where the modules can then fit in. There are a lot of security frameworks out there that could be used as a basis for this. The problem is though that each framework&#160; (like Shiro or Spring Security) uses its own mechanisms which are not standardized. So by choosing one framework we would force our users to depend on this.</p><p>The best standardized security framework in java is JAAS. 
 It is already included in Java and most security frameworks can be hooked into it. So let&#180;s investigate what we could do with JAAS.</p><h2 id="StandardizedAuthentication/Authorization-AuthenticationusingJAAS">Authentication using JAAS</h2><p>JAAS authentication is done by creating a LoginContext and doing a login on it. Things to configure is the name of the login config and the Callback Handlers. So CXF needs mechanisms for the user to set the config name and needs to provide CallBackHandlers to supply credentials.</p><h2 id="StandardizedAuthentication/Authorization-CallbackHandlers">CallbackHandlers</h2><p>CXF needs to supply different data to identify the users depending on the chosen authentication variant.</p><p>Basic Auth: username and password from HTTP header</p><p>WS-Security UserNameToken: Username and password from SOAP header</p><p>Spnego: Kerberos token from HTTP header</p><p>HTTPS client cert: Certificate information</p><p>We could simply detect what information i
 s provided and configure the Callbackhandlers for each information we can supply. Depending on when the login should happen we could collect CallbackHandlers in the Message using Interceptors.</p><h2 id="StandardizedAuthentication/Authorization-JAASconfiguration">JAAS configuration</h2><p>The JAAS configuration is supplied differently depending on the runtime CXF runs in.</p><p>Standalone: For standalone usage the JAAS config can simply come from a file.</p><p>Servlet Container: Not sure. Is there a standard approach for this?</p><p>Apache Karaf: Karaf already provides a JAAS integration so we just have to configure the JAAS config name and supply a suitable config in karaf</p><h2 id="StandardizedAuthentication/Authorization-SupplyingRoleandUserinformation">Supplying Role and User information</h2><p>JAAS stores identity information in the JAAS subject. The method getPrincipals returns Principal objects which can be users, roles or even other identity information. To differentiate be
 tween roles and users there are two common approaches.</p><ol><li>different Classes like a UserPrincipal or RolePrincipal. There seems to be a Group interface which allows to differentiate between Users and Groups and also allows to see group members.</li><li>prefixes. So for example roles start with role- . There is no standard for this approach</li></ol><h2 id="StandardizedAuthentication/Authorization-Authorization">Authorization</h2><p>Authorization has very diverse requirements. So we need to make sure we integrate well with different approaches.</p><p>Generally the idea is to base the Authorization on the JAAS login data. After a JAAS login the JAAS subject can be retrieved in a standard way:</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;">AccessControlContext acc = AccesController.getContext();
+<pre class="brush: java; gutter: false; theme: Confluence" style="font-size:12px;">AccessControlContext acc = AccesController.getContext();
 Subject subject = Subject.getSubject(acc);</pre>
 </div></div><p>So the idea is that we provide certain default authorization variants that rely on the above to retrieve authentication information in a standardized way. So authorization is nicely decoupled from authentication and fully standards based.</p><p>This then also provides a nice interface for users or other frameworks to access authentication information and provide custom authorization variants.</p><h2 id="StandardizedAuthentication/Authorization-DefaultAuthorizationVariants">Default Authorization Variants</h2><h3 id="StandardizedAuthentication/Authorization-JEEannotations">JEE annotations</h3><p>Java EE provides some standard annotations like @RolesAllowed. We can provide an interceptor that reads the annotations of serivce impls and provides authorization like in a JEE container.</p><h3 id="StandardizedAuthentication/Authorization-XACMLPEP">XACML PEP</h3><p>An XACML policy enforcement point can retrieve the JAAS login data and do authorization against an XACML Policy D
 ecision Point (PDP).</p><h2 id="StandardizedAuthentication/Authorization-SeparatingAuthorizationfromCXF">Separating Authorization from CXF</h2><p>As authorization is not only relevant for webservices it makes sense to keep the authorization code separate from cxf too. So one way to implement authorization would be to put it into a blueprint extension. Of course this would cover only OSGi and blueprint but it would be a start.</p><p>It could work similar to the XA transaction support. Unlike in tx support we could scan all beans for security annotations like @RolesAllowed. Then for each bean that has this annotation we could proxy it with a class that does the security check. This would allow to have minimal xml configuration.</p><p>Another approach is to mark beans for security checks using xml like in tx support. This variant then would also work nicely for XACML authorization as in that case there would be no annotation to scan for.</p><h3 id="StandardizedAuthentication/Authorizat
 ion-KarafrolebasedOSGiserviceAuthorization">Karaf role based OSGi service Authorization</h3><p>Karaf 3 already supports authorization on the OSGi service level and uses JAAS for authentication. So if we do a JAAS login in CXF and the service impl code calls an OSGi service then the Karaf role based securtiy should already work out of the box.We could add annotation based Authorization to karaf code to make it even better and require less config.</p><h2 id="StandardizedAuthentication/Authorization-Exceptionhandlingandanswergeneration">Exception handling and answer generation</h2><p>Currently the authentication and athorization modules often also generate the answer to the caller. It might be a good idea to decouple this.</p><p>In the authentication and authorization we only throw a defined Exception:</p><ul><li>Failure at Authentication: javax.security.auth.login.LoginException could also be more specific like AccountLockedException</li><li>Failure at Authorization: org.apache.cxf.in
 terceptor.security.AccessDeniedException or java.security.AccessControlException. The later one is better for code separate from cxf as it does not depend on CXF.</li></ul><p>Then in the transport like the http transport we map the exception to the defined status code and http response:</p><ul><li>LoginException: HTTP Code 401</li><li>AccessDeniedException, AccessControlException: HTTP Code 403</li></ul><p>Unfortunately CXF currently does not handle the status code generation in the transport. The exception is already mapped into a Fault at PhaseInterceptorChain. The Fault then holds the statusCode which is by default 500. So one simple way to do the mapping isto map from exception type to fault code in the Fault constructor. This is not extensible but would do for the start.</p><h2 id="StandardizedAuthentication/Authorization-JAASFeature">JAAS Feature</h2><p>The JAAS feature needs some configuration like the jaas context name. So it makes sense to integrate it with config admin in 
 OSGi and publish it as an OSGi service. So we can keep the JAAS configuration centralized and keep it out of each bundle.</p><p>As long as the configs are very limited we could of course also integrate it in each bundles cxf bus. This would have the advantage that it also works outside OSGi.</p><h2 id="StandardizedAuthentication/Authorization-Authenticationactivation">Authentication activation</h2><p>Ideally we should integrate the new authentication / authorization model in a way that enable the user to switch on authentication for the karaf server without specific configurations in the user bundles that implement the services. One problem with this very loosely coupled approach is that switching on authentication would secure all services but perhaps some are expected to work without. The other problem is that the services might start before the auth module and then run unsecured.</p><p>So we need a way to mark services that need authentication. One existing way to do so is to bin
 d the auhorization Feature as an OSGi service and add it to the features "by hand". This is a bit verbose but on the other hand it is very clear what happens.</p><p>One other approach would be to publish the feature as a an OSGi service with a unique ID (which is already present for features). Then we could have a new Element for cxf:bus and endpoints like that:</p><p>&lt;namedFeatures&gt;authentication, xacmlAuthorization&lt;/namedFeatures&gt;</p><p>This Element would mean that cxf will only publish the endpoint once both of these named features are present and will add the features to the endpoint /bus.</p><h2 id="StandardizedAuthentication/Authorization-Problems">Problems</h2><p>Doing a full JAAS login requires to use subject.doAs to populate the AcessControlContext. This is not possible in a CXF interceptor as the interceptor only works on a message but can not call the next interceptor for doAs. So the question is where to do the JAAS login and the doAs?</p><h2 id="Standardized
 Authentication/Authorization-Links">Links</h2><p><a shape="rect" class="external-link" href="http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html" rel="nofollow">http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html</a></p></div>
            </div>

Modified: websites/production/cxf/content/docs/swagger2feature.html
==============================================================================
--- websites/production/cxf/content/docs/swagger2feature.html (original)
+++ websites/production/cxf/content/docs/swagger2feature.html Tue Sep 12 19:09:41 2017
@@ -118,11 +118,11 @@ Apache CXF -- Swagger2Feature
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><h1 id="Swagger2Feature-Swagger2Feature">Swagger2Feature</h1><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1505159704987 {padding: 0px;}
-div.rbtoc1505159704987 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1505159704987 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1505242917199 {padding: 0px;}
+div.rbtoc1505242917199 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1505242917199 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1505159704987">
+/*]]>*/</style></p><div class="toc-macro rbtoc1505242917199">
 <ul class="toc-indentation"><li><a shape="rect" href="#Swagger2Feature-Swagger2Feature">Swagger2Feature</a></li><li><a shape="rect" href="#Swagger2Feature-Setup">Setup</a></li><li><a shape="rect" href="#Swagger2Feature-Properties">Properties</a></li><li><a shape="rect" href="#Swagger2Feature-ConfiguringfromCode">Configuring from Code</a></li><li><a shape="rect" href="#Swagger2Feature-ConfiguringinSpring">Configuring in Spring</a></li><li><a shape="rect" href="#Swagger2Feature-ConfiguringinBlueprint">Configuring in Blueprint</a></li><li><a shape="rect" href="#Swagger2Feature-ConfiguringinCXFNonSpringJaxrsServlet">Configuring in CXFNonSpringJaxrsServlet</a></li><li><a shape="rect" href="#Swagger2Feature-New:ConfiguringfromPropertiesfile">New: Configuring from Properties file</a></li><li><a shape="rect" href="#Swagger2Feature-EnablinginSpringBoot">Enabling in Spring Boot</a></li><li><a shape="rect" href="#Swagger2Feature-AccessingSwaggerDocuments">Accessing Swagger Documents</a></li><l
 i><a shape="rect" href="#Swagger2Feature-EnablingSwaggerUI">Enabling Swagger UI</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#Swagger2Feature-AutomaticUIActivation">Automatic UI Activation</a></li><li><a shape="rect" href="#Swagger2Feature-UnpackingSwaggerUIresources">Unpacking Swagger UI resources</a></li></ul>
 </li><li><a shape="rect" href="#Swagger2Feature-ReverseProxy">Reverse Proxy</a></li><li><a shape="rect" href="#Swagger2Feature-SetaCXFServletinitparameter'use-x-forwarded-headers'to'true'ifyouaccessSwaggerJSONand/o">Set a CXFServlet init parameter 'use-x-forwarded-headers' to 'true' if you access Swagger JSON and/o</a></li><li><a shape="rect" href="#Swagger2Feature-Samples">Samples</a></li></ul>



Mime
View raw message