...
Name | Description | Example | Required? | default value |
|---|---|---|---|---|
wsdlURL | The location of the WSDL. | file://local/wsdl/hello.wsdl or wsdl/hello.wsdl | No | WSDL is obtained from endpoint address by default |
serviceClass | The name of the SEI(Service Endpoint Interface) class. This class can have but does not require JSR181 annotations. | org.apache.camel.Hello | Yes |
|
serviceClassInstance | In 1.6 or later (will be deprecated in 2.0), serviceClassInstance works like serviceClass=#beanName, which looks up a serviceObject instance from the registry. | serviceClassInstance=beanName | No (use either serviceClass or serviceClassInstance) |
|
serviceName | The service name this service is implementing, it maps to the wsdl:service@name. | {http://org.apache.camel} | Only if more than one serviceName in WSDL present |
|
portName | The port name this service is implementing, it maps to the wsdl:port@name. | {http://org.apache.camel} | Only if more than one portName under the serviceName is present |
|
dataFormat | Which data type messages the CXF endpoint supports | POJO, PAYLOAD, MESSAGE | No | POJO |
relayHeaders | Available since 1.6.1. Please see the Description of relayHeaders option section for this option in 2.0. Should a CXF endpoint relay headers along the route. Currently only available when dataFormat=POJO | true, false | No | true |
wrapped | Which kind of operation that CXF endpoint producer will invoke | true, false | No | false |
setDefaultBus | Will set the default bus when CXF endpoint create a bus by itself | true, false | No | false |
bus | New in 2.0, use # notation to reference a bus object from the registry. The referenced object must be an instance of org.apache.cxf.Bus. | bus=#busName | No | Default bus created by CXF Bus Factory |
cxfBinding | New in 2.0, 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. | cxfBinding=#bindingName | No | An instance of org.apache.camel.component.cxf.DefaultCxfBinding |
headerFilterStrategy | New in 2.0, 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. | headerFilterStrategy=#strategyName | No | An instance of org.apache.camel.component.cxf.CxfHeaderFilterStrategy |
...
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/dropping 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.
Available in Release 1.6.1 and after (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 MessageHeadersRelay interface. An concrete implementation 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.
...
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 has 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 recover the in-band headers from the MessageContentList as it does in 1.6.1. If filtering in-band headers is required, please you PAYLOAD mode or plug in a (pretty straight forward) 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.
| Wiki Markup |
|---|
{snippet:id=dropAllMessageHeadersStrategy|lang=xml|url=camel/trunk/components/camel-cxf/src/test/resources/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest-context.xml} |
Then, your endpoint can reference the CxfHeaderFilterStrategy.
| Wiki Markup |
|---|
{snippet:id=noRelayRoute|lang=xml|url=camel/trunk/components/camel-cxf/src/test/resources/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest-context.xml} |
- 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.
| Wiki Markup |
|---|
{snippet:id=customMessageFilterStrategy|lang=xml|url=camel/trunk/components/camel-cxf/src/test/resources/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest-context.xml} |
- Other than relayHeaders, there are new properties that can be configured in CxfHeaderFilterStrategy.
Name | Description | type | Required? | Default value |
|---|---|---|---|---|
relayHeaders | all message headers will be processed by Message Header Filters | boolean | no | true (1.6.1 behavior) |
relayAllMessageHeaders | all message headers will be propagated (without processing by Message Header Filters) | boolean | no | false (1.6.1 behavior) |
allowFilterNamespaceClash | 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 | boolean | no | false (1.6.1 behavior) |
Configure the CXF endpoints with spring
...