Month: January 2016

Setting up Arquillian for Java EE testing

30th January 2016 Java EE, Testing No comments

This post is about aliens. There will be new X-Files series. I watched some episodes, I’m not a big fan, but this show had its good sides. In Java aliens are present from some time, I don’t even remember when they landed. My first 3-rd degree encounter with them was around 2012. The alien that I saw looked a little bit like this


Arquillian (difficult name – but hey ! his an alien) is a platform for running Java EE components tests inside Java EE, CDI and Servlet containers. There are modules available for functional testing (Graphene / Drone), persistance layer testing and other. It can manage embedded containers, manage containers by itself, it can attach to external container started in some other way. Arquillian creates deployment archives for this containers and provides us with test runners. Available containers are listed in the modules section of Arquillian home page and in the reference guide. Modules section is more up to date, but it does not provide complete guide on how to setup test environment.

Arquillian lets you test different component types depending on container used, but most of the time you will probably test with full Java EE Container or Servlet Container. Arquillian can even download server by maven resources plugin, it will be useful for the demo now. I think I may reuse this setup for next posts about Java EE, but then I will use external Wildfly or some other Java EE server. I would like to build a knowledge management application in Java EE using Domain Driven Design.

Why would I need module testing ? I prefer to test integrated modules as a lot of bugs is related to errors in cooperation between modules. With rigorous unit testing (that is test that test single unit of code) and design it may be possible to provide comparable quality, after all every component has provides API that can be tested. But then again if we plan and provide test in unit test that covers case component will throw InvalidArgumentException will not prepare us for actually handling this exception in client components.. Yes, it can be handled in client component (or some higher level component up the call stack), but you also must detect cases where you forgot to take care of it – and this is where rigorous unit testing comes in to consideration. In real life projects it’s sometimes not so easy. After all software development is about providing software that provides business value and required quality and architecture metrics. Having this in mind I prefer to create automated functional (e2e) test (always for not trivial projects) and then test that are more module or unit tests depending on component. Testing integrated code often requires container – like Spring or Java EE container. This is where Arquillian comes in.

Getting back to our alien – setting up Arquillian is not easy. My setup is not the most up to date one. I tried to update it, spend some time fighting with Wildfly / Aruqillian configuration and decided that it is not the most important thing to use Arquillian Universe instead of older setup. After all we will be using Wildfly 8.1 and Java EE 7 – good enough 😉

First thing is to set up maven configuration:

1. Set up integration test plugin

Important detail here is to setup system properties variables as these will be used by Arquillian and passed to Wildfly. We will us standalone-full.xml so that we can test API’s like JMS that aren’t available in standalone config.

2. Download and configure Wildfly

3. Dependencies

Here we have setup in parent pom – notice

  • jboss-javaee-all-7.0 dependency – we do not use the javaee-api dendency as it contains only API withou implementation (look at warning here)
  • arquillian-bom – this pom contains all dependencies required for Arquillian, we import is so that we do not have to specify full dependency configuration ourselves

and core module:

Now we can setup Wildfly in standalone-full.xml. Important part is overwriting port values here – originally http management port conflicts with NVidia application on Windows. We may also overwrite http port (but we are not really required to do so)

Finally setup in  arquillian.xml, a configuration file used by Arquillian. We just need to tell Arquillian what is the number of management port (setup in standalone-full.xml)

In order to create test we need to specify deployment that Arquillian will work with. We do it using ShrinkWrap module:

Now we are ready to do Java EE module testing:

Example code at github.

Have a nice day 😉

JPA 2.1 – generating database for unit and integration tests

24th January 2016 JPA No comments

Generating db for unit tests is pretty easy in JPA 2.1 or rather as easy as it was but a lot more portable an with more management options. We have a few new entries available in persistence.xml ( properties of JPA 2.1 spec), relevant to db creation are:

  • javax.persistence.schema-generation.create-script-source – this entry points jpa provider to script used when creating db
  • javax.persistence.schema-generation.drop-script-source – this entry points jpa provider to script used when tearing down db
  • javax.persistence.sql-load-script-source – this entry points jpa provider to script that is to load the data
  • javax.persistence.schema-generation.database.action – what action should be done for database – is the JPA provider to create database, drop it or both (drop-and-create) or maybe none?
  • javax.persistence.schema-generation.scripts.action – as above but used for generation of script files
  • javax.persistence.schema-generation.create-source – what source of information should JPA provider use when creating database – scripts, metadata or maybe scripts-then-metadata or metadata-then-script
  • javax.persistence.schema-generation.drop-source – as above but for dropping database
  • javax.persistence.schema-generation.scripts.create-target – target location for create instructions script
  • javax.persistence.schema-generation.scripts.drop-target- target location for drop instructions script

Example configuration:

In the example above H2 database is created in Oracle compatibility mode. Scripts are generated in root folder of project but not used to create or drop database. I used them to make creation of load script easier. Load script is read from src/main/resources 🙂 Hibernate will also read it from root folder, but EclipseLink refuses to do so.

Interesting option is using metadata to create DB and then ddl script to add some specific details or add stored procedures (yes, you could do it e.g. in hibernate using hibernate.cfg.xml but current solution is more portable).

Important detail – notice that all classes are listed in Persistence Unit. Some providers will support class detection when PU is bootstrapped in Java SE environment, some do not. It is safer to list classes. Code that uses unit tests and bootstraps database can be downloaded from GitHub.

If portability is not connected to losing some functionality than why not to use this option ? On the other hand if the price would be to sacrifice some required and well designed, written and maintained functionality that better solution would be to encapsulate the provided dependent part than to use the portable mechanism.

Have en dejlig dag!

JPA 2.1 named entity graphs in Hibernate and EclipseLink

21st January 2016 Java EE, JPA No comments

JPA 2.1 enables us to use named entity graphs that describe what part of entity graph should be loaded. Instead of using one default graph described by FetchType attributes on relation fields and basic fields (in this case code weaving is required) we can now define a few named graphs. Should I mention Fetch Joins used in JPQL and Criteria API ? Well, I don’t find use cases for these equal:

  • With Fetch Joins you have to duplicate query or use tricks like storing core part of query in one field and then concatenate case specific part. On the other hand you can do advanced filtering, grouping and ordering.
  • With Criteria API you can do the same but you can extract common query part to some method
  • Both with Criteria API and JPQL in order to cache results in L2 Cache you must enable query cache

The use cases for named entity graphs are the ones where we do not need advanced filtering or grouping and we do not want to use query cache. Entities fetched with entity graph are cached in L1 cache if EntityManager cache is used. So how can we use named entity graphs?

Let’s say we are given following tables mapped to entities:


On Customer entity we can specify named entity graphs:

In code snippet above there are two named entity graphs:

  • CRT.CUSTOMERS_WITH_PHONES – this one fetched customer data and phones for the customer
  • CRT.CUSTOMER_DATA – this one fetches only basic customer data

Those graphs are simple, this makes it even easier to show some properties. Every entity graphs is a set of:

  • attributeNodes – defined fields/properties that are to be fetched, they can reference subgraphs. Here we use NamedAttributeNode annotation which  value is field/property name that is to be fetched
  • subgraphs – define graphs for related entities, element collections and embedded classes
  • subclassGraphs – defined subgraph for subclasses

@NamedEntityGraphs defines also the  includeAllAttributes attribute that tells jpa provider do load all entity fields/properties, subgraphs still have to be specified.

Now that we have graphs defined We can use this graphs in two ways:

  • as fetch graphs – in this case if an attribute is not specified in named entity graph (including subgraphs) it is treated like it was lazy loaded
  • as load graphs – in this case default fetch type is used to attributes that are not specified in named entity graph (or one of subgraphs)

Let’s test it !

Hibernate JPA provider test:

We specify fetch graph to be used by setting a hint in query instance. As a hint value we specify named entity graph retrieved from EntityManager –  newEntityManager.getEntityGraph(Customer.CUSTOMER_DATA). Orders and phones are not fetched. Note that we use “javax.persistence.fetchgraph” hint – so the fields/properties not specified in graph will be treated as lazy loaded.

Let’s test graph with phones:

Here we using fetch graph but this time named entity graph included phones and they are loaded.

How about load graph ?

In test above named entity graph does not specify phones or orders, but load graph hint is used so default fetch type applies. And both order and phones are not fetched.

How about finder method? Let’s see:

Named entity graphs work in same way. Additionally with query logging enabled we can se that query for customer will be done once.

If we would like to use named entity graphs with O2O relations or basic fields/properties that we will be disappointed:

Both Hibernate and Eclipselink will fetch additional fields in case of One2One mapping and basic properties, and to this according to JPA Spec.

I think I’d rather stick to Fetch Joins and criteria API.

Code with examples will be  are available on GitHub

Cheers !

AngularJS animations – building a simple menu

12th January 2016 AngularJS, Web development No comments

AngularJS animations with ngAnimate are really easy and fun. AngularJS directives are ngAnimate aware so after including ngAnimate as a dependency we can add animations and transitions. We can apply animations in different phases depending on directive use. In order to apply animations we can use CSS or JavaScript or both. Below is a simple case – CSS based animation with ng-show. This is a very simple animation – we need to add only one class to get animation up and running.


Last two selectors are important when considering menu – we want to open menu smoothly. So we need to add a transition with ease in both in and out phases. We will transform all elements. When showing or hiding element AngularJS just adds or removes ng-hide CSS class so, after AngularJS docs, we need just add a .ng-hide class in case of ng-show directive.

menu-panel class selector is animating opening of menu while menu panel with ng-hide selector is animating closing transition.

Now directives – I used lists so I don’t have to position the elements.

And finally html:

As you see menu is super easy to use and it is declarative – no DOM manipulation, no jQuery. Of course we can use jQuery in a convenient way with ngAnimate. See ngAnimate documentation.

Running example in plunkr.

Have a nice day 🙂 !