 Když jsem si probrat, když jsi nějakou zátový můj lýbov, když jel apomatísýho, tak to bází. Tak tam tějí ty tyty, co by to asi mohli prožtít, tohoto výcoží, tak to se drobilo pál sávotný a pak se až vyšli na sluger, tam je co přespívat. Až mi sajde, že mám moc motivaci, když se to nějakou kavupací. a před head. Currently being well project lead, well is the reference implementation of CDI. So the topic is CDI and stands for context and dependence injection. It's not something like continuous delivery integration, whatever. So we are going to talk about components, about dependence injection and so on. However, today we are not going to cover any CDI basics or core features. Instead, I would like to show you how easy and efficient it is to use CDI container, in our case well, even outside the application service. So before we start, I only have few slides. So we have some example application prepared. I recommend you to either check out the repository, link is there. It's available at GitHub or browse it online. Yes, sorry. I will try to. So I recommend you to either check out the repository or browse it online, because it's always better to look at the code via laptop. And that's it. Now back to Agenda. We have four parts today. First, we will try to introduce the VELT AC Bootstrap API, because if you are using CDI outside the application server, the basic problem is how to start and stop the CDI container, so that you can use it. We will look into VELT AC Bootstrap API, which means we will not be using CDI portable API. The reason is that in all versions of VELT, old and stable versions of VELT do implement this API, whereas the portable API, which was introduced in CDI 2.0, is too hot, like CDI 2.0 is currently being reviewed by GCP, so it's not even released. Then I would like to show you how to make use of this API to test CDI components. When I say testing CDI components, I mean something like unit testing of CDI components, no integration testing. After both, I will try to show how CDI can cooperate with modern toolkates like Vertex. And finally, I will show you a development tool we have in VELT for developers to inspect the runtime of the application. So, as I said, the first thing we should do is to introduce the Bootstrap API. We have to start and stop the containers somehow. Those green lines are the simplest possible use case. The first line starts the container, and the second line stops the container. As you can see, there are two classes, well, specific classes. The first one is called VELT, which is actually not the best name, but we have to remain backward compatible and it's there for ages, so we can change it. This class is a kind of reusable builder, which is used to configure and start the container instance. And then, when you call the method initialize, you receive a wealth container instance, which represents running container. So, as I said before, we're going to walk through some code. So, in the repo, there are a few tests. All those tests are regular unit tests, and we're trying to use the VELT Bootstrap API to start a container, do some tests, and shut down it correctly. Before I start looking at the test, I'll show you a very simple application I prepared for today. So, the first thing we'll see is this interface. It's called whole service, and it has one default method, hello, with simple returns, a whole message. Then, we need some implementation of this interface, some being, which implements this interface. In our case, it's called event whole service, and it's using the default implementation of the hello method, but also fires an event whenever a unique, sorry, whenever a unique message is created, constructed. This is weird. Okay, I'll try to move slowly. Okay, so this is our implementation of the whole service, and we're just firing events. And then, we also have two more components. The first one is called console logger. Again, it's a very simple beat. We just define an observer method. This observer method simply observes all the messages fired and logs them to the console. And the last component we have is a little bit more interesting. It's a decorator. Maybe I should ask a question, how many of you do know something about CDI, actually? Yeah. Okay, not very much. Decorators are kind of interceptors, or AOP components, which intercept invocations of our components, but the difference is that decorators know something about the business logic of the component they intercept. In our case, our decorator implements a whole service, so it means that this method hello, we're actually intercepting the being method invocation, and in our case, we are just filtering out forbidden words. It means that if you pass something, we have some predefined forbidden words, and if you pass a forbidden word, then we replace it. That's all. And finally, we do call delegate. This is actually the being instance we are intercepting. Fine. Now back to the test. Let's look at the first method here. It's very simple. It's called the zero. On the first line, we are starting the container. Then we are... Then we are using our container to perform a programmatic hookup. This is a standard thing in CDI. You can either do add inject something, and the other approach is that you can do a more dynamic hookup of beads. So we just obtain a being instance, and then we do some assertion that when we call a whole service whole world, we receive a whole word message. And then we shut down the container. I have a comment there. As you all know, we'll see an issue with this approach of stopping the container. No. Well, if our assertion fails, then the container will not be shut down correctly, right? So this is not the best thing you can do. If you look at the second method we have here, which is testing... ...orbinway, it looks a little bit better, because world container also implements auto-closable, which means that you can use it with private resources block. So in the second case everything is okay, because once the private resources block completes, the container is automatically shut down. And then we have the last one. There's a little optimized, which is using some configuration methods here to configure a development instance for tests. In this case, we are disabling this camera, because we know that we only want to test a few classes, so we don't want it to perform discovery of binocaps and so on. So I can run the test, but we will not see that much, except that some messages are really here. Oops, what should I do? Yeah, you're back. Okay, now I'm back to the second topic, it's testing CDI components. In fact, you can test CDI components in several classes, but usually CDI components, or CDI beans, make use of some services provided by the container, like dependence injection events, interceptors, so on. So here is where we usually use mocking frameworks, but mocks for CDI components might get pretty complex, and sometimes it's even impossible to write a mock, for example, for decorators. So this approach and talking about is a little bit different. We start a CDI container with minimal configuration, and the benefits are that the container provided services are available. It's very fast and lively, and might be also combined with mocking frameworks. I'm going to show another example. In this case, I'm going to show a test for our decorator. As I said before, the decorator should just intercept the invocation, and if the name pass is forbidden, it should replace it. If you look at the test, we don't use the World SCB Strap API directly here. We're using a general test rule. This is a special test rule. We provide it in well, and what it does is that it starts and stops the container per test method execution. The advantage of this approach is that the configuration of the test is really minimal. In this case, I'm telling World to only scan those two classes. It's the HelloSeries decorator, and dummy HelloSeries. If I run the test, it should pass, first of all. Sorry. If you look at the console, there are no messages, because we did not include the console logger. So, it's testing CDI components. The next part, vertex. Vertex is modern and popular and so on. But sometimes, we might have some existing components on legacy business logic, let's say, and our mission is to reuse this logic with modern JVM toolkit like vertex. So, what we need to do is to start the CDI container somehow and stop it. And what we will do is also that we will use vertex web server and expose our HelloSeries. So, the next test, and it's actually the last one. This is a normal vertex test. We are using vertex unit driver. And if you look at the test, it's very simple. We use before and after methods, so we start a vertex instance. Then we deploy a special vertical. We show you later this vertical. And then in our test method, we are using rest assured working API just to test that if you call or if you do an HTTP cat request, we receive the correct answer. So, now, quick look at the vertical we have here. It looks complicated, but it's actually not very complicated. First of all, we need to start the weld somehow. So, we use an existing component we provide again in our VELT vertex extension. It's called VELT vertical. We deploy this vertical and if it succeeded, then we can be sure that the weld container is running. And the rest is actually not so interesting. We are using vertex web, which provides a router API. Then we again obtain our whole service, which is a bean instance. And then we register a blocking handler because CDI is usually blocking as most of the code. And we say that if the path starts with the hell of it, we will use our handler and actually we call our bean instance. And finally, we start the vertex web server. So, I'll run the test again. So, it takes a little bit longer because we are starting vertex also, but it seems that it works. Our VELT vertex extension allows to do much more, but I just wanted to show this simplest way of integrating those two different worlds, like vertex, asynchronous and reactive and so on. And CDI, which is perceived as a more legacy and synchronous code. And the last thing I'd like to show you is a special development, which we have in VELT. So, I created this main method, which actually does the same as the test. We run the vertex and deploy helloVertical. However, my run configuration also enables the development mode and we'll see what happens. So, run the application. If you look at the console where there is some warning about the development mode is enabled, that's cool. And now we will try to use our test, our application manually. So, I will just test it. Okay, fine. Also, we have a unique and a message generated. If I pass it again, it shouldn't be here. And because we have enabled the development mode, I can also inspect our default HTML client of the development tool. So, let me show you. Okay. As you can see, we have our vertex application. And it's this tool enables us to inspect our components in runtime, which means that we can look at the beans deployed. So, I can, for example, take a look at event whole service. This is our implementation. We can see that it has a decorator associated and so on. That's the first part. We have some basic monitoring features. Actually, we allow to see all the fired events and bean business method invocations. So, let me check the fired events. Okay, fine. We can see that because of our event is of type string and we can see the string directly. Let me try to use some forbidden word. Okay. And we can see that it was really fired event. And the last thing, the last thing, yeah, we're out of time. This is the second thing I was talking about. It's monitoring invocations of beans. So, we can see that event whole service bean was involved three times. And if you look at the detail, we can see that some basic information about the invocation, for example, that this invocation cost an observer method to be fired. So, that's it. We are out of time. Thanks for your attention and if you have any questions. Yeah. Yeah. This development tool is actually part of Wi-Fi already. What we have seen right now was a special not vertex version because normally you need some, there is some REST API and the default client just ask for data. Ask for data and normally we use servat, some kind of REST API everything in servat and in this case there are no servats of course because we are on vertex so there are some vertex members. Yes. It's available there. Sorry. How do I compare CDI in spring? That's yeah. That's more like a question when discussing over beer or so because I think it's out of the scope of this presentation but we can discuss later.