Where are Docker’s files?

I recently installed Docker on an Ubuntu server. It took me quite some time to find out where Docker stores all its (rather large) files. In my case it turned out to be in /var/lib/docker and I found it in this post. If you want to use a dedicated file system for Docker, perhaps using ZFS, it certainly helps to know where to put it!

Categories: Linux

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:


<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-ear-plugin</artifactId>
      <version>2.9.1</version>
      <configuration>
        <defaultLibBundleDir>lib/</defaultLibBundleDir>
        <skinnyWars>true</skinnyWars>
        <archive>
          <manifestEntries>
            <Implementation-Version>${project.version}</Implementation-Version>
          </manifestEntries>
        </archive>
        <modules>
          <webModule>
            <groupId>com.example</groupId>
            <artifactId>Example-Web</artifactId>
            <bundleFileName>Example-Web.war</bundleFileName>
            <moduleId>Example-Web.war</moduleId>
          </webModule>
          <!-- other modules -->
        </modules>
      </configuration>
    </plugin>
  </plugins>
</build>

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

2014-08-14 1 comment

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">
  <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
  ...
</persistence-unit>

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

Add Eclipse Marketplace to MuleSoft Anypoint Studio

Anypoint Studio, the IDE for Mule, is based on Eclipse, but ships without the Marketplace client. That is a pity, as it makes it harder to add useful extensions. Fortunately it is easy to fix. Select “Help/Install New Software…” and add the Juno repository (http://download.eclipse.org/releases/juno) as a site to work with. Search for Marketplace Client. It is found under General Purpose Tools.

Install Eclipse Marketplace client

Install it and there you are!

Note that this covers the current version of Anypoint Studio for Mule 3.5, which is based on Eclipse 3.8. Future versions may not use the Juno repository. Check the version of Eclipse that Anypoint is based on and use the proper repository.

Categories: Mule

Jens wins CodeMint’s coding challenge

CodeMint’s coding challenge is over and Jens Lideström is the winner! Check out the results in order to learn about high-performance lambda functions and streams for Java 8. The text is in Swedish, but the code speaks for itself.

The challenge was to process weather data from NCDC as fast as possible using the new streams and lambda functions available in Java SE 8. Jens used a custom spliterator in order to win. My solution is short and to the point, but it is four seconds slower. Congratulations to Jens (who joins CodeMint as a new consultant Tomorrow!).

Categories: Java

First Google Glass application released

Erik-Google-Glass-small
Last week I released my first real GlassWare! It is a really cool application, but unfortunately under non-disclosure. Anyway, my first impressions of Google Glass as a target platform are fairly positive.
The API is still changing and that can make life a bit difficult. Some samples target the wrong version and either won’t compile or crash. Furthermore my computer wouldn’t recognize Google Glass correctly at first, so adb couldn’t find it as a device. I solved that as explained in this post. Finally the voice recognition for my Swedish accent is – well, let’s settle for not perfect.
All in all, though, it is fun to develop for Google Glass! The bleading edge is where I want to be.

Categories: Android, Google Glass, Java
Follow

Get every new post delivered to your Inbox.