Saturday, June 28, 2014

I strongly believe that the JavaEE spec and the JavaEE stack is going through an excellent phase. It is the summer of JavaEE
as a fellow friend suggests. So in summer you always feel e bit more
enthusiastic and happy etc. I have been experimenting a lot lately with
JavaEE7 (and 6) technologies, especially with all the goodies that come
from the RedHat /JBoss stack. Application server, Hibernate 4, Infinispan, Rest-Easy, Arquillian & ShrinkWrap, OpenShift.
It's been a long time since I felt that I actually have tools and
technologies in my hands that actually work, are mature and I can rely
on.

But...then here comes the reality. This is an old and long
running whine of me, from the early start of my career. I always wanted
to work and build solutions using 'things' that came out of the JBoss
house, but 9 to 10 times, I got the reply, 'the client has a big
contract with this shop and the other shop' so we have to go with 'their'
tool. And most of the times their tool was 2-4 years behind in terms of
maturity on spec implementation. And most of the times we had to
re-invent the wheel or cannibalize actually the application because
their tool was not delivering, making a worse mess that using right from
the beginning something that is actually working.

The good
news? These recent years, most of the technologies that I was dreaming
of to have in my deployment path :), became a standard! No I don't have
to use your 5 year old, left over JPA implementation, i need to make
your server work with the standard. I don't have to use this outdated
REST implementation of yours, I need to wire something that is working.
No I don't have to use your specific plugin, in order to deploy
something that is considered standard, I want to use Maven or Gradle and
I will be expecting to work.

Unfortunately, I still have to
work and develop with tools, picked by others , due to some contract .
Unfortunately still my stack of choice ...will be 9 out of 10 times, out
of the scope.

I guess the only time this will change is when I
will be able to control what tools to be used, using my developer
experience from the past, in my own company :)

Friday, June 27, 2014

This post is mostly targeted to Java developers working on the financial sector, especially with systems that need to do payments and specifically using the IBAN/BIC standard.

So today I was browsing through some 'legacy' code, that was performing some sort of validations on String representations of IBAN accounts. I wrote a simple JUnit test, in order to check if the validations performed from this very very old JAVA 1.4 (or older) style of code, were eventually correct.

To my surprise I realized that a few bugs or missing cases were floating around. I started digging further, missing empty/null string or formatting exceptions, specific formatting decisions based on specific countries and many other issues led to starting asking myself how I can efficiently correct the code and eventually 'secure' this part of the system that was relying on such error prone validations.

After some more digging around, I found that there are actually 2 good candidates, for my case

I reviewed the API and functionality offered by both. To be fair IBANCheckDigit from Apache is some sort of utility class, while iban4j is a complete mini library that covers, creating, formating and checking of IBAN and BIC literals.

I re-used my unit test, replacing the legacy code with calls to ibanj, after including the dependency on my pom. All test passed, all validations and exceptions caught. I had a clear winner.

Many thanks to the developer, for sharing such a handy library. The API is clean and simple and the functionality conforms to the standards. At least it passed my legacy compatibility tests.

So in case you find yourself in a similar situation...give iban4j a go!

Monday, June 23, 2014

Series

In the previous post (part 5), we discovered how we can unit test using Arquillian, our EJB services, deploying them in a 'real' instance of Wildfly8.1 application server. Extending the previous example we will add some more configuration and code, so that we can add unit tests that involve our JPA2 Entities. Creating, saving and retrieving information from the database is a very fundamental task of many JavaEE applications. We need to make sure that our domain model and the logic coded on top of, is as much tested as possible. I am going to use the 'simplest' form of configuration and related libraries. Since we already test towards Wildfly 8.1, we will be using an internal H2 in-memory database that is bundled with the server, and the pre-configured ExampleDS datasource.

Watch out, this is just for testing and demo, in real life you will want to test under a production based RDBMS, so most probably you would be needing:

create a test DB schema in your DB server (e.g Oracle, MySQL, DB2...)

Add appropriate Datasource configuration to the application server, so that it connects to to the above DB server.

We have already setup Arquillian, and is already leveraging the capabilities of a standalone Wildfly 8.1 server. In the previous post (part 5), we have been testing a simple Stateless EJB, that was not retrieving or saving information on the database. On the sample-domain module we have already defined a simple JPA2 Entity Bean. We would like to test some basic stuff, like save the entity on a database, retrieving the entity etc. It is a common pattern even nowdays, for many projects, to create stateless sessions beans that are actually implementing this code for each entity. You might have heard of them as 'DAO' classes. In our case there is no DAO implementation but the same principles would apply.

Defining a test-persistence.xml

As we have already defined a standard persistence.xml under the sample-domain module (jar), that is configuring actually our Entity Manager, we need a similar confinguration. Eventually a very similar persistence xml but this time is going to be placed in the /src/test/resources folder, because it is going to cofigure for us, an Entity Manager that is going to be picked during our tests, from our Arquillian/Wildfly test combo.

This how it looks

Some notes on the above file

We are defining the ExampleDatasource that is pre-configured on Wildly 8.1

WildFly 8.1 comes bundled with Hibernate 4.x, so we are using 'safely' properties of Hibernate configuration.

We are using the 'create-drop' strategy so that means that every time we run the test (s), hibernate is going to drop the tables in the underlying database and recreate them. That will help us in cases where we are experimenting and we are constantly changing our domain model.

The emb. database that Wildly offers is H2, so we are configuring Hibernate to use this 'dialect'.

Creating an Arquillian Test

This is how our test look like (you can check out the source, on the git link at the end of the post)

Some notes on the above code

Point 0: This is one of the most important parts of every Arquillian based test. This is where we create the in memory 'war', our deploy-able that will contain the classes under test and any other resources needed by the supporting frameworks. All the wiring is done using an Arquillian based framework called ShrinkWrap. In our case the 'createDeployment' method, will package our single JPA entity called 'User' and a persistence.xml file, which is actually the test-persistence.xml under our test resources , configuring an Entity Manager that is working with the default Wildly Datasource.

Point 1: This is a special annotation, very handy on more complex tests, by using this annotation we are actually injecting by default JTA (transactional) support on our test methods, in this particular test is not heavy used. Make note of the ROLLBACK setting. It indicates that whatever this test method does within a transaction at the end all the insertions/deletes/updates are going to be rollbacked, so we leave no garbage behind.

Point 2:We need to annotate our test with the appropriate RunWith annotation, indicating that we want the Junit/Arquillian mechanism enabled

Point 3: We are injecting an entity manager, like we would have done in a regular EJB /resource. The name of the persistence manager must much with the one defined in the test-persistence.xml , so watch out.

Point 4: The @Before Annotation is indicating that the init() method, will run before every test. This is a great place to initialize any data,and prepare our test domain environment.

Point 5: As you can see within the init() method, we are persisting a User entity, similar to what we would have done in our product / real code!

Point 6: The actual test method, we are trying to query for the object, persisted later on.

Finally

The fact that we have already configured and prepared our project structure and configuration in order to use Arquillian, is actually the most important thing. Once you have the basic blocks ready, then it is a matter of writting more test and experimenting with your code. Right click on the test and as you can see , we have the green light of succes, a clear pass. Happy testing!

You can find the complete code for this post under the post6 tag on my bitbucket repository.

Monday, June 09, 2014

Series

This is the first 'extra' post, based on the maven JavaEE7 demo project I am 'building' on this series of blog posts. We have already defined a solid structure and some modules. One very common case in an application like this, is to use Arquillian (+JUnit), a god sent framework, that enable us to unit test our EJB services using a 'real' application server, most probably the same that we are going to deploy to. I am actually following the basic setup guide as it can be found here, the difference is that I am going to setup Wildfly 8.1 as my embedded container to host my unit tests. Widlfy 8.1 is a fully blown JavvaEE7 container, so I can safely test all my features.

Arquillian mind set and Maven

One of the basic things you need to understand in order to adopt Arquillian in your Maven-ized project is the following terms (ideas) that are actually implemented as dependencies.

You need the Arquillian framework/library of course, imagine that it is a new car but is missing it's engine. The front part it's empty.

You need an Arquillian Container Adapter, imagine that you need to install some kind of placeholders in the front part of your car, something like a frame that is going to be used so that an engine can be 'installed'.

You need a real container (application server), this is the engine that we are going to fit into our car.

You need JUnit, this is the 'testtrack' that your car is going to run and be tested.

You need your code (your EJB(s)), these are the passengers that are going to be placed in the car and test a ride on the Junit track.

Defining the dependencies on the parent pom

As we have already elaborated in the previous 4 posts, the parent pom is the place to define the dependencies and their versions of libraries to be used in our application. Have in mind the above list of terms let's get started and update the dependencyManagement section of our parent pom.

Some tips on the above fragment:

Some of the dependencies are of type pom, and scope import. This is actually a special case on defining group of dependencies all together. A pom type dependency, means that this is a group of individual libraries grouped together under this definition. You only need to define this uber pom and you will inherit the individual dependencies within it. In the Maven terminology this grouping of dependencies are called 'BOM' or also known as Bill of Materials. Arquillian is consisted of several concrete libraries and dependencies, instead of defining each one of the, one by one, we have the same result if we define the arquillian-bom.

The 'arquillian-transaction-bom' is an optional dependency, you may not define it, it adds extra features to the arquillian engine and in your tests. One of the most famous 'extra' features is the '@Transactional' arquillian annotation. See details here or here.

A special case, for Wildfly and JBoss. You will notice the dependency, 'wildfly-embedded', you will assume that this is a 'embedded' uber jar version of the Wildfly application server, like the one for Glassfish. Eventually this is not, and this is a common mistake that people make when trying to setup Arquillian with Wildfly. In order to make the whole thing work you need to download the 'real' application server. Have a look on the following section, where will will tackle this special case.

Configuring our ejb module for Arquillian and tests

In our demo applications we have 'coded' most of our EJB services on the module called sample-ejb. So we need to add extra configuration to it's pom in order to 'fire' junit+arquillian tests during the test phase of this module.

Most of the configuration will do on this pom, is to cover this 'special' case of Widlfly not being offered as a fully blown embedded container. So in order to make the whole mechanism work we need, to tell Maven, during our test phase, to download the Wildfly.zip (as we would do using a browser for example) unzip it somewhere, and the point Arquillian to the path. Once that is done, rAquillian will take over.

Downloading the wildfly server, before hand

The configuration below is written in the sample-services pom, our 'EJB services' module

Some tips on the above fragment:

We use the maven-dependency-plugin

We instruct the plugin to kick in during the 'process-test-classes' phase of the Maven lifecycle, and when it kicks in to execute the 'unpack' goal. So before Maven starts running the tests the above part of the configuration will have downloaded and unpacked Wildfly 8.1 to the class path.

Running the tests, using maven - surfire plugin

Again the code below is part of the sample-services.pom. We actually configure Maven Surefire Plugin, which is the plugin that executes the Junit-Arquilian tests.

Some tips on the above fragment:

Surefire provides the execution environment for the unit tests. In our case we have Junit-Arquillian powered tests. In order Arquillian to correctly initialize itself and to identify the container we need to pass as system parameters, the path of the download application server. Remember that wildfly / jboss is a special case. The container will already be downloaded on out /target folder.