Effy's Blog

Recently, I needed to modify content of a few thousands XML files. The modification itself was nontrivial and consisted of reading two attributes from an element and then updating a value of a previously read attribute. And to make it even more interesting, I wanted to keep the formatting of all files intact. My goal was creating a reusable utility that could be used also in the future, should such a need rise again. Because of the need to preserve the formatting, I rejected all tools I usually use (Dom4j, SAX, Jaxb) and started to search for a suitable tool. Finally I found the answer in a form of a recommendation on http://stackoverflow.com , the tool recommended was VTD-XML (or on github ).

I have read about logging performance impact many times, but I have never seen with my own eyes. That changed once I accidentally run full set of integration tests with full logging on, which took twice as long as with no log on. That changed my look on logging and now I will never look at a logger line the same way. The log's impact on application's performance is significant. It is definitely more than I anticipated and what is the worst part, it can be easily worsened by using a logger inappropriately. In this post, I will demonstrate how a small variance in logging line of code can make a huge difference in application's performance.

Setting up new environment is usually a great time to reflect on all the great things and all the bad things you had encountered in the past. Now I had just experienced this very moment twice in a row, thus resulting in a full scale tools revision. One of the things I have always overlooked were command line aliases. Once I decided to use aliases, another question was in order: Why to stop there, isn't there a way to put them to even better use? And after a while of googling I found a great article http://erics-notes.blogspot.cz/2013/06/maven-ant-alerts-in-ubuntu.html , it describes how to get system notifications from command line.

Most of the applications I work on are based on jsp's and usually run on Jboss AS of various versions. And even though the newer applications are maven based and run on Jboss AS 7, almost nothing have changed in a matter of development. At least I thought that nothing have changed, but that was only because my carelessness. When you are developing web tier, there is no compiler telling you what is wrong in the real time, you depend on syntax validation only. And that enables you to do a lot of small mistakes that usually end up with error 500 and a need to redeploy the application. But this is the case only until you discover the right configuration!

In my last post I have indicated that I am currently exploring the Play Framework (latest version 2.1.3) in detail. And as one of my points of interest I chose to examine some options of running an application in cloud. I was deciding between Heroku and OpenShift and the title of this post already gave away my interim decision. The most obvious difference between those two cloud services is that OpenShift does not provide out of the box support for Play applications. But I do not consider it to be a deal breaker as long as a Play application works there. When I started doing a light research on the subject of running Play application on OpenShift, most influential findings I found were OpenShift's blog post and Play2 OpenShift Quickstart at Github . There were others, but the basic Idea was that you can not run Play 2.x application natively (using embedded Netty and Play's command line). Long story short: you can!

I have recently begun experimenting with the Play Framework and I think it is great. Definitely something worth looking into. This post is based on my experience with Play 2.1.2, but I am convinced that it applies to 2.0.x versions as well (and quite possibly to older versions too). I am using an embeded Netty server that is a build in default server in Play Framework. Play works just fine if you are satisfied with the defaults, but the alternative configuration can pose a challenge. The default bind address is 0.0.0.0:9000 and it fine, but I needed it to change to meet the OpenShift 's demands. I wanted to bind a Play application on one specific address along with a non standard port. The configuration described in the Play's documentation works, but only from the Play's console and I needed to launch the application directly from the command line and that is where I got stuck for quite a while. And this is what I found out.