mirror of
https://github.com/jlengrand/quarkus-workshop.git
synced 2026-03-10 08:41:21 +00:00
more fixes
This commit is contained in:
@@ -80,7 +80,7 @@ Compared to vanilla JAX-RS, with Quarkus there is no need to create an `Applicat
|
||||
|
||||
## Running the Application
|
||||
|
||||
Now we are ready to run our application. In Che, select the _Command Palette_ by clicking on its icon in the upper right, and double-click on **Build and Run Locally**:
|
||||
Now we are ready to run our application. In Che, select the _Command Palette_ by clicking on its icon in the upper right, and double-click on **Start Live Coding**:
|
||||
|
||||
image::runlocally.png[runlocal,800]
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
= Dependency Injection
|
||||
:experimental:
|
||||
|
||||
In the previous step you created a basic RESTful Java application with Quarkus. In this step we'll add a custom bean using dependency injection (DI). Quarkus DI solution is based on the http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html[Contexts and Dependency Injection for Java 2.0 specification,target=_blank]. However, it is not a full CDI implementation verified by the TCK. Only a subset of the CDI features is implemented - see also the https://quarkus.io/guides/cdi-reference#supported_features[list of supported features, target=_blank] and the https://quarkus.io/guides/cdi-reference#limitations[list of limitations, target=_blank].
|
||||
In the previous step you created a basic RESTful Java application with Quarkus. In this step we'll add a custom bean using dependency injection (DI). Quarkus DI solution is based on the http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html[Contexts and Dependency Injection for Java 2.0 specification,target=_blank]. Because of the dynamic nature of some CDI APIs which conflict with native compilation, only a subset of the CDI features are implemented - see also the https://quarkus.io/guides/cdi-reference#supported_features[list of supported features.
|
||||
|
||||
== Add Custom Bean
|
||||
|
||||
@@ -62,7 +62,7 @@ If you do not get red squigglies, or you can't make them disappear, try to close
|
||||
|
||||
== Run the app
|
||||
|
||||
Once again, run the app in _dev_ mode by using the command palette and selecting **Build and Run Locally**.
|
||||
Once again, run the app in _dev_ mode by using the command palette and selecting **Start Live Coding**.
|
||||
|
||||
== Inspect the results
|
||||
|
||||
|
||||
@@ -33,7 +33,7 @@ This will add the extension below to your `pom.xml`:
|
||||
</dependency>
|
||||
----
|
||||
|
||||
Next, Run the app once more by using the command palette and select **Build and Run Locally** to start the app up in dev local mode. With no code, Quarkus still provides a default health check which may be enough for you if all you need is to know the app started. Try to access the `/health` endpoint on the Terminal:
|
||||
Next, Run the app once more by using the command palette and select **Start Live Coding** to start the app up in dev local mode. With no code, Quarkus still provides a default health check which may be enough for you if all you need is to know the app started. Try to access the `/health` endpoint on the Terminal:
|
||||
|
||||
[source, sh, role="copypaste"]
|
||||
----
|
||||
@@ -405,7 +405,7 @@ curl http://localhost:8080/hello
|
||||
|
||||
produces `hello quarkus!`.
|
||||
|
||||
Next, kbd:[CTRL+C] it (or close the "Build and Run Locally" Terminal window). We need to re-build the app as an executable JAR so it runs with the `prod` profile.
|
||||
Next, kbd:[CTRL+C] it (or close the "Start Live Coding" Terminal window). We need to re-build the app as an executable JAR so it runs with the `prod` profile.
|
||||
|
||||
Build an executable JAR just as before using the command palette and choosing **Create Executable JAR**.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ Debugging is an art of finding errors (bugs) and eradicating (debug) them from a
|
||||
|
||||
Let's introduce a subtle off-by-one bug in our application and use the debugger to debug it.
|
||||
|
||||
Open up the `GreetingResource.java` class again, and add another RESTful interface to that returns the last letter in a name:
|
||||
Open up the `GreetingResource.java` class again, and add another RESTful endpoint that returns the last letter in a name:
|
||||
|
||||
[source, java, role="copypaste"]
|
||||
----
|
||||
|
||||
@@ -40,7 +40,7 @@ We're using the _Axle_ variant here, which provides good support for async opera
|
||||
|
||||
== Run the app
|
||||
|
||||
Next, Run the app once more by using the command palette and select **Build and Run Locally** to start the app up in dev local mode.
|
||||
Next, Run the app once more by using the command palette and select **Start Live Coding** to start the app up in dev local mode.
|
||||
|
||||
== Create RESTful resource
|
||||
|
||||
|
||||
@@ -76,7 +76,7 @@ This will add the necessary entries in your `pom.xml` to bring in the Metrics ca
|
||||
|
||||
== Start the app
|
||||
|
||||
Next, Run the app once more by using the command palette and select **Build and Run Locally** to start the app up in dev local mode.
|
||||
Next, Run the app once more by using the command palette and select **Start Live Coding** to start the app up in dev local mode.
|
||||
|
||||
== Test Metrics endpoint
|
||||
|
||||
@@ -192,18 +192,19 @@ You'll need to trigger the methods that we've instrumented, so first run this co
|
||||
echo http://$(oc get route people -o=go-template --template={% raw %}'{{ .spec.host }}'{% endraw %})/names.html
|
||||
----
|
||||
|
||||
Within a few seconds, Prometheus should start scraping the metrics. Run this command to output the URL to the Prometheus GUI:
|
||||
Within about 15-30 seconds, Prometheus should start scraping the metrics. Run this command to output the URL to the Prometheus GUI:
|
||||
|
||||
[source,sh,role="copypaste"]
|
||||
----
|
||||
echo http://$(oc get route prometheus -o=go-template --template={% raw %}'{{ .spec.host }}'{% endraw %}')
|
||||
----
|
||||
|
||||
Open a separate browser tab and navigate to that URL. You should see:
|
||||
Open a separate browser tab and navigate to that URL. This is the Prometheus GUI which lets you issue queries to retrieve metrics Prometheus has gathered. Start typing in the query box to look for 'acme':
|
||||
|
||||
::img
|
||||
|
||||
This is the Prometheus GUI which lets you issue queries to retrieve metrics Prometheus has gathered. Start typing in the box to look for 'acme':
|
||||
[NOTE]
|
||||
====
|
||||
If you do not see any `acme` metrics when querying, wait 15 seconds, reload the Prometheus page, and try again. They will eventually show up!
|
||||
====
|
||||
|
||||
image:prom.png[Prometheus,800]
|
||||
|
||||
@@ -231,7 +232,13 @@ image::https://grafana.com/api/dashboards/3308/images/2099/image[Grafana dashboa
|
||||
|
||||
== Extra Credit after this workshop
|
||||
|
||||
If you have time after completing this workshop, try running grafana and hooking it up to your Prometheus instance you've created. Hint: `oc new-app grafana/grafana && oc expose svc/grafana` and then access Grafana at the URL emitted by this command: `echo http://$(oc get route grafana -o=go-template --template={% raw %}'{{ .spec.host }}'{% endraw %})`, add Prometheus as a data source at `http://prometheus:9090`, and create a custom dashboard showing some of your application metrics, or import an existing dashboard from the Grafana community.
|
||||
If you have time after completing this workshop, try running grafana and hooking it up to your Prometheus instance you've created. Here's the cheat sheet:
|
||||
|
||||
. `oc new-app grafana/grafana && oc expose svc/grafana`
|
||||
. Access Grafana at the URL emitted by this command: `echo http://$(oc get route grafana -o=go-template --template={% raw %}'{{ .spec.host }}'{% endraw %})`
|
||||
. Login as `admin/admin` (your lab username won't work!)
|
||||
. Add Prometheus as a data source at `http://prometheus:9090`
|
||||
. Create a custom dashboard showing some of your application metrics, or import an existing dashboard from the Grafana community.
|
||||
|
||||
== Cleanup
|
||||
|
||||
|
||||
@@ -19,12 +19,12 @@ If your application is still running from the previous exercise, go back to its
|
||||
|
||||
[source,sh,role="copypaste"]
|
||||
----
|
||||
mvn quarkus:add-extension -Dextensions="openapi"
|
||||
mvn quarkus:add-extension -Dextensions="openapi,swagger"
|
||||
----
|
||||
|
||||
This will add the extension to our project.
|
||||
This will add the necessary extension for using OpenAPI, and a graphical frontend extension called `swagger` which we'll discuss later.
|
||||
|
||||
Run the project again, using the command palette and selecting **Build and Run Locally** (if you had a previous app running, kbd:[CTRL+C] or close the old Terminal before running it again). This will again run our app. Once it's up and running, access the new `openapi` endpoint using the following command in a Terminal:
|
||||
Run the project again, using the command palette and selecting **Start Live Coding** (if you had a previous app running, kbd:[CTRL+C] or close the old Terminal before running it again). This will again run our app. Once it's up and running, access the new `openapi` endpoint using the following command in a Terminal:
|
||||
|
||||
[source,sh,role="copypaste"]
|
||||
----
|
||||
@@ -86,8 +86,6 @@ So out of the box all your endpoints are fully documented and will be emitted in
|
||||
|
||||
When building APIs, developers want to test them quickly. Swagger UI is a great tool for visualizing and interacting with your APIs. The UI is automatically generated from your OpenAPI specification.
|
||||
|
||||
The Quarkus OpenAPI extension embeds a properly configured Swagger UI page.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
By default, Swagger UI is only available when Quarkus is started in _dev_ or _test_ mode.
|
||||
@@ -106,7 +104,7 @@ quarkus.swagger-ui.path=/my-custom-path
|
||||
----
|
||||
====
|
||||
|
||||
Since our app is already running, click on the _Preview URL_ shown at the top of the terminal (on the _Build and Run Locally_ tab). Then, add `/swagger-ui` to the end of the URL to access the Swagger UI and play with your API.
|
||||
Since our app is already running, click on the _Preview URL_ shown at the top of the terminal (on the _Start Live Coding_ tab). Then, add `/swagger-ui` to the end of the URL to access the Swagger UI and play with your API.
|
||||
|
||||
image::swagger.png[swagger,600]
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ With Panache, we took an opinionated approach to make hibernate as easy as possi
|
||||
|
||||
* By extending `PanacheEntity` in your entities, you will get an ID field that is auto-generated. If you require a custom ID strategy, you can extend `PanacheEntityBase` instead and handle the ID yourself.
|
||||
|
||||
* By using Use public fields, there is no need for functionless getters and setters (those that simply get or set the field). You simply refer to fields like `Person.name` without the need to write a `Person.getName()` implementation. Panache will auto-generate any getters and setters you do not write, or you can develop your own getters/setters that do more than get/set, which will be called when the field is accessed directly.
|
||||
* By using Use public fields, there is no need for functionless getters and setters (those that simply get or set the field). You simply refer to fields like `person.name` without the need to write a `person.getName()` implementation. Panache will auto-generate any getters and setters you do not write, or you can develop your own getters/setters that do more than get/set, which will be called when the field is accessed directly.
|
||||
|
||||
* The `PanacheEntity` superclass comes with lots of super useful static methods and you can add your own in your derived entity class, and much like traditional object-oriented programming it's natural and recommended to place custom queries as close to the entity as possible, ideally within the entity definition itself. Users can just start using your entity `Person` by typing `Person`, and getting completion for all the operations in a single place.
|
||||
|
||||
@@ -21,7 +21,7 @@ You may have wondered why we are using `people` in our Java APIs, and now you'll
|
||||
|
||||
[source,sh,role="copypaste"]
|
||||
----
|
||||
mvn quarkus:add-extension -Dextensions="panache, h2, postgresql, resteasy-jsonb"
|
||||
mvn quarkus:add-extension -Dextensions="panache, h2, jdbc-postgresql, resteasy-jsonb"
|
||||
----
|
||||
|
||||
We'll use the in-memory H2 database for local testing, and Postgres when we deploy to our production Kubernetes environment. So that's why we have added in the `h2` and `postgresql` extensions. `resteasy-jsonb` is used to encode JSON objects.
|
||||
@@ -181,7 +181,7 @@ These statements will add some fake people to our database on startup.
|
||||
|
||||
== Run the application
|
||||
|
||||
Now we are ready to run our application. Using the command palette, select **Build and Run Locally** (if you had a previous app running, kbd:[CTRL+C] or close the old Terminal before running it again). You should see a bunch of log output that ends with:
|
||||
Now we are ready to run our application. Using the command palette, select **Start Live Coding** (if you had a previous app running, kbd:[CTRL+C] or close the old Terminal before running it again). You should see a bunch of log output that ends with:
|
||||
|
||||
[source, none]
|
||||
----
|
||||
|
||||
@@ -179,7 +179,6 @@ public class GreetingServiceTest {
|
||||
|
||||
@Test
|
||||
public void testGreetingService() {
|
||||
LOGGER.info("greeting: " + service.greeting("Quarkus"));
|
||||
Assertions.assertTrue(service.greeting("Quarkus").startsWith("hello Quarkus"));
|
||||
}
|
||||
}
|
||||
|
||||
@@ -56,7 +56,7 @@
|
||||
},
|
||||
{
|
||||
"commandLine": "mvn clean compile quarkus:dev -f ${current.project.path}",
|
||||
"name": "Build and Run Locally",
|
||||
"name": "Start Live Coding",
|
||||
"type": "custom",
|
||||
"attributes": {
|
||||
"goal": "Run",
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
},
|
||||
{
|
||||
"commandLine": "mvn clean compile quarkus:dev -f ${current.project.path}",
|
||||
"name": "Build and Run Locally",
|
||||
"name": "Start Live Coding",
|
||||
"type": "custom",
|
||||
"attributes": {
|
||||
"goal": "Run",
|
||||
|
||||
@@ -256,6 +256,10 @@ SSO_TOKEN=$(curl -s -d "username=${KEYCLOAK_USER}&password=${KEYCLOAK_PASSWORD}&
|
||||
curl -v -H "Authorization: Bearer ${SSO_TOKEN}" -H "Content-Type:application/json" -d @../files/quarkus-realm.json \
|
||||
-X POST "http://keycloak-che.${HOSTNAME_SUFFIX}/auth/admin/realms"
|
||||
|
||||
## MANUALLY add ProtocolMapper to map User Roles to "groups" prefix for JWT claims
|
||||
echo "Keycloak credentials: $KEYCLOAK_USER / $KEYCLOAK_PASSWORD"
|
||||
echo "URL: http://keycloak-che.${HOSTNAME_SUFFIX}"
|
||||
|
||||
# Create Che users, let them view che namespace
|
||||
for i in {1..$USERCOUNT} ; do
|
||||
# oc adm policy add-role-to-user view user${i} -n che
|
||||
|
||||
Reference in New Issue
Block a user