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-unsubscr...@camel.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
