Effy's Blog

Do you sometimes wish you could create a smart, yet still simple utility? My usual dilemma is choosing whether to create a shell script to suit my needs, or to create a standard Java application. Now I have another handy alternative. I was just shown an interesting program called Inlein . Inlein lets you to run Clojure written scripts without the need to care about its dependencies. This way you have all the libraries you could wish for at your disposal and yet the utility you are writing is an easily modifiable and readable text file.

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.

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.

When you are building a brand new application, it is usually the time, to challenge the old principles and to conserve the good ones while replacing the rest. My latest challenge was ... providing visible time of build and version of web application build with Maven . If you are now thinking "bah, that is just easy", you are right, because it is. But my path towards the solution presented in this post was not as easy and straightforward as I would have imagined, so I am presenting one hopefully simple instruction how to do it.

One of the new Java 7 features is possibility to use String values in switch statements. Proper usage of this can be found for example in oracle tutorials . But what i wanted to know is how fast is that. Is the new way faster, than a series of if-else statements, or is it slower?

I was recently asked to provide db based user authentication for a relatively application, which user primarily ldap user authentication. This nearly backdoor-looking feature is only for a handful of users which made it ideal for experimentation. I could have stored user passwords as plain-text and nobody else would ever know, but the one person that would know matters the most, me. Almost every application uses passwords for user autentization. Although in complex environment, you don't usually want users to have different password for every application, there are situations that needs different approach. And in those times, security shouldn't be taken lightly. Whether you are writing small intranet application, or full scale internet application, you should always protect your user's accounts, because a lot of studies suggest that majority of users use the same password for everything, so for these users, when one application falls, they all fall. That is the re...