Effy's Blog

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.

In my last post I presented Simple EJB Arquillian test based on JUnit running on managed JBoss AS 7 . And in this post I show a similar test only this time it is based on the TestNG testing framework. I have more experience with TestNG than with JUnit and all my tests are based on it. That is why I have decided to give it a try despite the fact that my preliminary tries failed. My goal was to create one Java EE 6 bean, a simple persistence entity and one TestNG test. A testing project described in this post is again based on the Maven and targeted on JBoss AS 7. It is only supposed to show the possibilities the Arquillian offers not to act as a real world application.

I believe that every programmer understands the need for testing. We want our code to be tested and bug free, but the time is of the essence. We need tests to be easily written and executed and as exact as possible. From my experience, testing Java EE always required a special treatment. You could either code additional means to enable launching tests from your application, or you were left with creating a test environment using for example OpenEJB for beans, something different for transactions and something else for persistence. The second approach is better, because it is more manageable and transparent, but it's downside is that the tests are run in a different environment than the one used as runtime. This means that not everything that works in tests will work when deployed on server and vice versa. In this post I am demonstrating the power of Arquillian.

I have recently begun experimenting with the Apache Wicket web framework. But when I launched the Wicket's examples, I have encountered " java.lang.IllegalArgumentException: Argument 'beanManager' may not be null " expeption. Even though the solution is quite simple, I don't think that it is as documented as it should be. And the fact that it is the only problem preventing the Wicket's example application from running on Jboss AS 7 is fairly grim.