Archive for August, 2014

Sharing EAR libraries with Maven and skinnyWars

This is not a new feature, but I have seen many applications with EAR-files that include the same dependencies in multiple modules, some times with different and possibly conflicting versions. The same library is found in WEB-INF/lib for multiple WAR-files, or both in WEB-INF/lib for a WAR and at the EAR level for EJB modules. This is inefficient and may cause subtle bugs. Ideally all shared libraries should be at the EAR level.

The solution with Maven is to use the skinnyWars option for the EAR:

          <!-- other modules -->

Next, the shared libraries must be referenced as dependencies from the EAR’s pom.xml. When there are few shared libraries it is probably best to include them as dependencies both in the EAR and in the other modules. If there are many dependencies they can be extracted to a separate Maven project and configured in a single place. The Maven project with shared dependencies should be defined to use packaging pom and should be referenced as a dependency with type pom from the EAR and the respective modules. That is really all there is to it.

Note! The skinnyWars support has been improved over the years. Other descriptions mention the need to filter out shared libraries from WAR files with includes/excludes rules. I don’t do that. The war files are complete and can be used as is. The Maven EAR plugin is smart enough to remove the shared libraries from the bundled WAR-files when it builds the EAR-file.

Categories: Java

Unavoidable deprecation warning in Hibernate 4.3

If you are using Hibernate 4.3 with JPA you may have seen the following warning:

WARN org.hibernate.ejb.HibernatePersistence HHH015016: Encountered a deprecated javax.persistence.spi.PersistenceProvider [org.hibernate.ejb.HibernatePersistence]; use [org.hibernate.jpa.HibernatePersistenceProvider] instead.

Fair enough, unfortunately it is difficult to get rid of it. Our persistence.xml already used the new provider:

<persistence-unit name="PU" transaction-type="RESOURCE_LOCAL">

What to do? It appears that this is a known bug, but as of 4.3.6.Final it is still open.

A convoluted workaround is to use custom code in order to create the correct persistence provider, as described here. Personally I prefer to wait for the fix as long as there are no test failures or other issues.

Categories: Java

Changed default options for cryptsetup

I use encrypted USB disks for my personal backups. When I tried to mount a disk on a CentOS 6 host recently it failed. What had happened? It turned out that I had used the default options for cryptsetup and the defaults changed between the versions used in CentOS 5 and 6. To fix the problem I simply had to specify the old default values:

cryptsetup create -c aes-cbc-plain -s 256 -h ripemd160 usbbackup /dev/sdd

Perhaps it is better to avoid defaults anyway.

Categories: Linux