 Welcome everybody, this is the April 16th edition of the OpenShift Commons briefings. For those of you who don't know, the Commons is a gathering of ISPs, VARs, SSIs, customers, individual developers. Anybody interested in the OpenShift ecosystem who wants to contribute and be part of it can join the Commons and find out interesting topics where we're going and where we're headed. Today's briefing is about continuous development with Jay Rebel on OpenShift. We have Adam from Zero Turnaround here. You can see him on the video, and we have Arun from Red Hat. I'll hand it over to you, Adam. Thanks. I think actually Arun is going to be kicking us off. Yeah, sure. Absolutely. Thank you. Thank you. Well, as Mike said, it is about continuous development with Jay Rebel on OpenShift. So we should be able to show you the relevance of both Jay Rebel and OpenShift and how they work very well with each other. With that, Adam, your time. Yeah. So my name is Adam Koblenz. I'm the Product Marketing Manager for Jay Rebel at Zero Turnaround. I used to be a real professional developer. I actually wrote code for a living, one of those guys, at a large investment bank in the US. And then I made my way through to here where I helped bring awesome software to other developers that I wish I would have had when I was writing code. Now, Arun. Right. So my name is Arun Gupta. I work for Red Hat. I've spent good time at Sun and then Oracle. And now at Red Hat, I run their technical marketing and developer advocacy team. I love coding. I love coding. That's sort of my key part. I love coding every day. If I don't code, I can't sleep well. So I think that's what keeps me alive. Lots of different ways to reach out to me, Twitter, blog. I'm a compulsive blogger. I'm going to pretty much push out two blogs a week or so. And then you can send me an email at arungupta.redhat.com. So with that, let's move on to the next slide then. So today, what we're going to talk about is, you want to do continuous development. Now, in order to do continuous development, you need tools. The tool that we recommend for JBoss technology is JBoss Tools. It's a kind of intuitive name in that sense. Now, JBoss Tools is basically a set of Eclipse plugins for JBoss technology. Whether you want to build a mobile application using Aerogear, whether you want to do a full stack Java EE development, whether you want to use Wildfly as an application server, whether local or in the cloud, which is what we're going to talk about today, or you want to do Rooms development or Camel or Hibernate or Forge or CDI, all of those tools are available as part of the JBoss Tools. You can either have Eclipse with you and then install JBoss Tools in there, which is a set of Eclipse plugins, or you can download the JBoss Developer Studio, where these tools are prepackaged and a lot more easier for you to get that one bundle, where everything is seamlessly integrated. Of course, needless to say, JBoss Tools provide first class integration for OpenShift, and we'll talk about that in a second. Next slide. So, what is Wildfly? Well, Wildfly is Red Hat's open source Java EE7 compliant application server. It was released in February of last year, basically became Java EE7 compliant. That was Wildfly 8.0. 9.0 is coming later this year. In between, we have released 8.1 and 8.2. So there is a constant cadence of releases that is coming out of Red Hat. And in 9.0, again, we have some really cool features coming up like graceful shutdown, where your connections are not disturbed if you're initiated the shutdown process and making it a lot more modular. This is also the upstream version for JBoss EAP, which is a commercial edition, where you can get commercially supported for Wildfly. Now, JBoss EAP today is Java EE6 compliant, but the EAP7, which is coming out hopefully later this year, will be Java EE7 compliant. So you can build your application on Wildfly, deploy it, but if you need commercial support, you will have to wait for EAP7, which should be available in the next few months. And yeah, well, why would you go for commercial support? The typical reason our customers go for commercial support is you don't want to deploy anything on just pure open source, grab it from off the shelf and then deploy on it. You want a company to back it up specifically with if there's an issue with your application or your application server setup, security patches, updates. We do constantly monitor and provide updates on that. So as a commercial support, those are some of the biggest benefits that you get as part of the EAP. That's actually one of the reasons that I really like using Wildfly is that I know that when I want to put my application into production, I can reliably deploy it on a supported version of the same kind of platform. What we do with something like Tomcat or something, you're hoping that things are going to work out in production and hope you can find third party support and it's really a mess. That's a very relevant point because one of the key parts of this is the code base between Wildfly and EAP is pretty much same. And when I say pretty much, I really mean 99.9% same. At a given point of time, we say, okay, you know what Wildfly is pretty mature. It's got the features, it's got the production features that we want. We take it and we say, okay, now let's cut it into a Jbuzz EAP. We run some additional tests, some database certifications, JDK certifications, and then we put it out for production release. So what that means is unlike WebLogic or WebSphere, which are purely closed source application servers, here you can continuously evolve your application with Wildfly and whenever EAP is ready, just seamlessly switch over to EAP for commercial deployment. Next slide. So we talked about Jbuzz Tools, which is your development environment. Then we talk about Wildfly, which is your application server. What is OpenShift? OpenShift is open source pass platform from Red Hat. And it comes in three different flavors. There is Origin, which is sort of the very classical Red Hat way, where everything is done out in the open source. All the features, every functionality for OpenShift is contributed in Origin. It's basically a GitHub project. So you check out the workspace, you can build that entire OpenShift on your machine by yourself. So that's the first one. The second one is Online, which you see on the far left here. Online is the public pass version. So anybody could go to OpenShift.com, sign up for an account, free, no credit card required. Once you sign up for an account, today what you get is three gears. And gear is OpenShift specific terminology, but essentially each gear is a half a gig of RAM and one gig of disk space. And so you can easily create your multi-tiered application, or at least three-tiered application very easily over there on three different gears, essentially. And then we have the private cloud version of it, which is the OpenShift Enterprise, where you can say, hey, this is my private pass, I have my data center running. And in my data center, instead of creating my own environment, own mechanism to manage that data center, I'm going to install OpenShift Enterprise over there. And on that OpenShift Enterprise, I'm going to install my custom application servers, which we call them as cartridges. So you can install your cartridges and run with it. It really allows you to standardize your operating environment and simplifies the entire operational nature of it. Now, in terms of OpenShift Online Enterprise, today we are at v2. Moving forward this year, the plan is to release v3, which is going to be powered by Docker and Kubernetes. Now, I don't want to go into the details of Docker and Kubernetes per se right now, but essentially what that gives you is Docker is a standard format for containers, how you can run your application in containers or software containers very easily. And Kubernetes is a project that is created by Google and heavily contributed by Red Hat, which allows you to do Docker container orchestration. So essentially you can leverage all the benefits of Docker and Kubernetes when v3 is available later this year. Yeah, and it's also, I think, really cool to point out that even the online public pass version of OpenShift with just the trial account, it's actually pretty powerful. You can actually play around with it and get a real good sense for what you're doing. And like Arun said, we're not necessarily going to talk about Docker and Kubernetes in this talk, but everything that we're showing you should work in Docker in the future when v3 rolls out as well. Right, yeah, the way I like to say that is OpenShift Online is not a cripple way as other companies, they give you an account and then the time bombs after a few months or they start charging you money. This account stays with you. We do hibernate applications if you're not using it, and that's for the right reason. If you're not using an application or if the application is not being used by anybody else, we just hibernate it, but you just access the application and then it comes back live again. So I think it's a pretty compelling offering. Yeah, it's pretty cool. So I guess that brings us to me. So like I said before, I work for Zeroturnaround and we make Jarebel and Xrebel, which are revolutionary tools for developing quality software faster. Now the whole point of what I'm going to show you today and what Arun and I are talking about today is basically how you can make the cloud development experience way less painful, right? Because there are tons benefits to why you should write code in the cloud versus locally or why writing code in the cloud actually is a beneficial experience. But it is kind of painful because no matter how great the tooling is, there's still extra tooling, right? And so we're going to show you how using Jarebel we can kind of help make that less painful. So Jarebel is, it's a JVM plugin, it's a developer productivity tool, right? Basically, the whole idea is that it lets you stop redeploying your application or restarting your application server. You can reload your code changes instantly without having to stop the application. So what you'll see later on in this briefing is I'm going to make code changes to the application while it's running an OpenShift locally on my JBoss Dev Studio or Clips or IntelliJ. And then what happens is you make your code change and we'll actually load the new version in for you. Right now, we have 65,000 happy users. This is a stat that I'm really impressed by myself. And I think that it's pretty cool. We have such a large user base. Now you may be asking, why do I have a bacon-wrapped Ferrari? And this is something that came out of when I was talking with some of our co-workers a few years ago, like, you know, who doesn't like Ferraris and what would be better than a Ferrari? And then someone else, this is when Parks and Recreation was first starting and they're like, oh, well, let's wrap it in bacon. So a bacon-wrapped Ferrari. Who wouldn't want a bacon-wrapped Ferrari? So like I said before, what is JVM? It lets you reload code changes instantly. Do you may be thinking that the JVM already has something like this? It's called HotSwap. But unlike HotSwap, JVM doesn't require you to be in debug mode. It also supports changing your class schemas, adding new methods and fields. And we support Java class file changes, resource file changes, and we also have integration written for over 90 frameworks and their configurations. That means you can change things like your Hibernate, JPA, which I'll actually show you, Java EE supported Spring. If you use that, you'll be able to seamlessly make changes to your application, not have to worry about the tooling involved, whether it's local or in some cloud provider like OpenShift or Docker in the future. And you can just kind of stay focused and actually doing your work. So what we find is that on average, developers spend about one full work month per year waiting for redeploys of their app server. And that's everything. That's based on data that goes everywhere from people who have five to 15 second jetty, tiny single servlet apps all the way up to people who have, you know, millions of lines of code in their full feature Java EE enterprise applications, right? And with Jerebel, it doesn't really matter because you just make your code changes, hit save, refresh, and you can view them. And the benefits here, you can go home on time, right? You don't, without having to cut your feature scope. Like I said, I used to work in a large investment bank. And so that kind of means that I'm pretty familiar with like large enterprise applications. And this is, you know, Java EE five at the time. But still, you know, as we get closer and closer to the end of a sprint, I have to work longer and longer hours, you know, my wife would want to know when I'm coming home. And if I had a tool like Jerebel, it would have been fantastic, you know, because I actually had a 16 minute redeploy. I'm one of my applications. Every time that I made a code change that had typo in it, I wasted a half hour of my life trying to verify that the code did what I wanted to do. And with Jerebel, you know, you can change anything. No matter how complex your application is, as far as we're concerned, it's still Java, it's still bytecode. And we're going to do the ultra low level engineering work to make that happen. And we actually do have case studies and surveys on our site that back up the claim that Jerebel actually can increase team velocity by up to 40%. So that means you're getting 40% more work done. It may look like black magic, but I think the key part that you're highlighting here is just using regular standard bytecode manipulation to make sure your changes are visible instantly. Yeah, I mean, yes, it is using so the average Java developer never usually touches bytecode. But the guys that we have, you know, it's your turnaround or like bytecode ninjas, like they, you know, ultra low level JVM hackers who can make a wonderful technology happen, you know, and bring it to anyone who does Java development. So here's a quick comparison between Jerebel and hotswap. Like I said, hotswap method bodies, Jerebel, everything else, we actually released Jerebel six in November of last year. And we're just kind of showing you some of the new stuff like here. Now we can do hierarchy stuff as well. So replacing super classes, implementing a new interfaces, initializing new instance fields. So for example, if you had like a instance of a person class with a field for first name, you want to add a new field for last name, you know, without that last feature, that meant that your existing instances would have this null field or this uninitialized field that would cause you to have problems if you didn't have like tons of security checking in your application. So what's really important for, you know, any tool, any developer tool is doesn't support your platform and you are, you are tech stack. So Jerebel supports almost everything from IDEs, we have Eclipse and all the Eclipse based IDEs, and that also includes JBoss Dev Studio, IntelliJ and NetBeans, if you are using those, we can hook in with Maven and or Gradle, as far as applications servers, we have JBoss EAP and Wildfly. We also have Tomcat, you know, while WebLogic, WebSphere, Glassfish, those are all supported. As far as frameworks, like I said, we have over 90 that we have integration for. So that's Java EE and all of the subspecs, we have, you know, Spring, Hibernate, JBoss Seam is one of our supported frameworks, for example, Wicked, if you use that, we have some real hardcore Wicked users who are, you know, loyal users of Jerebel as well. So before we get started in showing you what Jerebel can should do, let's quickly touch on how do you get it. So you can install Jerebel from the Eclipse marketplace or the update site. It's also available for NetBeans and IntelliJ in their plugin directories. And then it's also available as a zip file. So if you want to go to our website, if you don't use an IDE or if you have some very non-standard IDE system, go to the download zip file off our website, the Java agent's right there. It's super easy to install. So now I'm going to just quickly jump out of the slides and I'll show you how to actually install Jerebel and configure it and just look around and see what we have here. So here I've got my JBoss Dev Studio. It's a very, you know, standard Eclipse JBoss Dev tools are installed. Everyone's, you know, familiar with this, I hope. And then you can go to the Eclipse marketplace. If you were in a normal Eclipse, since I'm not in normal Eclipse, I would have to go to install new software or JBoss Central. And both of those have the option for installing Jerebel. If I go to install new software, you can install, you can add the update site. Hopefully that's not too taxing on my Eclipse right now with my video and everything going. But the update site's right here. And you would see, you'd pick Jerebel for Eclipse 3.3 plus and derivatives because JBoss Dev Studio is based on, I think this is, is this based on Luna? Yeah, I think you're muted. Sorry, I think you're muted. Funny. Yeah, I was muted. So, yeah, JBoss Developer Studio is something that we release on annual cadence. JBoss tools plugins, we make sure they always work with the latest release of Eclipse. Okay, great. And so I think this version is based on either Luna or Kepler. So it should be a very modern version of Eclipse. And you shouldn't have any, there should be no issues with things being out of date. Personally, I've been using this for the last couple weeks. And I found it to be pretty, pretty intuitive. The tools make sense. And there's some real niceties there as well. And if you're using NetBeans or IntelliJ, you would go to their plugin directories and install there. With Eclipse and Eclipse-based IDEs, you have your activation in your config center. In the configuration center, that's where you enable Jerebel for your local app servers and also any of the extra configuration options that you want to use. Let's see if it's going to load. Yeah, right now my processor is pegged with all this video and everything. So let's see how this goes. Yeah. There we go. Okay. So this is rendering weird, but that's fine. The idea is that you basically have, your local stuff is installed right here. And if you have an app server that you want to enable Jerebel on locally, you just check the checkbox. If you're, okay. That's fine. You can also enable Jerebel for your projects, but I'll show you how to do this separately in the context menus. And you can enable and disable for your debug stuff under here in your logging. Let's just go back to normal Jboss. Okay. This is fine. So go back to Keynote. Okay. So the question is like, yeah, how does it work? So Jerebel works local, which means the app server installed on the same machine as the IDE, either running in the IDE or from the command line. Remote is the JVM or the app server is on a different machine than the IDE. And the last one is cloud. So like open shift would be a great, especially what we're going to show you for the cloud offering here. You make your code changes, compile the class, and then use the new code. Compile the class is usually handled for you by your IDE. So for example, Jboss Dev Studio and the Eclipse-based IDEs build on a map that is enabled, you hit save, and the class gets generated. And the way this works is with workspace mapping. So static content served from the workspace. Class path resource is loaded into the JVM in memory by Jerebel. And we're going to see how this works, and it's actually really cool in a few minutes. So the architecture, so that it's clear how everything actually fits together, because right now this is, I'm sure, kind of generalized. So the idea is that the JVM has Java options, and you get either the Java agent or the agent path with a native library. If you're using the remote function, then you'd have to add a separate Java option as well to actually enable remoting. In the application, there are two pieces, and both of them are generated for you by the IDE plug-ins. There's the rebel.xml, which maps out the class path and static resources, and the optional rebel remote.xml, which contains your crypto keys and remote IDs, if appropriate, to enable the plug-in to correctly do the remoting to the cloud or to the remote VM. In the IDE, you have the Jerebel plug-in, and that generates everything for you. So I think that we've done enough slideware now, and I think now it's time to move on to the functional portion of the demo. There's a question in there, where they say, is there a plug-in for sublime text? So what you would use there, we actually have people who do this. We have people who use like Emacs, for example, or Vim and Jerebel, and you basically just need to issue the compile and command yourself, and you can use whatever you want to write your Java files, and then you just need to use either Ant or Maven or Gradle to compile the incremental classes. Unfortunately, in order to use OpenShift or any of our remote or cloud functionality, you do need an actual IDE plug-in, because the way that this works is Jerebel will actually piggyback on the servlet context of the remote machine and actually send the files for you to the remote machine and then do the class reloading. So we need something to hook into to actually send the files over HTTP to the machine. That's why you actually need a real plug-in. I hope they answered the question, and I'm sorry if they're trying to use sublime text and OpenShift for the same time, for Jerebel. But I promise... Sublime text and Emacs audience is pretty hacky, so they should be able to hack something together. Yeah, exactly. I mean, you can do something. I'm sure it's fine. I mean, worst case, this won't work with OpenShift, but if you are using a remote VM, for example, like VMware or Docker container or something, you actually could use... You could hack together something with R-Sync or something, and that would also work. We have customers who do that. So I'm just going to quickly wrong window. Hit this guy. Get the right one. Yeah, all right. So what I have here is I have my OpenShift account. So you can actually use my application if you want to, I guess. But I have the Wildfly app server, 8.2 final cartridge, along with the Jerebel cartridge, which was originally written by someone at Red Hat, and I've recently taken ownership for a little bit, so I can update it, and then we'll figure that out later. But you can follow along with the instructions at this blog post. It's a little out of date, but it's more or less what you want to do. It shows you how to use OpenShift and get Jerebel installed with it. You basically just have to add the cartridge and then enable the remoting in the IDE plugin. So I've done that, and I have this kind of simple Java EE7 application. I think this one is... Okay, so this is not based on a rune sample from before, but I actually have one of a rune's hands-on labs that we've done before with OpenShift. This is actually a simple Java EE7 application. I've got web servlets. I have JPA, and I also have CDI. So this is running on Wildfly 8.2. As you can see, I have my rebel.xml, which was generated for me, and I also have my rebel remote.xml, which contains my crypto keys, because I don't want to send my code over the wire unencrypted in case someone is sniffing for somehow. So we have a very simple servlet. I have this test servlet that I've added. If I go to my Chrome, I see I have this test servlet. I'm doing some absolute, like, please never do this in a real application, but I'm injecting my entity manager into the servlet just because it's a way for me to show you how these things work without having to spend too much time talking about all the extra stuff, you know, with best practices in Java EE. I just want to show you something functional that works really cool. So please don't do this, ever. But just to show you the kinds of stuff, like, if I wanted to make really simple code changes, right, right now, I assure you this is running on OpenShift. This is not a local application. You can see that it's running on rhcloud.com with my domain and my application. And I can go in my JBossDev studio. I figure out where to put you a room. Okay. So I can, you know, just make small changes. Like, here I'm going to say just text change a room. So hit save. And you see that I just got this message from the terrible remoting saying that my uploaded my resource and transaction was committed, right? So the class file got uploaded into OpenShift. And I can just hit refresh and it works, right? So what my application is doing is when I hit the server with a get request, it just generates a random number and creates a new attendee with that number and whatever name I'm just passing at. So here's a rune. Here's another rune. A rune is coming to my webinar a lot. He's a very vocal attendee. So, you know, what's kind of cool is I, you know, even though that is really simple change, just normal, you know, method body change, you can't do that in, you know, these, these cloud solutions because you have to commit the, so with OpenShift, you commit the code to the get repository. And then it bounces wildfly, which is actually a really cool way to handle things like, you know, hooking in with the get triggers. But, you know, maybe you don't, maybe you're not doing that much stuff and you just want to do a quick change. So that's fine. But let's say you want to do something a little bit more complex. Like let's say we want to add a new servlet. So I've got this, this hello servlet right here. I'm just going to go to hello servlet instead of test servlet. And that works. So right now the servlet works. And so what I can do is I'm just going to copy it. I'm just going to create a copy of it and change the output text and also change the mapping. This is going to be Adam servlet. So in Adam servlet, we see it already actually sent the file because it saw that the file that there's a new class file. So it already saved it and already sent it. I'm going to give it a new mapping, Adam servlet, right? I'm going to say, this is cool, right? So now hit save. My class file got generated by Jboss Dev Studio. It built the .class. Jarable Remoting Cloud functionally kicked in. The class file got updated on the on the OpenShift instance. And now I can go to Adam servlet and that worked. So help me understand, you know, in this case it's not the entire war file that is being redeployed. It's just that one class file that is uploaded. We are not even, yeah, exactly. So it's just the change to .class files or resources get sent at all. So even if you have like a, so you're taking like slow network connections out of the equation, you're not uploading all your resources again. If you have a year or a war that has tons of pictures, you're not you're not sending that again. You're only sending the .class file that actually got changed to a cached folder or a caching folder on the remote machine or VM or cloud environment. And then Jarable kicks in and reloads just that piece that was actually changed. So that would work for all the standard joey components, whether it's a servlet, whether it's a JaxxRS resource, whether it's a JPA and all those components. Yeah, so here, like, let's, right now, let's just add a new, a new JPA entity and then we'll start using it. Okay, so let's make a due to two. Right now I have an attendee. I have a dev user and a normal user. Let's copy one of them again, just because in the interest of time savings, I'm going to copy my dev user, right? So I'm going to duplicate the class and I'm going to change this to a coffee drinker, right? Because devs are coffee drinkers, let's be honest. So I'll go to my coffee drinker class. We're going to change our named queries. So I'll say find all drinker or final copy drinkers, right? We'll say find C from coffee drinker C. And now we can go and make sure that all the steps right, we're going to change the two string. You may want to change that upper case C to lower case C and the name query. Uh, yep. Good call. Here we go. No, this C is okay, but at the end. Ah, yes. There we go. Just so I had too much coffee today. So now we're all set, right? So we have this new JPA entity. We have, it has an ID and a string. And does it have a name? No, here, I'll give it a name too. Right? Okay. Let's add a new, uh, let's add a new constructor that takes in a string as well. And if this one doesn't get set, then we'll just do this.name equals default. And we'll do a getter and setter for it. And then I'm just going to hit generate for. See, because you can use, you know, the benefit of an ID is that you can generate this stuff if you want to. So there's insetters, name, and we're okay. Okay. So get and set name. Okay. Move you again, Arun. Okay. So this should be good. We have a getter and setter for the name. We added our new constructor. We have our new field. This is a new JPA entity. You know, just for fun. Change that too. It's a comment. We want to keep our comments up to date as well. Hit save. So we see that we actually sent the new file. So it's already there. And now if we want to, we can go back to our servlet and change what we were doing to use this new, uh, this new type. We're going to use our new entity. So without having to do anything, it's all just going to work. So we're going to find all coffee drinkers for our name query, change our class. Coffee drinkers. There's a typo in there. Okay. And type over here too. Okay. See, don't make your class names too complicated. There we go. That's when you use auto code completion. Yeah, that's true. All right. So this is all now using the right type. And now I can go to my persisting as well. I'm going to change my persistence to persist a new coffee drinker. Give it the name of rune still. And now I should be able to hit save. There's no compilation errors. The class got, uh, got compiled and uploaded. Now if I go back to my servlet, go back again. Now I have a coffee drinkers. So what we see here is that using Jarevel, I was able to add a new JPA entity. I was able to hook that into the existing persistence manager, in my servlet, and I was able to use it without having to rebuild the application. I didn't have to restart my, my OpenShift gear. I didn't even have to, you know, I didn't lose any of the state in my application. Like if I go back, my, my other users are all still there, which is like, this is just so powerful. Because now it gives you the flexibility to write code against a cloud, a cloud platform without having to sacrifice any of your, your time or sanity to do that. One of the implementation details that might be relevant is that if you create for brand new persistence.xml, you know, that won't work because that time, you know, Jarevel does not know how to initiate database connection, but once the database connection is established, you have redeployed the war file, then any number of entities can be easily added. Right. Or modified or anything, and that'll all, it'll all work just the way you expect it to. Yeah, I think this is awesome. This is Grant, by the way. And, you know, it's a game changer for the OpenShift community who are Java developers, because today we, you know, we bounce the server every time you deploy, but we also support hot deployment, which can take, you know, 45 seconds to two minutes, which makes OpenShift not really a viable platform to actually do development on in a cloud-based infrastructure. And so using the Jarevel plug-in makes an awesome experience, and you can, you know, use OpenShift cloud deployments for the entire development through production life cycle, which is great. Yeah. Yeah. And that's exactly what I love to hear whenever I show, whenever I show, say about this, say about this, right? The people who like a lot of cloud platforms, developers, developers to use them, because the experience, like the idea is that you write code in a cloud platform, you can hit, you know, real services in development and not have to mock everything out and hope it works. Now, the problem is that how do you, how do you, you know, give people the experience that they need in order to actually functionally write applications, right, and not have the downtime associated with actually transferring your application all the way to a cloud instance? Like, so there's actually a survey or actually a study that Microsoft did. I saw this in the New York Times recently. What they found was that the average email, right, even one email, like getting an email and reading it, takes you about nine minutes to being as productive as you were before, right? And that's only just reading an email. Imagine having a two minute, a two to five to 10 or however long minute redeploy of your application, right? So, actually, like the downtime is pretty, pretty aggressive in terms of the drain on your productivity. I have one more quick, cool thing to show in this, and that's I'm going to attempt to do some CDI shenanigans. So, I have, I think, CDI test at JSF, see if this works. I was playing around with this earlier and I didn't, I didn't clean this off before I did it, but so here's a, here we go. So, here I'm using JSF and CDI. And if we go to my code, let me just close some of these things because there's some kind of in the way right now. Okay. So, I have this test bean, the name test bean, right? And this is getting a bean injected into it. And this is what's actually feeding that, that JSF file. So, let me open that file up and you can see what we're doing. Okay. So, test bean test two right there. So, it's getting the, the value and putting it into the output text of the JSF page. And so, what I can do while this is all still running. First off, I can change this to if I, or to two if I want, right? Hit save and you see the class got, got pushed. Go right here, hit refresh. Now it's just two. So, that worked. And we can also change which beans are getting injected. So, let's say I want to swap this over to CDI bean test two. Okay. I can go back to my test, change this to two. Hit save. Now, hit refresh again. You have test toe, which I spelled wrong. But still, the idea is that it worked. But I think the, the cool part is gerable automatically identifies which components, which files, which classes have changed and it sends only those classes to the deployment. And I just fixed the typo, which did not take me any time because I have gerable as opposed to having to bounce, bounce down. So, I think the grand really put it very nicely because typically the pain point for me is, you know, every, I mean, by default, OpenShift behavior is you make a change, you do a good push, you know, it does the whole shebang, you know, you are going out for a coffee and you're coming back. It almost feels like a web sphere application server restart. But with this, you know, the changes are instant. So, you were actually really doing continuous development, you know, with this, and then now when your stuff is ready, then you say, oh, by the way, now let's do the default behavior where you restart the cartridge and the whole thing. Right, exactly. And so what, the way that, okay, so you may be asking like, realistically how long is it to actually be productive with this? And the idea is that you, you have your cartridge with Wildfly, you have your cartridge, the gerable cartridge embedded into it. You just enable gerable on your application. And then you just add the URL that you actually deploy to in the, this remoting is right here, this deployment URLs. And that's it, right? Like there's no big sysop type experiment going on with, you know, screwing around with stuff. It just kind of works. So one of the questions in the chat is what app servers does the gerable cartridge support today? We know Wildfly, EAP, those both are supported. Right. So, gerable's remoting functionality or gerable, like actually, you know, works with, you know, wild web logic, web sphere, Tomcat, Tommy, you know, clearly all the jba stuff, the whole web sphere family, Liberty, for example. So the idea is that, you know, you can be, you know, you don't have to change your tech stack, whatever you are using now will work. Obviously, you know, we're advocating that you use, you know, a more of a cloud type platform with this. But, you know, the idea is you can, you can keep, yeah, actually, it should. It should work. Adding the Liberty server with OpenShift should work. Grant, so the idea is that since Liberty works, it should. William, I guess my real question, and I haven't actually looked at the insides of the J Rebel cartridge, if it's like hard-coded to work with specific app servers, or if I do lay down the Liberty cartridge on OpenShift. So, the way that, the way that we did it, I don't know why I'm sharing it to you like this, I could just show it to you on my terminal, but we're just exploring the Java option. So, anything that reads Java ops normally should work. Awesome. Thanks. And then we have the OpenShift J Rebel Durer, and these things all get set up during the setup section. Nothing here should be, like, so basically, we have the normal Java ops, we also have the Catalina ops built in as well. So, if you're using Tomcat, for example, that'll get picked up. So, yeah, as long as things are using normal standard Java ops or Catalina ops, it should work. Right. I think we also showed, like, a few weeks ago, not just OpenShift, but this would all work very well with Docker already. So, when OpenShift V is launched later this year, it'll continue to evolve and make it a more seamless experience in that line as well. Right. So, but for right now, if you're using Docker, you would need to change the Docker recipe that basically does the same thing that the cartridge is doing at OpenShift, which is copy the Java agent or the native agent over to the Docker instance, and then add the Java options there as well. But that all should be fine. And as Arun says, we did that previously with Docker with great success. I think we may have a few slides left, just the last one. So, if you want, we can talk more about some stuff. I can show you some more code changes. Arun, did I miss anything this time? No, I think we covered pretty much everything that we wanted to do. And also, we talked about how you can use JBoss Developer Studio or JBoss Tools. We didn't talk about particularly local use case, which is not relevant for this audience. But you can do, you can get all the benefits that we showed today in a local wildfire or EAP instance as well on the network or on the cloud. And then I think, as people are saying in the chat window as well, I think this is really a game changer where it'll expedite your overall development cycle where you don't have to wait for a few seconds or maybe a minute also to get your application deployed. Right. Actually, so one of the things that I talked to a lot of the law developers, I talked to them, I talked about, you know, I'm sure you talk, you as well, Arun, talk to a lot of developers. But when I show them OpenShift or I show them, you know, a similar platform, and I, and like, yeah, it's really cool. But, you know, such and such like Red Hat or some other company, Devs aren't going to use this. I mean, come on, like, you know, the tools, it's painful to do this. And like, it's great for staging or production or whatever. But like for an actual like development, I'm not going to use it. And then I show them Jerrible and they're like, Oh, well, now this is actually a development platform. I can actually use this now. You know, this is, you know, because I, and I'm not knocking the Red Hat, you know, OpenShift tools, because OpenShift tools are actually pretty good. It's just an issue of, you know, if, if you have the option of a teleporter, but there's a really fast car, the fast car is still a pretty cool car. It's still pretty fast, but you could have a teleporter. And so that's, that's kind of like, it's kind of where like, I'm not knocking the tools. I'm just saying that nothing, nothing is better. Right. Yeah, this is, this is Mike. I get to talk to a lot of our enterprise users. And one of the things they try to do is chase all the efficiencies. And you kind of think, well, you know, Jerrible is very useful even outside of this, this conversation. But why, why is it so, why is it so attractive to a PADS conversation? And it's because PADS is the organization sitting down and sort of trying to find inefficiencies in the system. And if you've agreed to do that, then you've, you should agree to go down all the way to the developer when he first touches the code and invest at that level too. And that's why Jerrible comes up a lot in our deployments, because it brings that opportunity, that investment opportunity to really clean up how you're working with your code. Another big issue that we run up against is, you know, executive staff is always trying to get developers off their laptops because laptops are just expensive and their security risks and all sorts of fun stuff. But developers never want to give them up because they want that fastest transaction possible. They want to do unit testing there. And we find Jerrible really allows them to, to sort of give up their laptops finally. And that's a, that's a huge benefit. Yeah. I used to have, I used to, so back when I worked at the bank, I had like a 10 and a half pound thing, like a huge think pad. And, you know, I'd go home and I'd have like a desktop that was, you know, way more powerful or I'd have a net book. And I'm like, well, you know, what am I really doing on, on the think pad that I can't do on the net book? And really it came down to running an actual app server, right? Like