[CAMEL-19129] Improve Camel CXF documentation

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 3.20.2
• Component/s: camel-cxf, documentation
• Estimated Complexity: Unknown
• Assignee: Lukas Lowinger
• Reporter: Lukas Lowinger
• Created: 09/Mar/23 19:41
• Updated: 06/Jun/23 10:32
• Resolved: 06/Jun/23 10:32

Description

Camel CXF documentation could be improved, here are some ideas:

1. Out of date content

Some sections may explain problems or use cases that do not exist anymore and could thus be removed:

• HOW TO MAKE THE CAMEL-CXF COMPONENT USE LOG4J INSTEAD OF JAVA.UTIL.LOGGING - is this still an issue?
• Remove CONFIGURING THE CXF ENDPOINTS WITH APACHE ARIES BLUEPRINT - blueprint is not supported since Camel 4, is it?
• HOW TO OVERRIDE THE CXF PRODUCER ADDRESS FROM MESSAGE HEADER probably doesn't need to be under high level use cases and can be removed, as this header is described under headers section

2. Spring-specific parts that should be moved to a Spring-specific documentation page

This points to a more general problem, that Camel component documentation is oftentimes Spring-centric, although the given component can be used on a number of different runtimes or even with plain Camel. The Spring details may confuse users who do not use Spring. There should be a separate place for Spring specific details. It could perhaps work the same way like with Camel Quarkus, where each extension hast its own page documenting Quarkus specific GAV, configuration, limitations, etc.

• CONFIGURE THE CXF ENDPOINTS WITH SPRING

3. General

• Link to PersonProcessor at HOW TO CONSUME A MESSAGE FROM A CAMEL-CXF ENDPOINT IN POJO DATA FORMAT doesn't exist
• Shouldn't be artifactId = camel-cxf-soap ?
• Inconsistent definition of dataFormats in QUERY PARAMETERS and DESCRIPTIONS OF THE DATAFORMATS
• Make consistent section names - eg. "HOW TO DEAL WITH THE MESSAGE" vs "HOW TO CONSUME A MESSAGE"
• What does "Both SOAP with Attachment and MTOM are supported. However, SOAP with Attachment is not tested." mean in ATTACHMENT SUPPORT ?
• This sentence "To enable MTOM, set the CXF endpoint property "mtom-enabled" to true. (I believe you can only do it with Spring.)" at ATTACHMENT SUPPORT should be ideally rewritten
• Maybe re-order the sections, so it starts with some really simple example of consumer/producer (WSDL first/Java first approaches) and not with "How to ... " - as it seems more like corner cases sections
• Nice to have - having some best practice security section

Issue Links

• links to: GitHub Pull Request #9850