 Hello everyone. Welcome to this presentation about Tomcat and the ecosystem in Apache. So, the agenda quickly. So, we'll start from Tomcat. I'll present you very, very quickly the Java ecosystem at Apache and why it makes sense to kind of put them together to do something else. Quickly, who am I? So, my name is Roman Manibuco. You can hear I'm French. Like anyone, I'm on social network, Twitter, GitHub, etc. We don't care much. I'm working mainly with Tomcat Drive these days. But before, I was working in big companies for bank insurance between ops and dev teams. And I have a blog about Javaii, web technologies, things like that. So, let's start about what's linked to Javaii at Apache. So, I try to put most of the project. I'm sure I forgot some of them. The main ones should be there. So, Beval for bin validation to validate objects in a standard way. OpenGPA, it is written for Java database binding. JeroNimo. So, on this slide, it is not the server which is kind of let's say dead. But there are a lot of utilities there. I'm thinking to Xbin to scan the class pass. There is a telnet implementation. Generic factory, a bit like Spring, but done differently. My face is for JSS. Johnson, it's what's about JSON, JSONP, JSONB. So, code JSON, streaming API, binding. Open web bins as a CDI implementation. So, BIOC. ActiveMQ, Artemis or just activeMQ for GMS. But she for Chebat. The cat, I think you know what it is. Microwave and Tommy for servers. And Delta Spike, I put it there because it is a companion of CDI applications. It's a set of extensions. So, it adds a lot of useful features. If we have time, I'll speak about them very quickly. So, we have a lot of e-stuff, but they are mainly done in parallel. So, we don't, we have libraries. We can say this way except for Tomcat, which is a server. So, in this talk now, I'll be more centered on Microwave and Tommy because it's servers using this whole stack more or less. So, a quick reminder about the ecosystem. So, something important happened with E6. So, it was a long time ago now. I think it was in 2000, something like that. So, they created what they called profiles. So, before you get a server, you get the full stack. You get some things like Kerba, you use every day, I'm sure. Remote eGB, things like that. So, they said, okay, we have a lot of legacy stuff now. Let's split the server more or less in two. So, just keep half of the specification and we get something else called the web profile. So, you can get the web profile server or a full profile server with everything. More recently, I don't recall if that's last year there before, but no more than that, my profile initiative was created. That's more or less everybody which is doing things around E, but Oracle. The goal was to kind of boost E8 which was not moving that fast, mainly because of Oracle. So, kind of say to Oracle, we don't need you, so do something. And it's not directly EE, but it's kind of part of the ecosystem Spring Boot. So, if you were there before, there was an awesome talk about it. It's mainly how to get a server in update mode with auto configuration, things like that. So, that's the big picture. So, now let's start with Tomy, what it is and what you can get grabbing it. So, in terms of goals, Tomy is targeting E specification, the real specification, not a subset of specifications. The E6 version is web profile certified by Oracle. So, it's officially compliant to the specification. We have also a JAX RS version which is certified. It's a kind of hybrid certified distribution for E6 because JAX RS was not yet in the web profile. It was added in E7, but we got it certified. And we have the last version actually which is E7, but not certified to summarize, it is for legal reasons. One key thing with Tomy is to be Tomcat based. So, if you start to use Tomy, you are used to Tomcat, you do something and it doesn't work, that's a bug. That's not something we don't support, that's a bug. One goal is to stay light. So, Tomy is coming from Open EGP project which was created in 1999, something like that. So, it's pretty old, but the goal was to be fast to show that E doesn't need to be super slow, like web sphere, web law, etc. So, Tomy keeps that. We are light, we start fast, etc. And we are kind of user driven. So, we do what we need for the specification, but if a user is coming and say, well, it doesn't fit my need, we need to make it more flexible or something like that, we do it as much as we can. So, I said Tomy is Tomcat. So, that's basically what you'll see if you grab a Tomy archive, you unzip it or untie it and you'll see a bin folder, a conf folder, a lib folder, etc. So, it looks like a Tomcat. If you dig a bit into the files, you'll see a few differences. So, of course, the lib folder is bigger because we have, I think, five times more specifications in the web profile. And, yeah, more in the full profile. We have Tomy.sh and Tomy.xml there, which are not in Tomcat, which are specific to Tomy. But globally, it looks like Tomcat. And if you want to start it, you'll run Catalina.sh or startup, depending on what you want to do. So, it's really Tomcat. So, I said we added Tomy.xml, but mainly to configure Tomy resources. So, why do we have this file and not context.xml or something like that? It's mainly because Tomy or OpenEGB Flavor was working without Tomcat. At the beginning, we had OpenEGB. It was a container, let's say, without the HTTP layer. And we emptied OpenEGB into Tomcat to get a full server. But the standalone mode without Tomcat was working. So, we inherited from this file for global resources and it brings a bit more power than Tomcat resources management. So, the syntax is globally XML with properties. So, that's kind of hybrid. The goal being to be readable. A resource defines an ID. That's what you will use in your application. If you have a persistent unit, for instance, you link the data source through a GNDI name. It's that ID. We support aliases. So, it means you can use multiple names for the same resource. So, that's useful for data sources or anything which has external connections because you can use the same pool. So, instead of having 10 times 50 connections to a data source, you can only get 50 connections. And then the properties are mainly the way the instance is created. So, we find the driver, the URL, etc., for the data source. What's interesting is we are supporting placeholders. So, that's the OpenShift values. For instance, they are read from system properties. So, we have a file called system properties or the JVM system properties and the environment. And another nice feature in particular for companies is the ciphering. So, you don't have to put clear values there. So, of course, if that's the validation query, I think you don't care putting it in clear, but the password, it's another stuff. So, you can encrypt and decrypt a value. So, that's where the tomi.sh can be useful because it exposes a main, reusing Tomcat class pass, a common loader to be concrete. And if you add there your implementation of the ciphering, you can use this implementation to encrypt the password. In this slide, I used static3ds. It's the default provided encryption. It's not very secured in the way it is in the server built-in and everybody has it, but it's just a method to implement to have your own. So, nothing really fancy. What do I forget? Yeah. So, data sources are something very important for a server. So, it's managed. That's like connection factories for GMS, et cetera. But let's say you are using Mongo, for instance, MongoDB or any NoSQL database. You can also use resources because there is a way to configure it saying I want to instantiate this class. Here are the properties or use the constructor or something like that. So, it's all built-in. The gain there is to be able to configure the resource outside the application and get it injected in the application through at resources or through initial context. It's created at the deploy time and that's a singleton. So, that's mainly resources, like the external resources. So, for data sources, we support them to be flushable. So, you can see at some point, okay, automatically through some configuration and hooks. This instance is no more valid, recreated. We can also support lazy instantiation. So, the server is starting. The resource is wired but not instantiated and it is done at the first used. But we don't have a flush for all resources. It's not built-in. If you want a custom resource, you can support it. But since you can inject it in your application, if you know when you need to recreate it, it's not a big deal to do it. Something important for resources is the fact you can kind of make them dynamic in the way you can configure a custom implementation to grab the properties. So, you get the resource and you fill the properties, if you want. So, you can read a custom configuration registry, for instance. And you have also the notion of templates. So, you say this resource is using this template, it automatically configures my resource. So, you fill the properties, the type, the class name, aliases, et cetera, everything. I think that's it for resources. So, what's the challenge with Tommy? Because it looks like we grabbed Tomcat. We have a bunch of libraries in lib folder and that's it. Actually, it's a bit more complicated because when you have two specifications, you often need to integrate them. So, one integration between two. But since we have between 14, I think, and 30 specifications, we don't have a single integration to write. And when you'll do, let's say, 10th integration, you'll break the first one, et cetera. So, it's really a lot of work to make all integrations working all together. And that's what is Tommy, actually, just glue code between all specifications. So, I think I have an example here. So, if we just take what micro profile is covering, we need a CDI implementation. Okay, that's easy. We grab open webbind. We need a JaxRS implementation. We grab CXF. But now you need to integrate CXF with CDI. For JaxRS to work, we need a servlet container, or at least with CXF. So, we'll grab Tomcat, but we need to integrate CDI with Tomcat, with servlets. Tomcat with JaxRS as well to deploy the right CXF servlet, et cetera. And then we'll add JSONP. And there, we need to ensure we get the right implementation when doing the lookup. So, we have the right context, class loader, et cetera. So, just for this simple example of four specs, we have like five or six integrations to do. So, don't think that's because you put it all together, it will work. And it will not be E. So, in terms of how you can get to me, we have mainly four or five ways. The first one is to get an archive of to me. So, on the download area of Papachi or Mavin Central, you can get the web profile distribution. You can get, so that's just the web profile, the plus distribution, which is kind of the full profile for us, all we can support. And there is a weird distribution, which is the red one, the plume one. So, it started when Glassfish was a bit less supported, let's say. And users started to want something else, more supported, more dynamic. And they tried to me. But one big difference between the two implementation Glassfish and Tommy is GPA and GSF implementation. So, Tommy is coming with OpenGPA and MyFaces. And Glassfish is coming with Morara and EclipseLink. And that's the two specifications, which are all but portable. So, we created a distribution of to me with Glassfish implementations for GPA and GSF. That's the plume distribution. And we have a burger. So, that's to represent the embedded fashion. So, you can get to me and did a full to me running in your in the same JVM and your test, your main or whatever. Or just open a GB. So, to me without Tomcat, which can sound weird. But you can test everything with that from JacksWS, GMS, etc. For this flavor, you can grab either another jar or just use my van or product to get the dependencies from central. So, in terms of tooling, to me is not bad, actually, because we are supported by most ideas. NetBeans and IntelliJ are using a kind of full integration with Tommy detect it is a server. Eclipse, we are relaying on WTP with the same pitfalls and the issue you can get with Tomcat because they are creating themselves a standard context, etc. So, when you are moving from Eclipse to production, you can get some surprises, but you can develop with it. What's interesting is the Maven integration. I speak a bit more about it in the next slide. So, we are fully Maven compliant because we are on Central, we deploy on Central, but we also write Maven plug-ins. And we have one Tommy on the plug-ins for Gradle, which allows to have the same kind of experience than with JT. So, let's dig a bit into Tommy Maven plug-ins. So, that's a plug-in managing remote Tommy. Remote means there a fork. It can be a remote instance, but it can also be a local one, but just a fork compared to Maven GVM. This plug-in is very interesting because it is fully customizable. You can configure which artifact you use as Tommy. So, that's the coordinates you get when you want to grab it on Central, for instance. So, they are just customized classifier. I want the plus distribution. I don't want the web profile one, which is the default. You can remote debug. So, we have a Maven Tommy debug command. You can customize the JVM arguments, the system properties, customize the configuration, libraries, web apps, et cetera. And these artifacts are using Maven coordinates, which is pretty nice. What is good with that is compared to an Eclipse setup, for instance, to develop, you will share the configuration and the setup of your Tommy instance in the project. So, if your colleague is doing a checkout of your project, then Maven package Tommy run, it will get the same configuration. You don't need to share an Eclipse WTP folder with the configuration and her enemy to explain how to setup Tommy. In particular, if you need to customize the instance with drivers or default web apps. And we have a Maven Tommy build command, which enables you to not run to me, but create an archive from this description and deploy it on the next user or something like that. So, you can create custom to me distribution just with that plugin. So, of course, there is a lot of configuration, but you can remove it all and it will start your project in a web profile to me. Before I switch to the next slide, we have a Tommy MD in Maven plugin, which is kind of inspired from JT. So, you can deploy your current project. You will get, of course, your classes, rest services, etc. But you can point to source main web app, for instance, for the resources and just hit F5 to hot reload your JavaScript development, for instance. So, now let's see what Tommy is providing you to test your application. So, we have three main ways. The first one is the application composer. The second one is Archelian. And the last one is a custom JNIT based solution. So, the application composer, it's quite old solution for the testing. Originally, it was just for us to be able to test the core feature of the server without having to deploy a full class path or things like that. The idea there is to say, you provide to the test framework what you want to deploy. So, the container will not scan to see what needs to be deployed. It will just grab the model you are providing. So, in the sample on the right, we can see I'm enabling a JAX-RS. I customize the JAX-RS providers I want and I list all classes I want to deploy. There is a shortcut to say I want to deploy current project or all JAX-RS matching this name, things like that, because it's easier when you have a big project, but the core idea is to list them there. What's nice is, in this example, it is a rule that it can be a runner if you don't need to composite with anything else. But if you need, the rule is doing that pretty well. So, in this example, for instance, I can start the SFTP server, start Cassandra because my application is using both. Let's say it is grabbing some data from the SFTP server and pushing them in Cassandra. And then I'm starting my container which can inherit from the data from the Cassandra rule and SFTP server rule and just use all three in the same GVM. A nice feature for Jenkins in particular is the support of random ports. So, you can inject generate random ports for all the open ports of your application, for instance, HTTP for JAX-RS there. But since it is embedded, you can also get injections. So, you see, you can test the client side of your application, but also the server side at the same time. And one nice thing coming from the fact you are controlling what's deployed is if you need to mock something, you just add the mock implementation in the list of deployed classes and that's it. So, for instance, if I need to mock an O2 server, I can implement it this way and just add it in the classes deployed and I'll get my O2 server deployed automatically. Then Arcilian, it's a framework pushed by Jebos. The overall idea is to say we have a runner, it manages the lifecycle of the container and of the deployment of an application. So, it looks like this. So, you have Arcilian runner, of course. You describe the application you want to deploy, a bit like the application composer, but it is using Schrinfrag, which is in memory representation of an arcade. And then you can execute your test either in the container so you can get injections or on the client side. And there is a warp extension if you want to mix both, but it's a bit more complicated. What's interesting there for Tommy is the configuration because it's pretty advanced. You can configure everything. So, I'll not detail the configuration because it is more or less the same as for the maven plugging. So, you can configure which libraries you put there, you add there, which web apps or applications you add, et cetera, system properties. One nice thing using Arcilian is the group support. So, what does it mean? It means you can test clustering. So, you can say, I have two Tomies. Here, the configuration for each of them, Arcilian will manage to start them both. And in the test, there is a way to say, I'm testing on this instance or this instance. So, if you want to test something related to the clustering or if you put a token in a distributed map, you can check it is working. And very quickly, we support two main other ways to test. We have a bit more, but it will be too long. So, on the right, we have a runner wrapping the EGB container, which is an API introduced with E6, able to deploy a class pass in a standard fashion. And there, you can also get injections in the test class. What's interesting there is if you write a main in your application based on the EGB container, which gives you all the e-power, basically, it will run the same way than in the test. So, that's interesting to have it if you write a batch or something like that. The one on the right is the Tomie-Andy single runner. So, I really like this one because, first, you can use exactly the same thing in a main, in a custom main running a plain Tomie. But also, it will start a single time container for all the tests. So, if you have 10 tests of one second and you need to start the container and it takes two seconds, it will be super long, but there you will gain 20 seconds. So, that's really interesting. Things to note is we supported most of the application composer annotations, even if a default mode, if you don't put classes, it will deploy the class pass. But we added the application composer API support. So, it starts a single time the container, so it needs to know what it needs to deploy because it can't use the test since all tests will share the same instance. That's why we have this application class describing what needs to be deployed. And the application class can get injections. And it also supports the random ports and things like that, like the application composer. And that's nice because if you are testing a REST API, for instance, you can inject the random port there. And you will do your client setup in the application class. And then in the test, you will inject your application class and use it as a base instead of creating a new client in each test with an O2 token or something like that. So, you can share some logic for all tests in the application. And just a side note, so here you can see I'm injecting some arcs. So, for a test, it doesn't mean much, even if there is a way to get something, but you can use to me on this single main, I think. Well, there is a main related to this feature, and you can inject the arcs of the main through this feature. So, I guess that's enough for Tommy, so he quickly lists some features we have, which are interesting and very specific. So, I spoke about tome.xml, and you saw there is this properties syntax, which is a bit weird. Actually, tome configuration is fully based on properties. So, all you can do in tome.xml, you can do it in properties file. That's interesting because it's easier to generate a properties file in any language if you have some provisioning tool. We support overriding of most configuration, including the MDBs. So, if you have some activation properties for your MDBs, you can switch the queue, the type of destination, etc., through system properties. We have some container events that extension points for the container, so you can know and observe an event, which means an application is deployed, and you can modify it. You can deploy resources at that time, inspecting the application, etc. So, it's really a way to extend the container and add features on them. I spoke about the resources. We have a reloadable persistence unit. So, when you have a persistence unit, we'll deploy it on GMX, and you can change the configuration through GMX. So, add properties, change the database, why not, etc., and reload it. So, it will recreate the persistence unit, but without breaking the links done during the deployment. So, your injections will still work. That's a nice feature if you are doing some benches, and you are adding some cache on GPI, for instance, because you don't need to restart, basically. We have ATEM bin APIs, so that's to expose through GMX some CDI bins directly. And closer to Tumcat, we have a lazy valve and a lazy real implementation. The goal is to enable an application to provide an implementation of a valve or real, even when the application is deployed, you don't have the web app class loader ready to load it. So, we are kind of providing a facade implementation, which will look at the application instance when available. So, we have, when we deploy, we support several other server descriptors. So, we support some of Glassfish, JBoss, what I think. So, it can work out of the box, depending on what you are using from JBoss. Otherwise, I know we have a plug-in for Eclipse, but I never use it, so I'm not sure what it will do. We got some migrations. The main differences were about the GNDI names and, yeah, environment more than the application itself. So, if it's not a JBoss 4 or 5, it should be fine to migrate. Like you mentioned, the GNDI namespecs for the UJB, but they have some properties and system of properties where you can modify the time you GNDI namespace to map to which you have your environment possible. Sometimes it works, sometimes it works, sometimes it works. So, let's speak very quickly about microwave because I'm light, it seems. So, let's bypass this one. So, microwave is really about making modern development easy and pre-set up. So, the target is the single page applications and the rest services. So, the scope in terms of stack is JacksRS and JSON. We don't care. I bypass this one. So, this slide, I don't want to dig into the API too much, but what I want to show with this slide is to start to microwave it one night. But it's also very customizable, so you can configure everything which is in the server. The port, what you scan, which is yours, but also which packages. Where do you read the configuration? JSON, P can be configured, etc. And you can also configure Tomcat, which realm you use, which valve or authenticator you are using, etc. The sign up about this is if you write a main, of course, you have a way coming from Tomcat to wait for the end of a given, but you can also write a key if you want that, which is pretty nice. So, we have a main provided what we call the key. The nice thing there is it is mapping one for one the configuration we had on the previous slide, so there are much more, but all the configuration you can access programmatically, you can access it through the key as well. So, if you write a standard JacksRS application, you can deploy it with a microwave key and just customize the server as much as you need. And the last note is we support the microwave that properties configuration to kind of embed the default setup. If you are using the same everywhere, you don't need to repeat yourself. In term of tool, kind of the same thing than for Tomy. It can be seen as the browser of Tomy because we just grabbed the best part of Tomy MD and extracted it in a later project. So, a gradle plugin supporting an MD instance, and Madden plugins supported to run Aladgeti, an instance, or to bundle. So, it creates a layout close to Tomcat, but adapted to microwave. So, that's one difference between microwave and Tomy. Tomy stays Tomcat in terms of layout and experience. Microwave is a bit different because it is based on Tomcat MD, so there is no Tomcat MD distribution, things like that. So, I'll go very quickly on the testing. So, there is a rule and a runner for microwave. There is a mono or not flavor to say it starts once for all the tests or per test. And you can access the configuration. So, for the rule, you can go get configuration and for the runner you can inject on a field in the test the configuration to access the port if you use a random port. We also have a set of extensions. So, Geolokia and Otaio, it will just deploy automatically Geolokia and Otaio on slash Otaio, if I recall correctly, to get GMX monitoring exposed to HTTP. It will reuse the main realm you put on microwave for the security. We have a light O2 server based only on safe implementation. We are just doing the glue code there. We have a GTI module, adding a transaction manager in CDI, just if you are doing some micro services with a GMS or something like that. And at unit, I'll speak about it after. Now, so what's interesting with microwave compared to Tomy is it brings a new programming model fully based on CDI. So, with Tomy, you need a data source, you'll configure it in Tomy.xml, and then in the persistence unit, you'll wire GenDI name. With microwave, you'll create your data source through a CDI bin. So, you can use the pool you want, you can manage the configuration the way you want. So, the configuration will be consistent with your application. And then you can produce a persistence unit info builder, which is provided by the extension, GPI extension. You wire the data source providing the instance, which is injected. And then you can write services and default interceptor will handle the transactions. So, what's important there is everything is CDI in microwave world versus there is a part managed by the container or not in Tomy world. I'll go very quickly on that. So, the goal there was to show you how to develop an application with microwave. So, the first step is to create your dependency stack. So, microwave and in this example, RAD4G. Then you do some blue code between the two. And the goal with RAD4G was to get graphs of monitoring. In terms of implementation, the interesting part is not what is on the right, but more what is on the left. It's just RAD4G code. There is no code to handle the serialization, no code to handle the HTTP routing, no code to handle all the technical stack is provided by the framework. So, that's what is really nice. If you don't do something, let's say enterprise or old style, you do something no SQL or very custom. It will make it really fast to develop your application. You are centered on your business. I passed this slide. So, it was just another example to say since some version of Tomcat, you can bypass connectors. So, that's what we do, keeping HTTP. And doing that, you can write batches or daemons with microwave as well. The main difference with the previous main I showed you, so bake await, will be the await strategy, will be custom. So, in this case, it was a J batch. The await will be just pulling the status of a batch which was launched at the container deployment. The gain there is you are using the same container and the same programming model for all your applications. You don't need to write a custom main or something like that. You reuse the exact same environment. So, you can mutualize a lot of things doing that. Okay, I'll pass that. So, it was a few slides on Delta Spike which is a companion of microwave. It is providing configuration, jamming support, kind of spring data for GPA, etc. So, then the question at this point is do you use to me or microwave? I'm tempted. So, I have a table but I don't have time to enter into the details. But globally, the outcome is use the one you are comfortable with in your environment. So, if you have an operation team, I think to me, fits better because you will be able to give them the control of the resources, of the configuration in a Tomcat way. But if you deploy through Docker or through a custom packaging, a microwave will be more powerful because you will control what you expose basically. So, it was the conclusion. So, you can choose the red or the black but it will lead to success in any case. I had just one slide about micro profile and spring boot. The goal of this slide was to say the mainstream now is to be embedded using flat class pass to deploy application and to have a kind of auto configuration. So, you add a jar and it is auto configuring the environment, etc. And even if E6 did it, it is just becoming mainstream with these two initiatives or projects, let's say, because it is made simpler to access for any developer. If you are not a developer, you can still do it. So, that's in this context, a microwave was created. I never said microwave was a micro profile server even if it could because technically it is targeting the same specification because today, micro profile is not a profile like Oracle profiles. There is no TCK. There is no way to validate your compliance. It's just some nuts on a paper. I'm not yet embracing micro profile, just a small warning. But the important part on this slide is the mainstream is clear and the future of the Java development, in my opinion, is kind of unified now. There is no more E and spring. It's the same thing. Thank you. If you have some questions very quickly, no question. He did a great job supporting the timing. Thank you. Well, it was a super response. Thank you. Thank you.