This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 98992a22359 CAMEL-20410: documentation fixes for camel-cxf-soap
98992a22359 is described below
commit 98992a223590524e7c55a0587367f0f6ca73b4ca
Author: Otavio R. Piske <angusyo...@gmail.com>
AuthorDate: Sun Feb 18 14:39:47 2024 +0100
CAMEL-20410: documentation fixes for camel-cxf-soap
- Fixed grammar and typos
- Fixed punctuation
- Added and/or fixed links
Signed-off-by: Otavio R. Piske <angusyo...@gmail.com>
---
.../src/main/docs/cxf-component.adoc | 232 ++++++++++-----------
1 file changed, 116 insertions(+), 116 deletions(-)
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 2d5f2a7f069..4849e66e833 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<String> personId = (Holder<String>) msgList.get(0);
Holder<String> ssn = (Holder<String>) 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<String, Object> 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 {
+
"<name>New_testOobHeader</name><value>New_testOobHeaderValue</value></outofbandHeader>";
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 <<How to consume a message from a camel-cxf
endpoint in PAYLOAD data format>>.
+We've already shown how to access the SOAP message as `CxfPayload` object in
+PAYLOAD mode in the section <<How to consume a message from a Camel CXF
endpoint in PAYLOAD data format>>.
-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)::
<cxf:properties>
<!-- enable mtom by setting this property to true -->
<entry key="mtom-enabled" value="true"/>
- <!-- set the camel-cxf endpoint data fromat to PAYLOAD mode -->
+ <!-- set the Camel CXF endpoint data fromat to PAYLOAD mode -->
<entry key="dataFormat" value="PAYLOAD"/>
</cxf:properties>
</cxf:cxfEndpoint>
@@ -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]
----
<bean id="loggingOutInterceptor"
class="org.apache.cxf.interceptor.LoggingOutInterceptor">
- <!-- it really should have been user-prestream but CXF does have such
phase! -->
+ <!-- it really should have been user-prestream, but CXF does have such a
phase! -->
<constructor-arg value="write"/>
</bean>
@@ -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.
</bean>
----
-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`.
</route>
----
-* 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:
<bean id="customMessageFilterStrategy"
class="org.apache.camel.component.cxf.transport.header.CxfHeaderFilterStrategy">
<property name="messageHeaderFilters">
<list>
- <!-- SoapMessageHeaderFilter is the built in filter. It can be
removed by omitting it. -->
+ <!-- SoapMessageHeaderFilter is the built-in filter. It can be
removed by omitting it. -->
<bean
class="org.apache.camel.component.cxf.common.header.SoapMessageHeaderFilter"/>
<!-- Add custom filter here -->
@@ -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
`<?xml version="1.0" encoding="utf-8"?>`:
----
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<Soa
}
----
-As an alternative you can add a message header for it as demonstrated in
https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-soap/src/test/java/org/apache/camel/component/cxf/jaxws/CxfConsumerTest.java#L62[CxfConsumerTest]:
+As an alternative, you can add a message header for it as demonstrated in
https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-soap/src/test/java/org/apache/camel/component/cxf/jaxws/CxfConsumerTest.java#L62[CxfConsumerTest]:
[source,java]
----
@@ -1072,7 +1072,7 @@ which operation you are calling.
----
Be sure to include the JAX-WS `schemaLocation` attribute specified on
-the root beans element. This allows CXF to validate the file and is
+the root `beans` element. This allows CXF to validate the file and is
required. Also note the namespace declarations at the end of the
`<cxf:cxfEndpoint/>` 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 `<bean class="MyDataBinding"/>`
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]
