 Hi everybody, welcome back another technical demo around JVOS EAP and Micro Profile. I am Daniel Oh, let's get started. This video showcases how to build the boot-over jar with the JVOS EAP Micro Profile 2.0. This is a new feature of JVOS EAP Micro Profile 2.0. Let's jump into the demo. So we're going to use the EGGISTING in Thontail application. As you can see, there are a few Java classes already implemented. When you go to pomex.ml, you can find out the Thontail definition in your Mabel project. You're going to package this application's wall file as your application artifact. And you can see the Thontail version, the 272.0, the final, the latest version of the Thontail application, which allows you to build and deploy jacar.ee or java.ee in a project application with a small memory footprint and fast way. So here are just a few dependencies to use JaxRS to explore the RESTful API. Also, use Micro Profile Health specification to monitor your application status, like libraries, readiness. Specifically, it's really beneficial to use this capability on top of the Kubernetes cluster, like an upper-shift container platform. All right, move on to take a look at the actual Java application implementation. Here is the RESTful API application. Return output code, the JSON output. And the RESTful API is a greeting. And also, you can pass down the parameter key. It's a name and a variable, something any keyword. But the default value is a word. So just like a hello world application. When you go to the application configure Java file, you can find the contextual root to access to this RESTful API-API. And then we already implemented one of the Hashtag applications for liveness status. As you can see, when you access liveness status endpoint, you can just find out the output with the fruit bar is a dummy output as JSON format. Okay, move on. Try to run this application, use your main program, phone tail color, run. And then it takes a few seconds to start out and then packaging one file and to run this application within the phone tail. And try to access the endpoint, 88 slash API slash greeting with the parameter, just hello world with the default value. And then when you add a parameter like a phone tail API, and then we have got the return JSON file, hello comma phone tail API. Pretty cool. And try to access one more to find out the status of this application for liveness. And go to 88 slash health dash slash live and then you can find the dummy output when you access to status. You can actually specify and implement your actual application liveness. Okay, let's try to migrate this application to bootable jar based on micro profile 2.0 based on JVS EAP. In order to do that, we're going to change the version based on micro profile 2.0 GA version. And then we needed to add a few properties to use dependency from micro profile and JVS EAP. So for example, you can see JVS 734 version properly and also micro profile bomb valuable like 2.0 and also there are G-Cube maybe a programming version because we're going to use J-Cube tool to packaging and containerize images and deploy this application to Kubernetes and which container platform instead using Fabricate, which is a duplicate in the previous version. Alright, so one of us using operator openJDK11 as a base image to build this application. So we don't need to use a thong tail bomb dependence any longer. So that's why we need to add a new dependency management dependency based on JVS EAP with some two dependency and also JVS EAP micro profile bomb dependence as well. Okay, let's replace the existing thong tail dependencies here for several JXRF and micro profile health. Just comment these dependencies and then add a new one from the jacari.ee micro profile specification. For example, you can find that jacari.ee enterprise CDI API for Raspberry API implementation and processing JSON output and also a micro profile health specification. And last step, we need to redefine the build and profile to use micro profile sp2.0. So we just define two different profiles, first of all, globaljar and this is an implement based on Galion packaging feature. You can define multiple Galion layers like JXRF server and micro profile platform or single sign decorator, et cetera. And another profile is for deployment to upload ship based on JQ. So this profile will package its application and to deploy the container platform. All right, so try to package its application using globaljar profile. It takes a few seconds on normally, but depends on how many application you have. Let's go to take a look at that target territory. Now we have a globaljar here, XP20-demo-2.OGA-buildablejar. Try to run this application just using Java command line. So Java.jar and this globaljar, as you can see, enemy console is not enabled for this beautiful jar. All right, to access endpoint as the same we did in the Thontail, we got a same result like a hello world and API with a parameter named like a globaljar with the XP20.O and then we will find out the same result. And then let's try to add another specification for micro profile capability with the hashtag and config. So in order to add a new data connection hashtag, we need to implement the general hashtag classes. And also we need to inject the configuration capability or the micro profile specification using key database.up. And also we needed to access the actual database, but we just need to simulate database access configuration. But we, and also this hashtag for redness because we already like this hashtag status. So create a new micro profile dash computer profile to define database equals true, which you will be referring from the application side. Okay, we build this application once again and we run this application and now go to another terminal and try to access endpoint for hashtag. And but this is a base so it was EAP even though this is running on beautiful jar. So we need access to several elements for like a 9990 per. All right, it's pretty cool, pretty simple. So next step, we're going to deploy this application to the OpenShift Container platform. This is an empty project, which he doesn't implement any resources in this moment. So I just make sure to log in this project and try to maybe package it once again with different bootable jar OpenShift profile and add the command OC colon deploy. This argument allows us to deploy this application to OpenShift using OpenShift Maven plugin. In the meantime, when you go to target directory, you can find that OpenShift Manifest already generated automatically under the classic directory and JQ and OpenShift YAML file You can also have separate Manifest resources to file like a deployment company while YAML file and service. When you take a look at that OpenShift YAML file, there are already defined multiple resources for example service and deployment company, how to deploy this application using JQ with specified container name and specific Perl like Prometheus 9779 or Jolokia Perl and just HTTP Perl as well. And the ready is probably here based on actually the health and ready default endpoint in a row resources to export your application by client. In the meantime, the OpenShift console and the application are already running out. Just try to add a new label in the meantime the JVolts and click on the pod view logs You can find that the admin console is not enabled just like a whistle in local environment and you go up the low file you can find that the buildable jar is running this application of container platform. Try to open your app, you can see GUI, the buildable jar and just invoke endpoint, just hello world just like we expected and try to add a new name like a micro profile to that O and invoke and a micro profile to that O, just hello world. Okay, thanks for watching, have a good rest of the day.