diff --git a/components/camel-cxf/camel-cxf-soap/src/main/docs/cxf-component.adoc b/components/camel-cxf/camel-cxf-soap/src/main/docs/cxf-component.adoc index 2d5f2a7f069ea..4849e66e833d6 100644 --- a/components/camel-cxf/camel-cxf-soap/src/main/docs/cxf-component.adoc +++ b/components/camel-cxf/camel-cxf-soap/src/main/docs/cxf-component.adoc @@ -20,8 +20,8 @@ hosted in CXF. [TIP] ==== -When using CXF in streaming modes (see DataFormat option), then also -read about Stream caching. +When using CXF in streaming mode - check the DataFormat options below, then also +read about xref:manual::stream-caching.adoc[stream caching]. ==== Maven users must add the following dependency to their `pom.xml` @@ -53,7 +53,7 @@ are specified in the bean definition. cxf://someAddress[?options] ---- -Where *someAddress* specifies the CXF endpoint's address. With this URI +Where `someAddress` specifies the CXF endpoint's address. With this URI format, most of the endpoint details are specified using options. For either style above, you can append options to the URI as follows: @@ -82,10 +82,10 @@ include::partial$component-endpoint-headers.adoc[] The `serviceName` and `portName` are http://en.wikipedia.org/wiki/QName[QNames], so if you provide them be -sure to prefix them with their \{namespace} as shown in the examples +sure to prefix them with their _\{namespace}_ as shown in the examples above. -=== Descriptions of the dataformats +=== Descriptions of the data formats In Apache Camel, the Camel CXF component is the key to integrating routes with Web services. You can use the Camel CXF component to create a CXF endpoint, which can be used in either of the following ways: @@ -104,10 +104,10 @@ handlers are supported. message configuration in the CXF endpoint is applied. Only Protocol JAX-WS handler is supported. Logical JAX-WS handler is not supported. -|`RAW` |`RAW` mode provides the raw message stream that is received from the transport layer. +|`RAW` |`RAW` mode provides the raw message stream received from the transport layer. It is not possible to touch or change the stream, some of the CXF interceptors will be removed if you are using this kind of DataFormat, so -you can't see any soap headers after the camel-cxf consumer. JAX-WS +you can't see any soap headers after the Camel CXF consumer. JAX-WS handler is not supported. Note that `RAW` mode is equivalent to deprecated `MESSAGE` mode. |`CXF_MESSAGE` |`CXF_MESSAGE` allows for invoking the full @@ -120,9 +120,9 @@ exchange property, `CamelCXFDataFormat`. The exchange key constant is defined in `org.apache.camel.component.cxf.common.message.CxfConstants.DATA_FORMAT_PROPERTY`. -== How to create simple CXF service with POJO data format +== How to create a simple CXF service with POJO data format -Having simple java web service interface +Having simple java web service interface: [source,java] @@ -136,7 +136,7 @@ public interface EchoService { } ---- -and implementation +And implementation: [source,java] ---- @@ -171,9 +171,9 @@ For more complicated implementation of the service (more "Camel way"), we can se ---- -== How to consume a message from a camel-cxf endpoint in POJO data format +== How to consume a message from a Camel CXF endpoint in POJO data format -The `camel-cxf` endpoint consumer POJO data format is based on the +The Camel CXF endpoint consumer POJO data format is based on the http://cxf.apache.org/docs/invokers.html[CXF invoker], so the message header has a property with the name of `CxfConstants.OPERATION_NAME` and the message body is a list of the SEI @@ -196,7 +196,7 @@ public class PersonProcessor implements Processor { if (boi != null) { LOG.info("boi.isUnwrapped" + boi.isUnwrapped()); } - // Get the parameters list which element is the holder. + // Get the parameter list which element is the holder. MessageContentsList msgList = (MessageContentsList) exchange.getIn().getBody(); Holder personId = (Holder) msgList.get(0); Holder ssn = (Holder) msgList.get(1); @@ -217,7 +217,7 @@ public class PersonProcessor implements Processor { name.value = "Bonjour"; ssn.value = "123"; LOG.info("setting Bonjour as the response"); - // Set the response message, first element is the return value of the operation, + // Set the response message, the first element is the return value of the operation, // the others are the holders of method parameters exchange.getMessage().setBody(new Object[] { null, personId, ssn, name }); } @@ -225,11 +225,11 @@ public class PersonProcessor implements Processor { } ---- -== How to prepare the message for the camel-cxf endpoint in POJO data format +== How to prepare the message for the Camel CXF endpoint in POJO data format -The `camel-cxf` endpoint producer is based on the -https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/endpoint/Client.java[CXF -client API]. First you need to specify the operation name in the message +The Camel CXF endpoint producer is based on the +https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/endpoint/Client.java[CXF client API]. +First, you need to specify the operation name in the message header, then add the method parameters to a list, and initialize the message with this parameter list. The response message's body is a messageContentsList, you can get the result from that list. @@ -255,9 +255,9 @@ senderExchange.getIn().setHeader(CxfConstants.OPERATION_NAME, ECHO_OPERATION); Exchange exchange = template.send("direct:EndpointA", senderExchange); org.apache.camel.Message out = exchange.getMessage(); -// The response message's body is an MessageContentsList which first element is the return value of the operation, +// The response message's body is a MessageContentsList which first element is the return value of the operation, // If there are some holder parameters, the holder parameter will be filled in the reset of List. -// The result will be extract from the MessageContentsList with the String class type +// The result will be extracted from the MessageContentsList with the String class type MessageContentsList result = (MessageContentsList) out.getBody(); LOG.info("Received output text: " + result.get(0)); Map responseContext = CastUtils.cast((Map) out.getHeader(Client.RESPONSE_CONTEXT)); @@ -267,7 +267,7 @@ assertEquals("UTF-8", responseContext.get(org.apache.cxf.message.Message.ENCODIN assertEquals("echo " + TEST_MESSAGE, result.get(0), "Reply body on Camel is wrong"); ---- -== How to consume a message from a camel-cxf endpoint in PAYLOAD data format +== How to consume a message from a Camel CXF endpoint in PAYLOAD data format `PAYLOAD` means that you process the payload from the SOAP envelope as a native CxfPayload. `Message.getBody()` will return a @@ -293,7 +293,7 @@ protected RouteBuilder createRouteBuilder() { String documentString = ECHO_RESPONSE; Element in = new XmlConverter().toDOMElement(inElements.get(0)); - // Just check the element namespace + // Check the element namespace if (!in.getNamespaceURI().equals(ELEMENT_NAMESPACE)) { throw new IllegalArgumentException("Wrong element namespace"); } @@ -318,21 +318,21 @@ protected RouteBuilder createRouteBuilder() { == How to get and set SOAP headers in POJO mode -`POJO` means that the data format is a "list of Java objects" when the -camel-cxf endpoint produces or consumes Camel exchanges. Even though -Camel exposes the message body as POJOs in this mode, camel-cxf still +`POJO` means that the data format is a _"list of Java objects"_ when the +Camel CXF endpoint produces or consumes Camel exchanges. Even though +Camel exposes the message body as POJOs in this mode, Camel CXF still provides access to read and write SOAP headers. However, since CXF -interceptors remove in-band SOAP headers from the header list after they +interceptors remove in-band SOAP headers from the header list, after they have been processed, only out-of-band SOAP headers are available to -camel-cxf in POJO mode. +Camel CXF in POJO mode. The following example illustrates how to get/set SOAP headers. Suppose we -have a route that forwards from one Camel-cxf endpoint to another. That -is, SOAP Client -> Camel -> CXF service. We can attach two processors to +have a route that forwards from one Camel CXF endpoint to another. That +is, `SOAP Client -> Camel -> CXF service`. We can attach two processors to obtain/insert SOAP headers at (1) before a request goes out to the CXF -service and (2) before the response comes back to the SOAP Client. Processor -(1) and (2) in this example are InsertRequestOutHeaderProcessor and -InsertResponseOutHeaderProcessor. Our route looks like this: +service and (2) before the response comes back to the SOAP Client. Processors +(1) and (2) in this example are `InsertRequestOutHeaderProcessor` and +`InsertResponseOutHeaderProcessor`. Our route looks like this: [tabs] ==== @@ -360,17 +360,16 @@ XML:: ==== SOAP headers are propagated to and from Camel Message headers. The Camel -message header name is "org.apache.cxf.headers.Header.list" which is a -constant defined in CXF (org.apache.cxf.headers.Header.HEADER_LIST). The -header value is a List of CXF SoapHeader objects -(org.apache.cxf.binding.soap.SoapHeader). The following snippet is the -InsertResponseOutHeaderProcessor (that insert a new SOAP header in the -response message). The way to access SOAP headers in both -InsertResponseOutHeaderProcessor and InsertRequestOutHeaderProcessor are -actually the same. The only difference between the two processors is -setting the direction of the inserted SOAP header. - -You can find the `InsertResponseOutHeaderProcessor` example in https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java#L731CxfMessageHeadersRelayTest]: +message header name is `org.apache.cxf.headers.Header.list` which is a +constant defined in CXF (`org.apache.cxf.headers.Header.HEADER_LIST`). The +header value is a List of CXF `SoapHeader` objects +(`org.apache.cxf.binding.soap.SoapHeader`). +The following snippet is the `InsertResponseOutHeaderProcessor` (that inserts a new SOAP header in the response message). The way to access SOAP headers in both +`InsertResponseOutHeaderProcessor` and `InsertRequestOutHeaderProcessor` are +actually the same. +The only difference between the two processors is setting the direction of the inserted SOAP header. + +You can find the `InsertResponseOutHeaderProcessor` example in https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java#L731[CxfMessageHeadersRelayTest]: [source,java] ---- @@ -386,7 +385,7 @@ public static class InsertResponseOutHeaderProcessor implements Processor { + "New_testOobHeaderNew_testOobHeaderValue"; SoapHeader newHeader = new SoapHeader(soapHeaders.get(0).getName(), DOMUtils.readXml(new StringReader(xml)).getDocumentElement()); - // make sure direction is OUT since it is a response message. + // make sure the direction is OUT since it is a response message. newHeader.setDirection(Direction.DIRECTION_OUT); //newHeader.setMustUnderstand(false); soapHeaders.add(newHeader); @@ -398,14 +397,14 @@ public static class InsertResponseOutHeaderProcessor implements Processor { == How to get and set SOAP headers in PAYLOAD mode -We've already shown how to access the SOAP message as CxfPayload object in -PAYLOAD mode in the section <>. +We've already shown how to access the SOAP message as `CxfPayload` object in +PAYLOAD mode in the section <>. -Once you obtain a CxfPayload object, you can invoke the -CxfPayload.getHeaders() method that returns a List of DOM Elements (SOAP +Once you obtain a `CxfPayload` object, you can invoke the +`CxfPayload.getHeaders()` method that returns a List of DOM Elements (SOAP headers). -For an example see https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-soap/src/test/java/org/apache/camel/component/cxf/jaxws/CxfPayLoadSoapHeaderTest.java#L53[CxfPayLoadSoapHeaderTest]: +For example, see https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-soap/src/test/java/org/apache/camel/component/cxf/jaxws/CxfPayLoadSoapHeaderTest.java#L53[CxfPayLoadSoapHeaderTest]: [source,java] ---- @@ -427,7 +426,7 @@ from(getRouterEndpointURI()).process(new Processor() { assertEquals(1, headers.size(), "Get the wrong headers size"); assertEquals("http://camel.apache.org/pizza/types", ((Element) (headers.get(0).getObject())).getNamespaceURI(), "Get the wrong namespace URI"); - // alternatively you can also get the SOAP header via the camel header: + // alternatively, you can also get the SOAP header via the camel header: headers = exchange.getIn().getHeader(Header.HEADER_LIST, List.class); assertNotNull(headers, "We should get the headers here"); assertEquals(1, headers.size(), "Get the wrong headers size"); @@ -441,15 +440,15 @@ from(getRouterEndpointURI()).process(new Processor() { ---- You can also use the same way as described in -sub-chapter "How to get and set SOAP headers in POJO mode" to set or get +subchapter "How to get and set SOAP headers in POJO mode" to set or get the SOAP headers. So, you can use the -header "org.apache.cxf.headers.Header.list" to get and set a list of +header `org.apache.cxf.headers.Header.list` to get and set a list of SOAP headers.This does also mean that if you have a route that forwards -from one Camel-cxf endpoint to another (SOAP Client -> Camel -> CXF -service), now also the SOAP headers sent by the SOAP client are +from one Camel CXF endpoint to another (`SOAP Client -> Camel -> CXF +service`), now also the SOAP headers sent by the SOAP client are forwarded to the CXF service. If you do not want that these headers are -forwarded you have to remove them in the Camel header -"org.apache.cxf.headers.Header.list". +forwarded, you have to remove them in the Camel header +`org.apache.cxf.headers.Header.list`. == SOAP headers are not available in RAW mode @@ -458,7 +457,7 @@ skipped. == How to throw a SOAP Fault from Camel -If you are using a `camel-cxf` endpoint to consume the SOAP request, you +If you are using a Camel CXF endpoint to consume the SOAP request, you may need to throw the SOAP Fault from the camel context. + Basically, you can use the `throwFault` DSL to do that; it works for `POJO`, `PAYLOAD` and `RAW` data format. + @@ -473,7 +472,7 @@ Text tn = doc.createTextNode(DETAIL_TEXT); detail.appendChild(tn); ---- -Then throw it as you like +Then throw it as you like: [source,java] ---- @@ -483,7 +482,7 @@ from(routerEndpointURI).setFaultBody(constant(SOAP_FAULT)); If your CXF endpoint is working in the `RAW` data format, you could set the SOAP Fault message in the message body and set the response -code in the message header as demonstrated by https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-soap/src/test/java/org/apache/camel/component/cxf/jaxws/CxfMessageStreamExceptionTest.java#L43[CxfMessageStreamExceptionTest] +code in the message header as demonstrated by https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-soap/src/test/java/org/apache/camel/component/cxf/jaxws/CxfMessageStreamExceptionTest.java#L43[CxfMessageStreamExceptionTest]: [source,java] ---- @@ -491,7 +490,7 @@ from(routerEndpointURI).process(new Processor() { public void process(Exchange exchange) throws Exception { Message out = exchange.getMessage(); - // Set the message body with the + // Set the message body out.setBody(this.getClass().getResourceAsStream("SoapFaultMessage.xml")); // Set the response code here out.setHeader(org.apache.cxf.message.Message.RESPONSE_CODE, new Integer(500)); @@ -500,15 +499,14 @@ from(routerEndpointURI).process(new Processor() { }); ---- -Same for using POJO data format. You can set the SOAPFault on the out -body. +Same for using POJO data format. You can set the SOAPFault on the _OUT_ body. [#propagate-request-response-context] -== How to propagate a camel-cxf endpoint's request and response context +== How to propagate a Camel CXF endpoint's request and response context -https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/endpoint/Client.java[CXF -client API] provides a way to invoke the operation with request and -response context. If you are using a `camel-cxf` endpoint producer to +https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/endpoint/Client.java[CXF client API] provides a way to invoke the operation with request and +response context. +If you are using a Camel CXF endpoint producer to invoke the outside web service, you can set the request context and get response context with the following code: @@ -539,18 +537,22 @@ assertEquals("Get the wrong wsdl operation name", "{http://apache.org/hello_worl == Attachment Support -*POJO Mode:* Message Transmission Optimization Mechanism (MTOM) is supported if is enabled (see -example in Payload Mode for enabling MTOM). Since attachments are -marshalled and unmarshalled into POJOs, the attachments should be -retrieved from Camel Message Body(As parameter list), and it isn't +=== POJO Mode + +Message Transmission Optimization Mechanism (MTOM) is supported if enabled - check +the example in Payload Mode for enabling MTOM. +Since attachments are marshalled and unmarshalled into POJOs, the attachments should be +retrieved from the Apache Camel message body (as a parameter list), and it isn't possible to retrieve attachments by Camel Message API [source,java] ---- -DataHandler Exchange.getIn(AttachmentMessage.class).getAttachment(String id) +DataHandler handler = Exchange.getIn(AttachmentMessage.class).getAttachment("id"); ---- -*Payload Mode:* Message Transmission Optimization Mechanism (MTOM) is supported by this Mode. +=== Payload Mode + +Message Transmission Optimization Mechanism (MTOM) is supported by this Mode. Attachments can be retrieved by Camel Message APIs mentioned above. SOAP with Attachment (SwA) is supported and attachments can be retrieved. SwA is the default (same as setting the CXF endpoint property `mtomEnabled` to `false`). @@ -607,7 +609,7 @@ XML (Spring):: - + @@ -724,26 +726,26 @@ public static class MyProcessor implements Processor { } ---- -*RAW Mode:* Attachments are not supported as it does not process the -message at all. +=== RAW Mode + +Attachments are not supported as it does not process the message at all. + +=== CXF_MESSAGE Mode -*CXF_MESSAGE Mode*: MTOM is supported, and Attachments can be retrieved -by Camel Message APIs mentioned above. Note that when receiving a -multipart (i.e. MTOM) message the default SOAPMessage to String -converter will provide the complete multipart payload on the body. If -you require just the SOAP XML as a String, you can set the message body -with message.getSOAPPart(), and Camel convert can do the rest of work +MTOM is supported, and Attachments can be retrieved by Camel Message APIs mentioned above. Note that when receiving a multipart (i.e., MTOM) message, the default `SOAPMessag`e to `String` converter will provide the complete multipart payload on the body. +If you require just the SOAP XML as a String, you can set the message body +with `message.getSOAPPart()`, and the Camel converter can do the rest of the work for you. == Streaming Support in PAYLOAD mode -The camel-cxf component now supports streaming of incoming +The Camel CXF component now supports streaming of incoming messages when using PAYLOAD mode. Previously, the incoming messages -would have been completely DOM parsed. For large messages, this is time -consuming and uses a significant amount of memory. The incoming messages can remain as a javax.xml.transform.Source while +would have been completely DOM parsed. For large messages, this is time-consuming and uses a significant amount of memory. +The incoming messages can remain as a `javax.xml.transform.Source` while being routed and, if nothing modifies the payload, can then be directly streamed out to the target destination. For common "simple proxy" use -cases (example: from("cxf:...").to("cxf:...")), this can provide very +cases (example: `from("cxf:...").to("cxf:...")`), this can provide very significant performance increases as well as significantly lowered memory requirements. @@ -751,28 +753,26 @@ However, there are cases where streaming may not be appropriate or desired. Due to the streaming nature, invalid incoming XML may not be caught until later in the processing chain. Also, certain actions may require the message to be DOM parsed anyway (like WS-Security or message -tracing and such) in which case the advantages of the streaming is +tracing and such) in which case, the advantages of the streaming are limited. At this point, there are two ways to control the streaming: -* Endpoint property: you can add "allowStreaming=false" as an endpoint +* Endpoint property: you can add `allowStreaming=false` as an endpoint property to turn the streaming on/off. -* Component property: the CxfComponent object also has an allowStreaming +* Component property: the `CxfComponent` object also has an `allowStreaming` property that can set the default for endpoints created from that component. Global system property: you can add a system property of -"org.apache.camel.component.cxf.streaming" to "false" to turn it off. +`org.apache.camel.component.cxf.streaming` to `false` to turn it off. That sets the global default, but setting the endpoint property above will override this value for that endpoint. == Using the generic CXF Dispatch mode -The camel-cxf component supports the generic -https://cxf.apache.org/docs/jax-ws-dispatch-api.html[CXF dispatch -mode] that can transport messages of arbitrary structures (i.e., not -bound to a specific XML schema). To use this mode, you simply omit -specifying the wsdlURL and serviceClass attributes of the CXF endpoint. +The Camel CXF component supports the generic +https://cxf.apache.org/docs/jax-ws-dispatch-api.html[CXF dispatch mode] that can transport messages of arbitrary structures (i.e., not bound to a specific XML schema). +To use this mode, you omit specifying the `wsdlURL` and `serviceClass` attributes of the CXF endpoint. [tabs] ==== @@ -812,9 +812,9 @@ XML (Spring):: ==== It is noted that the default CXF dispatch client does not send a -specific SOAPAction header. Therefore, when the target service requires -a specific SOAPAction value, it is supplied in the Camel header using -the key SOAPAction (case-insensitive). +specific `SOAPAction` header. Therefore, when the target service requires +a specific `SOAPAction` value, it is supplied in the Camel header using +the key `SOAPAction` (case-insensitive). [#cxf-loggingout-interceptor-in-message-mode] === How to enable CXF's LoggingOutInterceptor in RAW mode @@ -862,7 +862,7 @@ XML (Spring):: [source,xml] ---- - + @@ -916,13 +916,13 @@ is unknown to the runtime, the header will be simply relayed. * `POJO` and `PAYLOAD` modes are supported. In `POJO` mode, only out-of-band message headers are available for filtering as the in-band -headers have been processed and removed from header list by CXF. The +headers have been processed and removed from the header list by CXF. The in-band headers are incorporated into the `MessageContentList` in POJO -mode. The `camel-cxf` component does make any attempt to remove the +mode. The Camel CXF component does make any attempt to remove the in-band headers from the `MessageContentList`. If filtering of in-band headers is required, please use `PAYLOAD` mode or plug in a (pretty straightforward) CXF interceptor/JAXWS Handler to the CXF endpoint. - Here is an example of configuring CxfHeaderFilterStrategy. + Here is an example of configuring the `CxfHeaderFilterStrategy`. [source,xml] @@ -935,7 +935,7 @@ straightforward) CXF interceptor/JAXWS Handler to the CXF endpoint. ---- -Then, your endpoint can reference the `CxfHeaderFilterStrategy`. +Then, your endpoint can reference the `CxfHeaderFilterStrategy`: [source,xml] ---- @@ -945,9 +945,9 @@ Then, your endpoint can reference the `CxfHeaderFilterStrategy`. ---- -* You can plugin your own `MessageHeaderFilter` implementations overriding -or adding additional ones to the list of relays. In order to override a -preloaded relay instance just make sure that your `MessageHeaderFilter` +* You can plug in your own `MessageHeaderFilter` implementations overriding +or adding additional ones to the list of relays. To override a +preloaded relay instance, make sure that your `MessageHeaderFilter` implementation services the same name spaces as the one you are looking to override. @@ -958,7 +958,7 @@ Here is an example of configuring user defined Message Header Filters: - + @@ -983,33 +983,33 @@ Header Filters) _Type_: `boolean` _Default_: `false` -|`allowFilterNamespaceClash` |No |If two filters overlap in activation namespace, the property control how +|`allowFilterNamespaceClash` |No |If two filters overlap in activation namespace, the property controls how it should be handled. If the value is `true`, last one wins. If the value is `false`, it will throw an exception _Type_: `boolean` _Default_: `false` |======================================================================= -== How to make the camel-cxf component use log4j instead of java.util.logging +== How to make the Camel CXF component use log4j instead of java.util.logging CXF's default logger is `java.util.logging`. If you want to change it to log4j, proceed as follows. Create a file, in the classpath, named `META-INF/cxf/org.apache.cxf.logger`. This file should contain the -fully-qualified name of the class, +fully qualified name of the class, `org.apache.cxf.common.logging.Log4jLogger`, with no comments, on a single line. -== How to let camel-cxf response start with xml processing instruction +== How to let Camel CXF response start with xml processing instruction If you are using some SOAP client such as PHP, you will get this kind of -error, because CXF doesn't add the XML processing instruction +error because CXF doesn't add the XML processing instruction ``: ---- Error:sendSms: SoapFault exception: [Client] looks like we got no XML document in [...] ---- -To resolve this issue, you just need to tell StaxOutInterceptor to +To resolve this issue, you need to tell `StaxOutInterceptor` to write the XML start document for you, as in the https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-soap/src/test/java/org/apache/camel/component/cxf/jaxws/WriteXmlDeclarationInterceptor.java[WriteXmlDeclarationInterceptor] below: [source,java] @@ -1027,7 +1027,7 @@ public class WriteXmlDeclarationInterceptor extends AbstractPhaseInterceptor` tag. These declarations are required because the combined `\{namespace}localName` syntax is presently not supported for this tag's attribute values. @@ -1128,7 +1128,7 @@ below. |`cxf:handlers` |A JAX-WS handler list which should be supplied to the JAX-WS endpoint. See below. -|`cxf:dataBinding` |You can specify the which `DataBinding` will be use in the endpoint. +|`cxf:dataBinding` |You can specify which `DataBinding` will be used in the endpoint. This can be supplied using the Spring `` syntax. @@ -1151,7 +1151,7 @@ Configuration page]. [NOTE] ==== -You can use cxf:properties to set the camel-cxf endpoint's dataFormat +You can use `cxf:properties` to set the Camel CXF endpoint's dataFormat and setDefaultBus properties from spring configuration file. [source,xml]