| [[CXF-CXFComponent]] |
| CXF Component |
| ~~~~~~~~~~~~~ |
| |
| [Note] |
| ==== |
| |
| |
| When using CXF as a consumer, the link:cxf-bean-component.html[CXF Bean |
| Component] allows you to factor out how message payloads are received |
| from their processing as a RESTful or SOAP web service. This has the |
| potential of using a multitude of transports to consume web services. |
| The bean component's configuration is also simpler and provides the |
| fastest method to implement web services using Camel and CXF. |
| |
| ==== |
| |
| [Tip] |
| ==== |
| |
| |
| When using CXF in streaming modes (see DataFormat option), then also |
| read about link:stream-caching.html[Stream caching]. |
| |
| ==== |
| |
| The *cxf:* component provides integration with |
| http://cxf.apache.org[Apache CXF] for connecting to JAX-WS services |
| hosted in CXF. |
| |
| * link:#CXF-CXFComponent[CXF Component] |
| ** link:#CXF-URIformat[URI format] |
| ** link:#CXF-Options[Options] |
| *** link:#CXF-Thedescriptionsofthedataformats[The descriptions of the |
| dataformats] |
| **** link:#CXF-HowtoenableCXFLoggingOutInterceptorinMESSAGEmode[How to |
| enable CXF's LoggingOutInterceptor in MESSAGE mode] |
| *** link:#CXF-DescriptionofrelayHeadersoption[Description of |
| relayHeaders option] |
| **** link:#CXF-AvailableonlyinPOJOmode[Available only in POJO mode] |
| **** link:#CXF-ChangessinceRelease2.0[Changes since Release 2.0] |
| ** link:#CXF-ConfiguretheCXFendpointswithSpring[Configure the CXF |
| endpoints with Spring] |
| ** |
| link:#CXF-ConfiguringtheCXFEndpointswithApacheAriesBlueprint.[Configuring |
| the CXF Endpoints with Apache Aries Blueprint.] |
| ** |
| link:#CXF-Howtomakethecamel-cxfcomponentuselog4jinsteadofjava.util.logging[How |
| to make the camel-cxf component use log4j instead of java.util.logging] |
| ** link:#CXF-Howtoletcamel-cxfresponsemessagewithxmlstartdocument[How to |
| let camel-cxf response message with xml start document] |
| ** link:#CXF-HowtooverridetheCXFproduceraddressfrommessageheader[How to |
| override the CXF producer address from message header] |
| ** |
| link:#CXF-Howtoconsumeamessagefromacamel-cxfendpointinPOJOdataformat[How |
| to consume a message from a camel-cxf endpoint in POJO data format] |
| ** |
| link:#CXF-Howtopreparethemessageforthecamel-cxfendpointinPOJOdataformat[How |
| to prepare the message for the camel-cxf endpoint in POJO data format] |
| ** |
| link:#CXF-Howtodealwiththemessageforacamel-cxfendpointinPAYLOADdataformat[How |
| to deal with the message for a camel-cxf endpoint in PAYLOAD data |
| format] |
| ** link:#CXF-HowtogetandsetSOAPheadersinPOJOmode[How to get and set SOAP |
| headers in POJO mode] |
| ** link:#CXF-HowtogetandsetSOAPheadersinPAYLOADmode[How to get and set |
| SOAP headers in PAYLOAD mode] |
| ** link:#CXF-SOAPheadersarenotavailableinMESSAGEmode[SOAP headers are |
| not available in MESSAGE mode] |
| ** link:#CXF-HowtothrowaSOAPFaultfromCamel[How to throw a SOAP Fault |
| from Camel] |
| ** |
| link:#CXF-Howtopropagateacamel-cxfendpointrequestandresponsecontext[How |
| to propagate a camel-cxf endpoint's request and response context] |
| ** link:#CXF-AttachmentSupport[Attachment Support] |
| ** link:#CXF-StreamingSupportinPAYLOADmode[Streaming Support in PAYLOAD |
| mode] |
| ** link:#CXF-UsingthegenericCXFDispatchmode[Using the generic CXF |
| Dispatch mode] |
| ** link:#CXF-SeeAlso[See Also] |
| |
| Maven users will need to add the following dependency to their `pom.xml` |
| for this component: |
| |
| [source,xml] |
| ------------------------------------------------------------ |
| <dependency> |
| <groupId>org.apache.camel</groupId> |
| <artifactId>camel-cxf</artifactId> |
| <version>x.x.x</version> |
| <!-- use the same version as your Camel core version --> |
| </dependency> |
| ------------------------------------------------------------ |
| |
| [Tip] |
| ==== |
| CXF dependencies |
| |
| If you want to learn about CXF dependencies you can checkout the |
| `WHICH-JARS` text file. |
| |
| ==== |
| |
| [[CXF-URIformat]] |
| URI format |
| ^^^^^^^^^^ |
| |
| [source,java] |
| ------------------------------ |
| cxf:bean:cxfEndpoint[?options] |
| ------------------------------ |
| |
| Where *cxfEndpoint* represents a bean ID that references a bean in the |
| Spring bean registry. With this URI format, most of the endpoint details |
| are specified in the bean definition. |
| |
| [source,java] |
| --------------------------- |
| cxf://someAddress[?options] |
| --------------------------- |
| |
| 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: |
| |
| [source,java] |
| --------------------------------------------------------------------- |
| cxf:bean:cxfEndpoint?wsdlURL=wsdl/hello_world.wsdl&dataFormat=PAYLOAD |
| --------------------------------------------------------------------- |
| |
| [[CXF-Options]] |
| Options |
| ^^^^^^^ |
| |
| [width="100%",cols="10%,10%,80%",options="header",] |
| |======================================================================= |
| |Name |Required |Description |
| |
| |`wsdlURL` |No |The location of the WSDL. It is obtained from endpoint address by |
| default. _Example_: file://local/wsdl/hello.wsdl[file://local/wsdl/hello.wsdl] |
| or `wsdl/hello.wsdl` |
| |
| |`serviceClass` |Yes |The name of the SEI (Service Endpoint Interface) class. This class can |
| have, but does not require, JSR181 annotations. + |
| This option is only required by POJO mode. If the wsdlURL option is |
| provided, serviceClass is not required for PAYLOAD and MESSAGE mode. |
| When wsdlURL option is used without serviceClass, the serviceName and |
| portName (endpointName for Spring configuration) options *MUST* be |
| provided. It is possible to use `#` notation to reference a |
| `serviceClass` object instance from the registry. E.g. |
| `serviceClass=#beanName`. The `serviceClass` for a CXF producer (that |
| is, the `to` endpoint) should be a Java interface. + |
| *Since 2.8,* it is possible to omit both wsdlURL and serviceClass |
| options for PAYLOAD and MESSAGE mode. When they are omitted, arbitrary |
| XML elements can be put in CxfPayload's body in PAYLOAD mode to |
| facilitate CXF Dispatch Mode. |
| Please be advised that the *referenced object cannot be a Proxy* |
| (Spring AOP Proxy is OK) as it relies on `Object.getClass().getName()` |
| method for non Spring AOP Proxy. |
| _Example_: `org.apache.camel.Hello` |
| |
| |`serviceName` |No |The service name this service is implementing, it maps to the |
| `wsdl:service@name`. |
| *Required* for camel-cxf consumer since camel-2.2.0 or if more than one |
| `serviceName` is present in WSDL. |
| _Example_: \{http://org.apache.camel}ServiceName |
| |
| |`endpointName` |No |The port name this service is implementing, it maps to the |
| `wsdl:port@name`. |
| *Required* for camel-cxf consumer since camel-2.2.0 or if more than one |
| `portName` is present under `serviceName`. |
| _Example_: \{http://org.apache.camel}PortName |
| |
| |`dataFormat` |No |The data type messages supported by the CXF endpoint. |
| _Default_: `POJO` |
| _Example_: `POJO`, `PAYLOAD`, `MESSAGE` |
| |
| |`relayHeaders` |No |Please see the *Description of* `relayHeaders` *option* section for this |
| option. Should a CXF endpoint relay headers along the route. Currently |
| only available when `dataFormat=POJO` |
| _Default_: `true` |
| _Example_: `true`, `false` |
| |
| |`wrapped` |No |Which kind of operation that CXF endpoint producer will invoke + |
| _Default_: `false` |
| _Example_: `true`, `false` |
| |
| |`wrappedStyle` |No |*New in 2.5.0* The WSDL style that describes how parameters are |
| represented in the SOAP body. If the value is false, CXF will chose the |
| document-literal unwrapped style, If the value is true, CXF will chose |
| the document-literal wrapped style |
| _Default_: `Null` |
| _Example_: `true`, `false` |
| |
| |`setDefaultBus` |No |*Deprecated* Will set the default bus when CXF endpoint create a bus by |
| itself. This option is deprecated use defaultBus from Camel 2.16 |
| onwards. |
| _Default_: `false` |
| _Example_: `true`, `false` |
| |
| |`defaultBus` |No |*Camel 2.16:* Will set the default bus when CXF endpoint create a bus by |
| itself |
| _Default_: `false` |
| _Example_: `true`, `false` |
| |
| |`bus` |No |A default bus created by CXF Bus Factory. Use `#` notation to reference |
| a bus object from the registry. The referenced object must be an |
| instance of `org.apache.cxf.Bus`. |
| _Example_: `bus=#busName` |
| |
| |`cxfBinding` |No |Use `#` notation to reference a CXF binding object from the registry. |
| The referenced object must be an instance of |
| `org.apache.camel.component.cxf.CxfBinding` (use an instance of |
| `org.apache.camel.component.cxf.DefaultCxfBinding`). |
| _Example_: `cxfBinding=#bindingName` |
| |
| |`headerFilterStrategy` |No |Use `#` notation to reference a header filter strategy object from the |
| registry. The referenced object must be an instance of |
| `org.apache.camel.spi.HeaderFilterStrategy` (use an instance of |
| `org.apache.camel.component.cxf.CxfHeaderFilterStrategy`). |
| _Example_: `headerFilterStrategy=#strategyName` |
| |
| |`loggingFeatureEnabled` |No |New in 2.3. This option enables CXF Logging Feature which writes inbound |
| and outbound SOAP messages to log. |
| _Default_: `false` + |
| _Example_: `loggingFeatureEnabled``=true` |
| |
| |`defaultOperationName` |No |New in 2.4, this option will set the default operationName that will be |
| used by the CxfProducer which invokes the remote service. |
| _Default_: `null` + |
| _Example_: `defaultOperationName``=greetMe` |
| |
| |`defaultOperationNamespace` |No |New in 2.4. This option will set the default operationNamespace that |
| will be used by the CxfProducer which invokes the remote service. |
| _Default_: `null` |
| _Example_: |
| `defaultOperationNamespace``=``http://apache.org/hello_world_soap_http` |
| |
| |`synchronous` |No |New in 2.5. This option will let cxf endpoint decide to use sync or |
| async API to do the underlying work. The default value is false which |
| means camel-cxf endpoint will try to use async API by default. |
| _Default_: `false` |
| _Example_: synchronous=true |
| |
| |`publishedEndpointUrl` |No |New in 2.5. This option can override the endpointUrl that published from |
| the WSDL which can be accessed with service address url plus ?wsdl. |
| _Default_: `null` |
| _Example_: publshedEndpointUrl=http://example.com/service[http://example.com/service] |
| |
| |`properties.XXX` |No |*Camel 2.8:* Allows to set custom properties to CXF in the endpoint uri. |
| For example setting `properties.mtom-enabled=true` to enable MTOM. |
| `properties.org.apache.cxf.interceptor.OneWayProcessorInterceptor.USE_ORIGINAL_THREAD=true `just |
| make sure the CXF doesn't switch the thread when start the invocation. |
| |
| |`allowStreaming` |No |New in *Camel 2.8.2*. This option controls whether the CXF component, |
| when running in PAYLOAD mode (see below), will DOM parse the incoming |
| messages into DOM Elements or keep the payload as a |
| javax.xml.transform.Source object that would allow streaming in some |
| cases. |
| |
| |`skipFaultLogging` |No |New in *Camel 2.11*. This option controls whether the |
| PhaseInterceptorChain skips logging the Fault that it catches. |
| |
| |`cxfEndpointConfigurer` |No |New in *Camel 2.11*. This option could apply the implementation of |
| `org.apache.camel.component.cxf.CxfEndpointConfigurer which `supports to |
| configure the CXF endpoint in programmatic way. Since *Camel |
| 2.15.0,*user can configure the CXF server and client by implementing |
| configure\{Server|Client} method of `CxfEndpointConfigurer`. |
| |
| |`username` |No |New in *Camel 2.12.3* This option is used to set the basic |
| authentication information of username for the CXF client. |
| |
| |`password` |No |New in *Camel 2.12.3* This option is used to set the basic |
| authentication information of password for the CXF client. |
| |
| |`continuationTimeout` |No |New in *Camel 2.14.0*This option is used to set the CXF continuation |
| timeout which could be used in CxfConsumer by default when the CXF |
| server is using Jetty or Servlet transport. (Before *Camel 2.14.0*, |
| CxfConsumer just set the continuation timeout to be 0, which means the |
| continuation suspend operation never timeout.) |
| _Default_: 30000 |
| _Example_: continuation=80000 |
| |======================================================================= |
| |
| 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 |
| above. |
| |
| [[CXF-Thedescriptionsofthedataformats]] |
| The descriptions of the dataformats |
| +++++++++++++++++++++++++++++++++++ |
| |
| [width="100%",cols="50%,50%",options="header",] |
| |======================================================================= |
| |DataFormat |Description |
| |
| |`POJO` |POJOs (Plain old Java objects) are the Java parameters to the method |
| being invoked on the target server. Both Protocol and Logical JAX-WS |
| handlers are supported. |
| |
| |`PAYLOAD` |`PAYLOAD` is the message payload (the contents of the `soap:body`) after |
| message configuration in the CXF endpoint is applied. Only Protocol |
| JAX-WS handler is supported. Logical JAX-WS handler is not supported. |
| |
| |`MESSAGE` |`MESSAGE` is the raw message that is received from the transport layer. |
| It is not suppose to touch or change 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 and JAX-WS |
| handler is not supported. |
| |
| |`CXF_MESSAGE` |New in *Camel 2.8.2*, `CXF_MESSAGE` allows for invoking the full |
| capabilities of CXF interceptors by converting the message from the |
| transport layer into a raw SOAP message |
| |======================================================================= |
| |
| You can determine the data format mode of an exchange by retrieving the |
| exchange property, `CamelCXFDataFormat`. The exchange key constant is |
| defined in |
| `org.apache.camel.component.cxf.CxfConstants.DATA_FORMAT_PROPERTY`. |
| |
| [[CXF-HowtoenableCXFLoggingOutInterceptorinMESSAGEmode]] |
| How to enable CXF's LoggingOutInterceptor in MESSAGE mode |
| |
| CXF's `LoggingOutInterceptor` outputs outbound message that goes on the |
| wire to logging system (Java Util Logging). Since the |
| `LoggingOutInterceptor` is in `PRE_STREAM` phase (but `PRE_STREAM` phase |
| is removed in `MESSAGE` mode), you have to configure |
| `LoggingOutInterceptor` to be run during the `WRITE` phase. The |
| following is an example. |
| |
| [source,xml] |
| ------------------------------------------------------------------------------------------------------- |
| <bean id="loggingOutInterceptor" class="org.apache.cxf.interceptor.LoggingOutInterceptor"> |
| <!-- it really should have been user-prestream but CXF does have such phase! --> |
| <constructor-arg value="target/write"/> |
| </bean> |
| |
| <cxf:cxfEndpoint id="serviceEndpoint" address="http://localhost:${CXFTestSupport.port2}/LoggingInterceptorInMessageModeTest/helloworld" |
| serviceClass="org.apache.camel.component.cxf.HelloService"> |
| <cxf:outInterceptors> |
| <ref bean="loggingOutInterceptor"/> |
| </cxf:outInterceptors> |
| <cxf:properties> |
| <entry key="dataFormat" value="MESSAGE"/> |
| </cxf:properties> |
| </cxf:cxfEndpoint> |
| ------------------------------------------------------------------------------------------------------- |
| |
| [[CXF-DescriptionofrelayHeadersoption]] |
| Description of relayHeaders option |
| ++++++++++++++++++++++++++++++++++ |
| |
| There are _in-band_ and _out-of-band_ on-the-wire headers from the |
| perspective of a JAXWS WSDL-first developer. |
| |
| The _in-band_ headers are headers that are explicitly defined as part of |
| the WSDL binding contract for an endpoint such as SOAP headers. |
| |
| The _out-of-band_ headers are headers that are serialized over the wire, |
| but are not explicitly part of the WSDL binding contract. |
| |
| Headers relaying/filtering is bi-directional. |
| |
| When a route has a CXF endpoint and the developer needs to have |
| on-the-wire headers, such as SOAP headers, be relayed along the route to |
| be consumed say by another JAXWS endpoint, then `relayHeaders` should be |
| set to `true`, which is the default value. |
| |
| [[CXF-AvailableonlyinPOJOmode]] |
| Available only in POJO mode |
| |
| The `relayHeaders=true` express an intent to relay the headers. The |
| actual decision on whether a given header is relayed is delegated to a |
| pluggable instance that implements the `MessageHeadersRelay` interface. |
| A concrete implementation of `MessageHeadersRelay` will be consulted to |
| decide if a header needs to be relayed or not. There is already an |
| implementation of `SoapMessageHeadersRelay` which binds itself to |
| well-known SOAP name spaces. Currently only out-of-band headers are |
| filtered, and in-band headers will always be relayed when |
| `relayHeaders=true`. If there is a header on the wire, whose name space |
| is unknown to the runtime, then a fall back `DefaultMessageHeadersRelay` |
| will be used, which simply allows all headers to be relayed. |
| |
| The `relayHeaders=false` setting asserts that all headers in-band and |
| out-of-band will be dropped. |
| |
| You can plugin your own `MessageHeadersRelay` implementations overriding |
| or adding additional ones to the list of relays. In order to override a |
| preloaded relay instance just make sure that your `MessageHeadersRelay` |
| implementation services the same name spaces as the one you looking to |
| override. Also note, that the overriding relay has to service all of the |
| name spaces as the one you looking to override, or else a runtime |
| exception on route start up will be thrown as this would introduce an |
| ambiguity in name spaces to relay instance mappings. |
| |
| [source,xml] |
| ------------------------------------------------------------------------------------------------------- |
| <cxf:cxfEndpoint ...> |
| <cxf:properties> |
| <entry key="org.apache.camel.cxf.message.headers.relays"> |
| <list> |
| <ref bean="customHeadersRelay"/> |
| </list> |
| </entry> |
| </cxf:properties> |
| </cxf:cxfEndpoint> |
| <bean id="customHeadersRelay" class="org.apache.camel.component.cxf.soap.headers.CustomHeadersRelay"/> |
| ------------------------------------------------------------------------------------------------------- |
| |
| Take a look at the tests that show how you'd be able to relay/drop |
| headers here: |
| |
| https://svn.apache.org/repos/asf/camel/branches/camel-1.x/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java[https://svn.apache.org/repos/asf/camel/branches/camel-1.x/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java] |
| |
| [[CXF-ChangessinceRelease2.0]] |
| Changes since Release 2.0 |
| |
| * `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 |
| in-band headers are incorporated into the `MessageContentList` in POJO |
| 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. |
| * The Message Header Relay mechanism has been merged into |
| `CxfHeaderFilterStrategy`. The `relayHeaders` option, its semantics, and |
| default value remain the same, but it is a property of |
| `CxfHeaderFilterStrategy`. |
| Here is an example of configuring it. |
| |
| [source,xml] |
| ------------------------------------------------------------------------------------------------------- |
| <bean id="dropAllMessageHeadersStrategy" class="org.apache.camel.component.cxf.common.header.CxfHeaderFilterStrategy"> |
| |
| <!-- Set relayHeaders to false to drop all SOAP headers --> |
| <property name="relayHeaders" value="false"/> |
| |
| </bean> |
| ------------------------------------------------------------------------------------------------------- |
| |
| Then, your endpoint can reference the `CxfHeaderFilterStrategy`. |
| |
| [source,xml] |
| ------------------------------------------------------------------------------------------------------- |
| <route> |
| <from uri="cxf:bean:routerNoRelayEndpoint?headerFilterStrategy=#dropAllMessageHeadersStrategy"/> |
| <to uri="cxf:bean:serviceNoRelayEndpoint?headerFilterStrategy=#dropAllMessageHeadersStrategy"/> |
| </route> |
| ------------------------------------------------------------------------------------------------------- |
| |
| * The `MessageHeadersRelay` interface has changed slightly and has been |
| renamed to `MessageHeaderFilter`. It is a property of |
| `CxfHeaderFilterStrategy`. Here is an example of configuring user |
| defined Message Header Filters: |
| |
| [source,xml] |
| ------------------------------------------------------------------------------------------------------- |
| <bean id="customMessageFilterStrategy" class="org.apache.camel.component.cxf.common.header.CxfHeaderFilterStrategy"> |
| <property name="messageHeaderFilters"> |
| <list> |
| <!-- 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 --> |
| <bean class="org.apache.camel.component.cxf.soap.headers.CustomHeaderFilter"/> |
| </list> |
| </property> |
| </bean> |
| ------------------------------------------------------------------------------------------------------- |
| |
| * Other than `relayHeaders`, there are new properties that can be |
| configured in `CxfHeaderFilterStrategy`. |
| |
| [width="100%",cols="10%,10%,80%",options="header",] |
| |======================================================================= |
| |Name |Required |Description |
| |`relayHeaders` |No |All message headers will be processed by Message Header Filters |
| _Type_: `boolean` |
| _Default_: `true` |
| |
| |`relayAllMessageHeaders` | No |All message headers will be propagated (without processing by Message |
| Header Filters) |
| _Type_: `boolean` |
| _Default_: `false` |
| |
| |`allowFilterNamespaceClash` |No |If two filters overlap in activation namespace, the property control 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` |
| |======================================================================= |
| |
| [[CXF-ConfiguretheCXFendpointswithSpring]] |
| Configure the CXF endpoints with Spring |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| You can configure the CXF endpoint with the Spring configuration file |
| shown below, and you can also embed the endpoint into the `camelContext` |
| tags. When you are invoking the service endpoint, you can set the |
| `operationName` and `operationNamespace` headers to explicitly state |
| which operation you are calling. |
| |
| [source,xml] |
| ---------------------------------------------------------------------------------------------------------------- |
| <beans xmlns="http://www.springframework.org/schema/beans" |
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" |
| xmlns:cxf="http://camel.apache.org/schema/cxf" |
| xsi:schemaLocation=" |
| http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd |
| http://camel.apache.org/schema/cxf http://camel.apache.org/schema/cxf/camel-cxf.xsd |
| http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd"> |
| <cxf:cxfEndpoint id="routerEndpoint" address="http://localhost:9003/CamelContext/RouterPort" |
| serviceClass="org.apache.hello_world_soap_http.GreeterImpl"/> |
| <cxf:cxfEndpoint id="serviceEndpoint" address="http://localhost:9000/SoapContext/SoapPort" |
| wsdlURL="testutils/hello_world.wsdl" |
| serviceClass="org.apache.hello_world_soap_http.Greeter" |
| endpointName="s:SoapPort" |
| serviceName="s:SOAPService" |
| xmlns:s="http://apache.org/hello_world_soap_http" /> |
| <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"> |
| <route> |
| <from uri="cxf:bean:routerEndpoint" /> |
| <to uri="cxf:bean:serviceEndpoint" /> |
| </route> |
| </camelContext> |
| </beans> |
| ---------------------------------------------------------------------------------------------------------------- |
| |
| Be sure to include the JAX-WS `schemaLocation` attribute specified on |
| 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 are required because the combined |
| \{`namespace}localName` syntax is presently not supported for this tag's |
| attribute values. |
| |
| The `cxf:cxfEndpoint` element supports many additional attributes: |
| |
| [width="100%",cols="50%,50%",options="header",] |
| |======================================================================= |
| |Name |Value |
| |
| |`PortName` |The endpoint name this service is implementing, it maps to the |
| `wsdl:port@name`. In the format of `ns:PORT_NAME` where `ns` is a |
| namespace prefix valid at this scope. |
| |
| |`serviceName` |The service name this service is implementing, it maps to the |
| `wsdl:service@name`. In the format of `ns:SERVICE_NAME` where `ns` is a |
| namespace prefix valid at this scope. |
| |
| |`wsdlURL` |The location of the WSDL. Can be on the classpath, file system, or be |
| hosted remotely. |
| |
| |`bindingId` |The `bindingId` for the service model to use. |
| |
| |`address` |The service publish address. |
| |
| |`bus` |The bus name that will be used in the JAX-WS endpoint. |
| |
| |`serviceClass` |The class name of the SEI (Service Endpoint Interface) class which could |
| have JSR181 annotation or not. |
| |======================================================================= |
| |
| It also supports many child elements: |
| |
| [width="100%",cols="50%,50%",options="header",] |
| |======================================================================= |
| |Name |Value |
| |
| |`cxf:inInterceptors` |The incoming interceptors for this endpoint. A list of `<bean>` or |
| `<ref>`. |
| |
| |`cxf:inFaultInterceptors` |The incoming fault interceptors for this endpoint. A list of `<bean>` or |
| `<ref>`. |
| |
| |`cxf:outInterceptors` |The outgoing interceptors for this endpoint. A list of `<bean>` or |
| `<ref>`. |
| |
| |`cxf:outFaultInterceptors` |The outgoing fault interceptors for this endpoint. A list of `<bean>` or |
| `<ref>`. |
| |
| |`cxf:properties` | A properties map which should be supplied to the JAX-WS endpoint. See |
| 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. |
| This can be supplied using the Spring `<bean class="MyDataBinding"/>` |
| syntax. |
| |
| |`cxf:binding` |You can specify the `BindingFactory` for this endpoint to use. This can |
| be supplied using the Spring `<bean class="MyBindingFactory"/>` syntax. |
| |
| |`cxf:features` |The features that hold the interceptors for this endpoint. A list of |
| beans or refs |
| |
| |`cxf:schemaLocations` |The schema locations for endpoint to use. A list of schemaLocations |
| |
| |`cxf:serviceFactory` |The service factory for this endpoint to use. This can be supplied using |
| the Spring `<bean class="MyServiceFactory"/>` syntax |
| |======================================================================= |
| |
| You can find more advanced examples that show how to provide |
| interceptors, properties and handlers on the CXF |
| https://cwiki.apache.org/CXF20DOC/JAX-WS+Configuration[JAX-WS |
| Configuration page]. |
| |
| *NOTE* |
| You can use cxf:properties to set the camel-cxf endpoint's dataFormat |
| and setDefaultBus properties from spring configuration file. |
| |
| [source,xml] |
| ------------------------------------------------------------------------- |
| <cxf:cxfEndpoint id="testEndpoint" address="http://localhost:9000/router" |
| serviceClass="org.apache.camel.component.cxf.HelloService" |
| endpointName="s:PortName" |
| serviceName="s:ServiceName" |
| xmlns:s="http://www.example.com/test"> |
| <cxf:properties> |
| <entry key="dataFormat" value="MESSAGE"/> |
| <entry key="setDefaultBus" value="true"/> |
| </cxf:properties> |
| </cxf:cxfEndpoint> |
| ------------------------------------------------------------------------- |
| |
| [[CXF-ConfiguringtheCXFEndpointswithApacheAriesBlueprint.]] |
| Configuring the CXF Endpoints with Apache Aries Blueprint. |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| Since camel 2.8 there is support for utilizing aries blueprint |
| dependency injection for your CXF endpoints. |
| The schema utilized is very similar to the spring schema so the |
| transition is fairly transparent. |
| |
| Example |
| |
| [source,xml] |
| ------------------------------------------------------------------------------------------------------------------------------------ |
| <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" |
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" |
| xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0" |
| xmlns:camel-cxf="http://camel.apache.org/schema/blueprint/cxf" |
| xmlns:cxfcore="http://cxf.apache.org/blueprint/core" |
| xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd"> |
| |
| <camel-cxf:cxfEndpoint id="routerEndpoint" |
| address="http://localhost:9001/router" |
| serviceClass="org.apache.servicemix.examples.cxf.HelloWorld"> |
| <camel-cxf:properties> |
| <entry key="dataFormat" value="MESSAGE"/> |
| </camel-cxf:properties> |
| </camel-cxf:cxfEndpoint> |
| |
| <camel-cxf:cxfEndpoint id="serviceEndpoint" |
| address="http://localhost:9000/SoapContext/SoapPort" |
| serviceClass="org.apache.servicemix.examples.cxf.HelloWorld"> |
| </camel-cxf:cxfEndpoint> |
| |
| <camelContext xmlns="http://camel.apache.org/schema/blueprint"> |
| <route> |
| <from uri="routerEndpoint"/> |
| <to uri="log:request"/> |
| </route> |
| </camelContext> |
| |
| </blueprint> |
| ------------------------------------------------------------------------------------------------------------------------------------ |
| |
| Currently the endpoint element is the first supported CXF |
| namespacehandler. |
| |
| You can also use the bean references just as in spring |
| |
| [source,xml] |
| ---------------------------------------------------------------------------------------------------------------- |
| <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" |
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" |
| xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0" |
| xmlns:jaxws="http://cxf.apache.org/blueprint/jaxws" |
| xmlns:cxf="http://cxf.apache.org/blueprint/core" |
| xmlns:camel="http://camel.apache.org/schema/blueprint" |
| xmlns:camelcxf="http://camel.apache.org/schema/blueprint/cxf" |
| xsi:schemaLocation=" |
| http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd |
| http://cxf.apache.org/blueprint/jaxws http://cxf.apache.org/schemas/blueprint/jaxws.xsd |
| http://cxf.apache.org/blueprint/core http://cxf.apache.org/schemas/blueprint/core.xsd |
| "> |
| |
| <camelcxf:cxfEndpoint id="reportIncident" |
| address="/camel-example-cxf-blueprint/webservices/incident" |
| wsdlURL="META-INF/wsdl/report_incident.wsdl" |
| serviceClass="org.apache.camel.example.reportincident.ReportIncidentEndpoint"> |
| </camelcxf:cxfEndpoint> |
| |
| <bean id="reportIncidentRoutes" class="org.apache.camel.example.reportincident.ReportIncidentRoutes" /> |
| |
| <camelContext xmlns="http://camel.apache.org/schema/blueprint"> |
| <routeBuilder ref="reportIncidentRoutes"/> |
| </camelContext> |
| |
| </blueprint> |
| ---------------------------------------------------------------------------------------------------------------- |
| |
| [[CXF-Howtomakethecamel-cxfcomponentuselog4jinsteadofjava.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, |
| `org.apache.cxf.common.logging.Log4jLogger`, with no comments, on a |
| single line. |
| |
| [[CXF-Howtoletcamel-cxfresponsemessagewithxmlstartdocument]] |
| How to let camel-cxf response message with xml start document |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| If you are using some SOAP client such as PHP, you will get this kind of |
| error, because CXF doesn't add the XML start document "<?xml |
| version="1.0" encoding="utf-8"?>" |
| |
| [source,java] |
| --------------------------------------------------------------------------------------- |
| Error:sendSms: SoapFault exception: [Client] looks like we got no XML document in [...] |
| --------------------------------------------------------------------------------------- |
| |
| To resolved this issue, you just need to tell StaxOutInterceptor to |
| write the XML start document for you. |
| |
| You can add a customer interceptor like this and configure it into you |
| camel-cxf endpont |
| |
| Or adding a message header for it like this if you are using *Camel |
| 2.4*. |
| |
| [source,java] |
| ------------------------------------------------------------------- |
| // set up the response context which force start document |
| Map<String, Object> map = new HashMap<String, Object>(); |
| map.put("org.apache.cxf.stax.force-start-document", Boolean.TRUE); |
| exchange.getOut().setHeader(Client.RESPONSE_CONTEXT, map); |
| ------------------------------------------------------------------- |
| |
| [[CXF-HowtooverridetheCXFproduceraddressfrommessageheader]] |
| How to override the CXF producer address from message header |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| The `camel-cxf` producer supports to override the services address by |
| setting the message with the key of "CamelDestinationOverrideUrl". |
| |
| [source,java] |
| ---------------------------------------------------------------------------------------------- |
| // set up the service address from the message header to override the setting of CXF endpoint |
| exchange.getIn().setHeader(Exchange.DESTINATION_OVERRIDE_URL, constant(getServiceAddress())); |
| ---------------------------------------------------------------------------------------------- |
| |
| [[CXF-Howtoconsumeamessagefromacamel-cxfendpointinPOJOdataformat]] |
| 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 |
| http://cwiki.apache.org/CXF20DOC/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 |
| method parameters. |
| |
| [[CXF-Howtopreparethemessageforthecamel-cxfendpointinPOJOdataformat]] |
| How to prepare the message for the camel-cxf endpoint in POJO data format |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| The `camel-cxf` endpoint producer is based on the |
| https://svn.apache.org/repos/asf/cxf/trunk/api/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. |
| |
| If you don't specify the operation name in the message header, |
| `CxfProducer` will try to use the `defaultOperationName `from |
| `CxfEndpoint`, if there is no `defaultOperationName` set on |
| `CxfEndpoint`, it will pickup the first operationName from the Operation |
| list. |
| |
| If you want to get the object array from the message body, you can get |
| the body using `message.getbody(Object[].class)`, as follows: |
| |
| [[CXF-Howtodealwiththemessageforacamel-cxfendpointinPAYLOADdataformat]] |
| How to deal with the message for a camel-cxf endpoint in PAYLOAD data format |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| `PAYLOAD` means that you process the payload message from the SOAP |
| envelope. You can use the `Header.HEADER_LIST` as the key to set or get |
| the SOAP headers and use the `List<Element>` to set or get SOAP body |
| elements. |
| `Message.getBody()` will return an |
| `org.apache.camel.component.cxf.CxfPayload` object, which has getters |
| for SOAP message headers and Body elements. This change enables |
| decoupling the native CXF message from the Camel message. |
| |
| [[CXF-HowtogetandsetSOAPheadersinPOJOmode]] |
| 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 expose 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 Header list after they |
| have been processed, only out-of-band SOAP headers are available to |
| Camel-cxf in POJO mode. |
| |
| The following example illustrate 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 |
| obtain/insert SOAP headers at (1) before request goes out to the CXF |
| service and (2) before response comes back to the SOAP Client. Processor |
| (1) and (2) in this example are InsertRequestOutHeaderProcessor and |
| InsertResponseOutHeaderProcessor. Our route looks like this: |
| |
| 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. |
| |
| [[CXF-HowtogetandsetSOAPheadersinPAYLOADmode]] |
| How to get and set SOAP headers in PAYLOAD mode |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| We've already shown how to access SOAP message (CxfPayload object) in |
| PAYLOAD mode (See "How to deal with the message for 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 |
| headers). |
| |
| Since Camel 2.16.0, 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 |
| the SOAP headers. So, you can use now the |
| 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 |
| 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". |
| |
| [[CXF-SOAPheadersarenotavailableinMESSAGEmode]] |
| SOAP headers are not available in MESSAGE mode |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| SOAP headers are not available in MESSAGE mode as SOAP processing is |
| skipped. |
| |
| [[CXF-HowtothrowaSOAPFaultfromCamel]] |
| How to throw a SOAP Fault from Camel |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| 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 `MESSAGE` data format. + |
| You can define the soap fault like this |
| |
| Then throw it as you like |
| |
| If your CXF endpoint is working in the `MESSAGE` data format, you could |
| set the the SOAP Fault message in the message body and set the response |
| code in the message header. |
| |
| Same for using POJO data format. You can set the SOAPFault on the out |
| body and also indicate it's a fault by calling Message.setFault(true): |
| |
| [[CXF-Howtopropagateacamel-cxfendpointrequestandresponsecontext]] |
| How to propagate a camel-cxf endpoint's request and response context |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| https://svn.apache.org/repos/asf/cxf/trunk/api/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: |
| |
| [source,java] |
| ------------------------------------------------------------------------------------------------------------- |
| CxfExchange exchange = (CxfExchange)template.send(getJaxwsEndpointUri(), new Processor() { |
| public void process(final Exchange exchange) { |
| final List<String> params = new ArrayList<String>(); |
| params.add(TEST_MESSAGE); |
| // Set the request context to the inMessage |
| Map<String, Object> requestContext = new HashMap<String, Object>(); |
| requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, JAXWS_SERVER_ADDRESS); |
| exchange.getIn().setBody(params); |
| exchange.getIn().setHeader(Client.REQUEST_CONTEXT , requestContext); |
| exchange.getIn().setHeader(CxfConstants.OPERATION_NAME, GREET_ME_OPERATION); |
| } |
| }); |
| org.apache.camel.Message out = exchange.getOut(); |
| // The output is an object array, the first element of the array is the return value |
| Object\[\] output = out.getBody(Object\[\].class); |
| LOG.info("Received output text: " + output\[0\]); |
| // Get the response context form outMessage |
| Map<String, Object> responseContext = CastUtils.cast((Map)out.getHeader(Client.RESPONSE_CONTEXT)); |
| assertNotNull(responseContext); |
| assertEquals("Get the wrong wsdl opertion name", "{http://apache.org/hello_world_soap_http}greetMe", |
| responseContext.get("javax.xml.ws.wsdl.operation").toString()); |
| ------------------------------------------------------------------------------------------------------------- |
| |
| [[CXF-AttachmentSupport]] |
| Attachment Support |
| ^^^^^^^^^^^^^^^^^^ |
| |
| *POJO Mode:* Both SOAP with Attachment and MTOM are supported (see |
| example in Payload Mode for enabling MTOM). However, SOAP with |
| Attachment is not tested. Since attachments are marshalled and |
| unmarshalled into POJOs, users typically do not need to deal with the |
| attachment themself. Attachments are propagated to Camel message's |
| attachments if the MTOM is not enabled, since 2.12.3. So, it is |
| possible to retreive attachments by Camel Message API |
| |
| [source,java] |
| -------------------------------------------- |
| DataHandler Message.getAttachment(String id) |
| -------------------------------------------- |
| |
| *Payload Mode:* MTOM is supported since 2.1. Attachments can be |
| retrieved by Camel Message APIs mentioned above. SOAP with Attachment |
| (SwA) is supported and attachments can be retrieved since 2.5. SwA is |
| the default (same as setting the CXF endpoint property "mtom-enabled" to |
| false). |
| |
| To enable MTOM, set the CXF endpoint property "mtom-enabled" to _true_. |
| (I believe you can only do it with Spring.) |
| |
| You can produce a Camel message with attachment to send to a CXF |
| endpoint in Payload mode. |
| |
| You can also consume a Camel message received from a CXF endpoint in |
| Payload mode. |
| |
| *Message Mode:* Attachments are not supported as it does not process the |
| message at all. |
| |
| *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 |
| for you. |
| |
| [[CXF-StreamingSupportinPAYLOADmode]] |
| Streaming Support in PAYLOAD mode |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| In 2.8.2, 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. Starting in 2.8.2, |
| 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 |
| significant performance increases as well as significantly lowered |
| memory requirements. |
| |
| 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 |
| limited. At this point, there are two ways to control the streaming: |
| |
| * 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 |
| 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 if off. |
| That sets the global default, but setting the endpoint property above |
| will override this value for that endpoint. |
| |
| [[CXF-UsingthegenericCXFDispatchmode]] |
| Using the generic CXF Dispatch mode |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| From 2.8.0, 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. |
| |
| [source,xml] |
| ------------------------------------------------------------------------------------------- |
| <cxf:cxfEndpoint id="testEndpoint" address="http://localhost:9000/SoapContext/SoapAnyPort"> |
| <cxf:properties> |
| <entry key="dataFormat" value="PAYLOAD"/> |
| </cxf:properties> |
| </cxf:cxfEndpoint> |
| ------------------------------------------------------------------------------------------- |
| |
| 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). |
| |
| |
| |
| [[CXF-SeeAlso]] |
| See Also |
| ^^^^^^^^ |
| |
| * link:configuring-camel.html[Configuring Camel] |
| * link:component.html[Component] |
| * link:endpoint.html[Endpoint] |
| * link:getting-started.html[Getting Started] |
| |