![]() If you work the way I do, this is an incredible tool that allows me to build a portlet using a fraction of the number of deploys I otherwise would have. The JRebel Agent does the rest - swapping the old class for the new one when the change is detected. JRebel manages to do this hot swap of the class by using a configuration file that tells it which "disk location" to monitor. True, but when you do thousands of them over the course of a large engagement, those 7 seconds add up. "C'mon" you might say, ".deployments only take like 7 seconds to do". With JRebel, you can dynamically reload classes and resources at runtime which means that I can make a change in my IDE, compile it (just the class, not the entire plugin/project) and BAM! latest version of the class is live in the runtime - no deployment necessary. JRebel is a product written by Zeroturnaround - who incidentally has some of the best customer service I have ever received in my entire life. For all of my 6.1 and 6.2 work, JRebel was one of me besties, saving me countless hours a day. I started using JRebel back when I was working with Liferay 6.1 - something that feels like an eternity ago now. It might not be for everyone, but if you are a bits and pieces person like myself, this might be for you. My approach means A LOT of updated deploys - but this, for those of you who are not familiar, is where JRebel comes into the game. Me? I tend to be the bits and pieces type developer - I know what I want to achieve but I take it one bite at a time. The other part was that he like to think of it as a sort of game of compiler roulette, taking his chances and hoping that everything worked. One part of his reasoning for this was because he hated waiting for deployments. I remember working with a guy who would spend hours writing thousands of lines of code before he compiled it. Last we'll wrap it up by showing how to configure/generate the rebel.xml file - specifically how to manage this for the new Gradle project structure. Next we'll setup our agent configuration and logging levels stuff so that you can use to reveal some additional logging and help you figure out whether or not things are working. If you already know about JRebel, you can skip that section. First, for any JRebel newcomers, I'm going to do a quick "What is JRebel". In this post I'm going to share what I found and what I did in hopes that it will shortcut this task for others. The short answer is no, youl use JRebel, and, for me, I think there is still heaps of value in the tool. So my question was, with the new model and all this OSGI stuff, "Does this mean I can't or don't need JRebel anymore?". Liferay 7's achitecture is - let's say - is "a bit of a shift" from the past versions, so I wasn't sure. I started doing some research as well as having a chat with the infamous David Nebinger about JRebel, OSGI, whether or not it should in theory work etc. I am a huge JRebel fan myself and, based on what I know of JRebel and how it works, couldn't think of a reason why it wouldn't work - but, I hadn't yet tried it out. I recently responded to the thread in the forums where the poster was asking about Liferay 7 and it's compatibility with OSGI. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |