You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "ppalaga (via GitHub)" <gi...@apache.org> on 2023/06/06 13:19:17 UTC

[GitHub] [camel-quarkus-examples] ppalaga commented on a diff in pull request #144: Provide example for CXF SOAP

ppalaga commented on code in PR #144:
URL: https://github.com/apache/camel-quarkus-examples/pull/144#discussion_r1219465241


##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel master component.

Review Comment:
   ```suggestion
   :cq-example-description: An example that shows how to use Camel CXF SOAP component.
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.

Review Comment:
   ```suggestion
   TIP: More information about generating Java classes from WSDL can be found in  https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-java-from-wsdl.html[wsdl2java] chapter of Quarkus CXF documentation.
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).

Review Comment:
   ```suggestion
   If you don't have the WSDL file upfront, you can create your SOAP service from Java classes annotated with JAX-WS annotations. 
   Check the `org.acme.cxf.soap.pojo.service.ContactService` interface as an example. 
   Again, we implement the service interface in a Camel fashion, this time though a bean 
   - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl`.
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).
+
+The exposed contact web service will enable five operations - _addContact_, _getContact_, _getContacts_, _updateContact_, _removeContact_.

Review Comment:
   ```suggestion
   The exposed contact web service will enable five operations - `addContact`, `getContact`, `getContacts`, `updateContact` and `removeContact`.
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).
+
+The exposed contact web service will enable five operations - _addContact_, _getContact_, _getContacts_, _updateContact_, _removeContact_.
+
+TIP: If you would like to only generate WSDL from Java, you can follow https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-wsdl-from-java.html.
+
+---
+=== Binding (Advanced)
+
+For illustrating how other `wsdl2java` options could be applied to `quarkus.cxf.codegen.wsdl2java.additional-params` we have added `src/main/resources/binding.xml` which enables us to use `LocalDate` (more common in Java world) instead of default XML Date representation `XMLGregorianCalendar`. But in terms of this quickstart, it is not important at all and we could work with `XMLGregorianCalendar` as well.
+
+== Start in the Development mode
+
+[source,shell]
+----
+$ mvn clean compile quarkus:dev
+----
+
+The above command compiles the project, starts the application and lets the Quarkus tooling watch for changes in your
+workspace. Any modifications in your project will automatically take effect in the running application.
+
+To start playing with the example, go to section `Local playground`.
+
+TIP: Please refer to the Development mode section of
+https://camel.apache.org/camel-quarkus/latest/first-steps.html#_development_mode[Camel Quarkus User guide] for more details.
+
+== Playground [[playground]]
+
+We can first try to add some contact with:
+[source,shell]
+----
+curl -X POST -H "Content-Type: text/xml;charset=UTF-8" -d @src/main/resources/requests/contact/add.xml http://localhost:8080/cxf/services/contact
+----
+Then verify it was added with:
+[source,shell]
+----
+$ curl -X POST -H "Content-Type: text/xml;charset=UTF-8" -d @src/main/resources/requests/contact/getAll.xml http://localhost:8080/cxf/services/contact
+----
+Which should return:
+
+[source,xml]
+----
+<soap:Envelope
+	xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
+	<soap:Body>
+		<ns2:getContactsResponse
+			xmlns:ns2="http://camel.apache.org/test/ContactService">
+			<return>
+				<contacts>
+					<name>Lukas</name>
+					<address>
+						<city>New York</city>
+						<street>Sky 1234</street>
+					</address>
+					<type>PERSONAL</type>
+				</contacts>
+			</return>
+		</ns2:getContactsResponse>
+	</soap:Body>
+</soap:Envelope>

Review Comment:
   It will be very hard to read like this.
   Could you please re-indent with 2 or 4 spaces? 



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).
+
+The exposed contact web service will enable five operations - _addContact_, _getContact_, _getContacts_, _updateContact_, _removeContact_.
+
+TIP: If you would like to only generate WSDL from Java, you can follow https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-wsdl-from-java.html.
+
+---
+=== Binding (Advanced)
+
+For illustrating how other `wsdl2java` options could be applied to `quarkus.cxf.codegen.wsdl2java.additional-params` we have added `src/main/resources/binding.xml` which enables us to use `LocalDate` (more common in Java world) instead of default XML Date representation `XMLGregorianCalendar`. But in terms of this quickstart, it is not important at all and we could work with `XMLGregorianCalendar` as well.
+
+== Start in the Development mode
+
+[source,shell]
+----
+$ mvn clean compile quarkus:dev
+----
+
+The above command compiles the project, starts the application and lets the Quarkus tooling watch for changes in your
+workspace. Any modifications in your project will automatically take effect in the running application.
+
+To start playing with the example, go to section `Local playground`.
+

Review Comment:
   ```suggestion
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).
+
+The exposed contact web service will enable five operations - _addContact_, _getContact_, _getContacts_, _updateContact_, _removeContact_.
+
+TIP: If you would like to only generate WSDL from Java, you can follow https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-wsdl-from-java.html.
+
+---
+=== Binding (Advanced)
+
+For illustrating how other `wsdl2java` options could be applied to `quarkus.cxf.codegen.wsdl2java.additional-params` we have added `src/main/resources/binding.xml` which enables us to use `LocalDate` (more common in Java world) instead of default XML Date representation `XMLGregorianCalendar`. But in terms of this quickstart, it is not important at all and we could work with `XMLGregorianCalendar` as well.
+
+== Start in the Development mode
+
+[source,shell]
+----
+$ mvn clean compile quarkus:dev
+----
+
+The above command compiles the project, starts the application and lets the Quarkus tooling watch for changes in your
+workspace. Any modifications in your project will automatically take effect in the running application.
+
+To start playing with the example, go to section `Local playground`.
+
+TIP: Please refer to the Development mode section of
+https://camel.apache.org/camel-quarkus/latest/first-steps.html#_development_mode[Camel Quarkus User guide] for more details.
+
+== Playground [[playground]]
+
+We can first try to add some contact with:
+[source,shell]
+----
+curl -X POST -H "Content-Type: text/xml;charset=UTF-8" -d @src/main/resources/requests/contact/add.xml http://localhost:8080/cxf/services/contact
+----
+Then verify it was added with:
+[source,shell]
+----
+$ curl -X POST -H "Content-Type: text/xml;charset=UTF-8" -d @src/main/resources/requests/contact/getAll.xml http://localhost:8080/cxf/services/contact
+----
+Which should return:
+
+[source,xml]
+----
+<soap:Envelope
+	xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
+	<soap:Body>
+		<ns2:getContactsResponse
+			xmlns:ns2="http://camel.apache.org/test/ContactService">
+			<return>
+				<contacts>
+					<name>Lukas</name>
+					<address>
+						<city>New York</city>
+						<street>Sky 1234</street>
+					</address>
+					<type>PERSONAL</type>
+				</contacts>
+			</return>
+		</ns2:getContactsResponse>
+	</soap:Body>
+</soap:Envelope>
+----
+
+We can also test our customer service:
+
+[source,shell]
+----
+$ curl -X POST -H "Content-Type: text/xml;charset=UTF-8" -d @src/main/resources/requests/customer/getByName.xml http://localhost:8080/cxf/services/customer
+----
+
+You can observe that we have hardcoded `test` name at SOAPBody part in `src/main/resources/requests/customer/getByName.soap` as follows:
+[source, xml]
+----
+<cus:getCustomersByName>
+    <name>test</name>
+</cus:getCustomersByName>
+----
+
+We can try to alter it to non-valid request (validation is enabled with `schema-validation-enabled=true` at `org.acme.cxf.soap.wsdl.MyWsdlRouteBuilder`). So try to change `test` -> `t` and invoke it again, you should see following exception:

Review Comment:
   ```suggestion
   We can try to alter it to non-valid request (the validation is enabled with `schema-validation-enabled=true` in `org.acme.cxf.soap.wsdl.MyWsdlRouteBuilder`). 
   For example, you can change `test` to `t`.
   Once you invoke the service again, you should see the following exception:
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).

Review Comment:
   ```suggestion
   NOTE: Most modern IDEs will be able to discover the generared classes automatically. 
   You may want to check some occurrences of those in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`.
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.

Review Comment:
   ```suggestion
   The customer web service is exposed via Camel route endpoint `cxf:bean:customer`. 
   Its logic is implemented directly in the route by delegating to `org.acme.cxf.soap.wsdl.repository.CustomerRepository`.
   The endpoint supports two SOAP operations: `getCustomersByName` and `updateCustomer`.
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).

Review Comment:
   ```suggestion
   The "WSDL first" approach presupposes writing the link:src/main/resources/wsdl/CustomerService.wsdl[WSDL file] manually at the beginning of the SOAP service design.
   Then we can use link:pom.xml#L231[the `generate-code` goal] of `quarkus-maven-plugin` to generate the Java classes for us. 
   The `wsdl2java` tool is used under the hood and its configuration can be found in link:src/main/resources/application.properties#L28-L29[application.properties].
   ```
   
   One sentence per line makes it easier to review and to track changes. 



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).
+
+The exposed contact web service will enable five operations - _addContact_, _getContact_, _getContacts_, _updateContact_, _removeContact_.
+
+TIP: If you would like to only generate WSDL from Java, you can follow https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-wsdl-from-java.html.

Review Comment:
   ```suggestion
   TIP: If you would like to only generate WSDL from Java, you can follow the https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-wsdl-from-java.html[WSDL from Java] chapter of Quarkus CXF documentation.
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).
+
+The exposed contact web service will enable five operations - _addContact_, _getContact_, _getContacts_, _updateContact_, _removeContact_.
+
+TIP: If you would like to only generate WSDL from Java, you can follow https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-wsdl-from-java.html.
+
+---

Review Comment:
   What is the purpose of this `---`?



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).
+
+The exposed contact web service will enable five operations - _addContact_, _getContact_, _getContacts_, _updateContact_, _removeContact_.
+
+TIP: If you would like to only generate WSDL from Java, you can follow https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-wsdl-from-java.html.
+
+---
+=== Binding (Advanced)
+
+For illustrating how other `wsdl2java` options could be applied to `quarkus.cxf.codegen.wsdl2java.additional-params` we have added `src/main/resources/binding.xml` which enables us to use `LocalDate` (more common in Java world) instead of default XML Date representation `XMLGregorianCalendar`. But in terms of this quickstart, it is not important at all and we could work with `XMLGregorianCalendar` as well.

Review Comment:
   ```suggestion
   For illustrating how other `wsdl2java` options could be applied via `quarkus.cxf.codegen.wsdl2java.additional-params`, we have added a custom binding defined in `src/main/resources/binding.xml`. 
   It instructs CXF to use `LocalDate` (more common in Java world) instead of default XML Date representation `XMLGregorianCalendar`. 
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).
+
+The exposed contact web service will enable five operations - _addContact_, _getContact_, _getContacts_, _updateContact_, _removeContact_.
+
+TIP: If you would like to only generate WSDL from Java, you can follow https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-wsdl-from-java.html.
+
+---
+=== Binding (Advanced)
+
+For illustrating how other `wsdl2java` options could be applied to `quarkus.cxf.codegen.wsdl2java.additional-params` we have added `src/main/resources/binding.xml` which enables us to use `LocalDate` (more common in Java world) instead of default XML Date representation `XMLGregorianCalendar`. But in terms of this quickstart, it is not important at all and we could work with `XMLGregorianCalendar` as well.
+
+== Start in the Development mode
+
+[source,shell]
+----
+$ mvn clean compile quarkus:dev
+----
+
+The above command compiles the project, starts the application and lets the Quarkus tooling watch for changes in your
+workspace. Any modifications in your project will automatically take effect in the running application.
+
+To start playing with the example, go to section `Local playground`.
+
+TIP: Please refer to the Development mode section of
+https://camel.apache.org/camel-quarkus/latest/first-steps.html#_development_mode[Camel Quarkus User guide] for more details.
+
+== Playground [[playground]]

Review Comment:
   ```suggestion
   [[playground]]
   == Playground
   ```



##########
cxf-soap/README.adoc:
##########
@@ -0,0 +1,197 @@
+= Camel Quarkus CXF SOAP example
+:cq-example-description: An example that shows how to use Camel CXF SOAP component.
+
+{cq-description}
+
+In this example we will create two SOAP webservices with two different approaches. Both services will use Camel routes as service implementation exposed via CXF component.
+
+== WSDL first
+
+"WSDL first" approach assumes writing WSDL file manually at the beginning of SOAP service design (such wsdl can be found at `src/main/resources/wsdl/CustomerService.wsdl`). Then we can use the _quarkus-maven-plugin_ and its _generate-code_ goal (see `pom.xml`) which will generate Java classes for us. To configure the plugin, see `src/main/resources/application.properties` file (properties started with `quarkus.cxf.codegen.wsdl2java` prefix).
+
+The customer web service will be exposed via Camel route endpoint `cxf:bean:customer` and its logic implemented directly in the route with the help of `org.acme.cxf.soap.wsdl.repository.CustomerRepository`. It will enable two operations - _getCustomersByName_ and _updateCustomer_.
+
+NOTE: Generated classes can be directly used in your IDE (you can see usage eg. in `org.acme.cxf.soap.wsdl.repository.CustomerRepository`).
+
+TIP: More info about generating Java classes from WSDL can be found at https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/first-soap-client.html#wsdl2java.
+
+== Java first
+
+On the other hand if we don't have the WSDL file, we can create SOAP service directly from Java interface (see `org.acme.cxf.soap.pojo.service.ContactService`) which is then processed by CXF (will create WSDL file as a benefit - how to obtain it will be shown later) and from that point we can implement the service in Camel fashion (see `org.acme.cxf.soap.pojo.MyPojoRouteBuilder`) as with "WSDL first" approach (but here we implement the logic in bean service - see `org.acme.cxf.soap.pojo.service.impl.ContactServiceInMemoryImpl` and not directly in route).
+
+The exposed contact web service will enable five operations - _addContact_, _getContact_, _getContacts_, _updateContact_, _removeContact_.
+
+TIP: If you would like to only generate WSDL from Java, you can follow https://quarkiverse.github.io/quarkiverse-docs/quarkus-cxf/dev/user-guide/generate-wsdl-from-java.html.
+
+---
+=== Binding (Advanced)
+
+For illustrating how other `wsdl2java` options could be applied to `quarkus.cxf.codegen.wsdl2java.additional-params` we have added `src/main/resources/binding.xml` which enables us to use `LocalDate` (more common in Java world) instead of default XML Date representation `XMLGregorianCalendar`. But in terms of this quickstart, it is not important at all and we could work with `XMLGregorianCalendar` as well.
+
+== Start in the Development mode
+
+[source,shell]
+----
+$ mvn clean compile quarkus:dev
+----
+
+The above command compiles the project, starts the application and lets the Quarkus tooling watch for changes in your
+workspace. Any modifications in your project will automatically take effect in the running application.
+
+To start playing with the example, go to section `Local playground`.
+
+TIP: Please refer to the Development mode section of
+https://camel.apache.org/camel-quarkus/latest/first-steps.html#_development_mode[Camel Quarkus User guide] for more details.
+
+== Playground [[playground]]
+
+We can first try to add some contact with:
+[source,shell]
+----
+curl -X POST -H "Content-Type: text/xml;charset=UTF-8" -d @src/main/resources/requests/contact/add.xml http://localhost:8080/cxf/services/contact
+----
+Then verify it was added with:
+[source,shell]
+----
+$ curl -X POST -H "Content-Type: text/xml;charset=UTF-8" -d @src/main/resources/requests/contact/getAll.xml http://localhost:8080/cxf/services/contact
+----
+Which should return:
+
+[source,xml]
+----
+<soap:Envelope
+	xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
+	<soap:Body>
+		<ns2:getContactsResponse
+			xmlns:ns2="http://camel.apache.org/test/ContactService">
+			<return>
+				<contacts>
+					<name>Lukas</name>
+					<address>
+						<city>New York</city>
+						<street>Sky 1234</street>
+					</address>
+					<type>PERSONAL</type>
+				</contacts>
+			</return>
+		</ns2:getContactsResponse>
+	</soap:Body>
+</soap:Envelope>
+----
+
+We can also test our customer service:
+
+[source,shell]
+----
+$ curl -X POST -H "Content-Type: text/xml;charset=UTF-8" -d @src/main/resources/requests/customer/getByName.xml http://localhost:8080/cxf/services/customer
+----
+
+You can observe that we have hardcoded `test` name at SOAPBody part in `src/main/resources/requests/customer/getByName.soap` as follows:
+[source, xml]
+----
+<cus:getCustomersByName>
+    <name>test</name>
+</cus:getCustomersByName>
+----
+
+We can try to alter it to non-valid request (validation is enabled with `schema-validation-enabled=true` at `org.acme.cxf.soap.wsdl.MyWsdlRouteBuilder`). So try to change `test` -> `t` and invoke it again, you should see following exception:
+
+[source, xml]
+----
+<soap:Envelope
+	xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
+	<soap:Body>
+		<soap:Fault>
+			<faultcode>soap:Client</faultcode>
+			<faultstring>Unmarshalling Error: cvc-minLength-valid: Value 't' with length = '1' is not facet-valid with respect to minLength '2' for type '#AnonType_namegetCustomersByName'. </faultstring>
+		</soap:Fault>
+	</soap:Body>
+</soap:Envelope>
+----

Review Comment:
   Narrower indentation please 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org