You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/02-architecture.adoc
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@
6
6
= Architecture
7
7
8
8
The solution pattern leverages preconfigured, ready-to-use Quarkus and Spring Boot templates.
9
-
Those templates contains placeholders where code and configration just need to be copy-pasted from the legacy application.
9
+
Those templates contains placeholders where code and configuration just need to be copy-pasted from the legacy application.
10
10
11
11
12
12
== Common Challenges
@@ -40,11 +40,11 @@ Camel-based integration logic can be written in XML or Java, and can behave as a
40
40
41
41
The present demo will take a legacy API developed in JBoss Fuse 6.2 on Karaf, in Blueprint XML.
42
42
It's suggested that such an application targets the Quarkus runtime.
43
-
The provided Quarkus template is 100% compatible with Camel K, so the resutling migrated application is immediately ready to be added to a serverless stack.
43
+
The provided Quarkus template is 100% compatible with Camel K, so the resulting migrated application is immediately ready to be added to a serverless stack.
44
44
45
45
The material can be used to migrate any Fuse 6 or 7 distribution to the Red Hat build of Apache Camel.
46
46
The demos will however focus on migrating a Fuse 6 application, and more concretely a Camel v2.17 one, in Blueprint XML format, running on Karaf 2. The XML format will be converted to the optimized IO XML one.
47
-
This path has been chosen for the demonstration because it can be considered the hardest one. Applications running on Fuse 7, no matter which distribution, could use the same approach and will bnefit from a shortest migration effort.
47
+
This path has been chosen for the demonstration because it can be considered the hardest one. Applications running on Fuse 7, no matter which distribution, could use the same approach and will benefit from a shortest migration effort.
48
48
49
49
In general, the following migration strategy should be considered:
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/03-demo.adoc
+12-11Lines changed: 12 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -48,7 +48,7 @@ Next, you can learn how to walkthrough this demo.
48
48
=== Before getting started
49
49
To try out, you'll need Maven, and it's best to have a Java 17 runtime. +
50
50
Maven needs to have access to the repository "https://maven.repository.redhat.com/ga/" for the dependencies. +
51
-
To make things easier, it's better to use a visual Java IDE, such as Eclipse, Vscode...
51
+
To make things easier, it's better to use a visual Java IDE, such as Eclipse, VS Code...
52
52
53
53
=== Setup
54
54
First, clone the repository: +
@@ -63,7 +63,7 @@ Enter the repository and switch to the 4.0 branch. +
63
63
==== Getting the source application
64
64
The demoed example is a migration of a CXF-based REST API implemented using FUSE 6 +
65
65
The source code of that legacy application in the /fuse6-apps directory, under /rest/claimdemo +
66
-
In the rest of the document, this location will be refered to as $SOURCE +
66
+
In the rest of the document, this location will be referred to as $SOURCE +
67
67
68
68
$ SOURCE=./fuse6-apps/rest/claimdemo
69
69
@@ -78,7 +78,7 @@ This application listens to API calls at http://localhost:8182/cxf/status/status
78
78
==== Identifying the target for the migration
79
79
The present document will describe how to migrate the application to the Camel Extension for Quarkus runtime. +
80
80
We'll therefore start with the template located in the templates/rest/ceq-xml-rest-app directory. +
81
-
For the rest of the document, this location will be refered to as $TARGET +
81
+
For the rest of the document, this location will be referred to as $TARGET +
82
82
83
83
$ TARGET=./templates/rest/ceq-xml-rest-app
84
84
@@ -92,6 +92,7 @@ Here below, we'll call this namespace 'claimdemo-migration'.
92
92
If you want to test the migrated application as a serverless component, you'll need an OpenShift server with Camel K installed. +
93
93
Install the Red Hat Camel K Operator to your OpenShift cluster.
94
94
Optionaly you can also deploy the OpenShift Serverless (Knative Serving and Knative Eventing) operators. +
95
+
95
96
Make sure you also have the kamel CLI on your local machine, and of the same version as the Camel K Operator. +
96
97
For clarity, we'll use a separate namespace for Camel K-related artefacts. Let's call it camel-migration. +
97
98
@@ -134,7 +135,7 @@ To complete it, proceed to follow the below steps.
134
135
135
136
$ cp -r $SOURCE/src/main/java $TARGET/src/main/
136
137
137
-
.. You can optionaly remove the Service interface, which is a class used specifically by the CXFRS framework, which is no longer the framework supporting REST API in Camel 3.
138
+
.. You can optionally remove the Service interface, which is a class used specifically by the CXFRS framework, which is no longer the framework supporting REST API in Camel 3.
@@ -155,8 +156,8 @@ Therefore, add the below annotation to that Java class:
155
156
+
156
157
[NOTE]
157
158
====
158
-
The Camel CXFRS component has been removed from Camel since v3. Camel now relies on the Camel REST component for the implementation of REST API endpoints. This provides separation of concerns between th REST interface and the REST implementation. It's recommended to generate the REST interface from an OpenAPI specification. +
159
-
Camel ships a Maven plugin to automate th creation of the required code from the openAPI document. +
159
+
The Camel CXFRS component has been removed from Camel since v3. Camel now relies on the Camel REST component for the implementation of REST API endpoints. This provides separation of concerns between the REST interface and the REST implementation. It's recommended to generate the REST interface from an OpenAPI specification. +
160
+
Camel ships a Maven plugin to automate the creation of the required code from the openAPI document. +
160
161
====
161
162
+
162
163
.. Copy the OpenAPI spec to the Maven project and run the Maven plugin. +
@@ -180,7 +181,7 @@ Camel ships a Maven plugin to automate th creation of the required code from the
180
181
<from id="_from4" uri="direct://getCustById"/>
181
182
182
183
. *Final consideration upon CXFRS*
183
-
.. The CXFRS library, based on the CXF framework initially designed for SOAP, made use of the saop-related "operationName" header to identify the target Java method to call. +
184
+
.. The CXFRS library, based on the CXF framework initially designed for SOAP, made use of the soap-related "operationName" header to identify the target Java method to call. +
184
185
This is not needed anymore, as the implementation now relies on the Camel REST library. +
185
186
.. To makes the application forward compatible to new clients, it's best to get rid of that header constraints. +
186
187
An easy (quick & dirty) way to do that is by replacing the condition in the camel route as follows:
@@ -217,11 +218,11 @@ To run it and test it on OpenShift:
217
218
$ cd -
218
219
219
220
220
-
==== Turning the migrated application into a CamCamel KelK serverless function
221
+
==== Turning the migrated application into a Camel K serverless function
221
222
The template makes use of the new IO XML format, which makes the migrated application immediately compatible with Camel K. +
222
223
223
-
As mentioned, with Camel K, the Java dependencies (custom Camel processor) need to be made externaly available, for example thanks to a Nexus repository +
224
-
To do that, you can use the helpers found in the Camel K template directory, which will be refered to as $CAMELK +
224
+
As mentioned, with Camel K, the Java dependencies (custom Camel processor) need to be made externally available, for example thanks to a Nexus repository +
225
+
To do that, you can use the helpers found in the Camel K template directory, which will be referred to as $CAMELK +
225
226
226
227
$ CAMELK=./templates/camelk
227
228
@@ -255,7 +256,7 @@ To do that, you first need to edit the pom.xml and correct the URL of the Nexus
255
256
You'll have to make sure that you have permission to write to the Nexus repository. +
256
257
This means you will need to make an authenticated call to the Nexus server. +
257
258
Credentials information are located in the settings.xml linked to your local Nexus (not the one we used to create a ConfigMap). +
258
-
Your local file sould contain a <server> entry with the exact same "id" as the one listed in the pom.xml +
259
+
Your local file should contain a <server> entry with the exact same "id" as the one listed in the pom.xml +
0 commit comments