Tools

Tech Tip – Running Glassfish Nightly Builds in NetBeans

If you have tried adding a recent nightly build of GlassFish 4.1 to the server configurations in NetBeans, you may have come across the following problem:

glassfish-netbeans-error

The solution is as follows:

cd glassfish4/glassfish/lib/install/applications/__admingui/WEB-INF/lib/
mv console-core-4.2-SNAPSHOT.jar console-4.1.jar

This deficiency of the NetBeans server plugin is covered by Bug #250165

Tech Tip – Upgrading from WildFly 8.1.0 to WildFly 8.2.0

*** Updated ! ***

I came over this problem when I moved an existing Java EE 7 application from WildFly 8.1.0.Final to 8.2.0.Final.  The application is a pure Java EE 7 application with no external dependencies, so you would think it should run without any changes when upgrading the minor verision of a Java EE 7 compliant application server.

In my code I have a LogProducer which enables me to inject the logger using @Inject and this producer was annotated with the javax.inject.Singleton. This works fine in WildFly 8.1.0.

import java.util.logging.Logger;
import javax.enterprise.inject.Produces;
import javax.inject.Singleton;
import javax.enterprise.inject.spi.InjectionPoint;

@Singleton
public class LogProducer {

   @Produces
   public Logger producer(InjectionPoint ip) {
      return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
   }
}

But when I started it in Wildfly 8.2.0, I got the infamous WELD-001408:

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Logger with qualifiers @Default

The reason for this is that Wildfly 8.2.0 builds upon Weld 2.2 (CDI 1.2), while Wildfly 8.1.0 builds upon Weld 2.1.2 (CDI 1.1). To make the producer work in WildFly 8.2.0, I had to change the annotation to javax.ejb.Singleton.

import java.util.logging.Logger;
import javax.enterprise.inject.Produces;
import javax.ejb.Singleton;
import javax.enterprise.inject.spi.InjectionPoint;

@Singleton
public class LogProducer {

   @Produces
   public Logger producer(InjectionPoint ip) {
      return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
   }
}

As pointed out in the comments, using an EJB as a producer may not be the most efficient or correct way. In this case I prefer to use @ApplicationScoped as shown below.

import java.util.logging.Logger;
import javax.enterprise.inject.Produces;
import javax.enterprice.context.ApplicationScoped;
import javax.enterprise.inject.spi.InjectionPoint;

@ApplicationScoped
public class LogProducer {

   @Produces
   public Logger producer(InjectionPoint ip) {
      return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
   }
}

In the current version of NetBeans (8.0.2), this will produce a warning regarding the injection point, Bug 244173.

Docker is Everywhere

Here is a blog post I posted on my blog at Cybercom.

If I should mention one topic that has been more or less on everybody’s lips at every conference I have attended in 2014, it would be Docker. I do not think I have ever seen a technology that has been embraced by so many so fast before.

So what is Docker then?

In short, it is a platform for building, shipping and running applications using containerization.

Read more about it at https://www.docker.com/whatisdocker/

Here are a couple of examples:

Get ubuntu images from Docker Hub:

$ docker pull ubuntu

Starting a container running Ubuntu 14.04 is as easy as this:

$ docker run -it ubuntu/14.04 /bin/bash

Deploying an application in a container running Wildfly on Ubuntu can be done by creating a Dockerfile similar to this (ivargrimstad/ubuntu-wildfly is a Docker image I have uploaded to my repository at Docker Hub (https://hub.docker.com/u/ivargrimstad/):

FROM ivargrimstad/ubuntu-wildfly
ADD ./app.war /opt/jboss/wildfly/standalone/deployments/app.war

Build the image:

$ docker build --rm -t myapp .

And run the application on port 80:

$ docker run -it -p 80:8080 myapp

These were just a couple of easy examples to get you startet. Try the Docker tutorial at https://www.docker.com/tryit/ to try it out without installing anything locally.

 

2014 Conferences

I know it is a bit early to sum up the year in November, but since I have not planned any more conference talks this year I think I will do it anyway. As the picture shows I have been pretty active this year.

 

2014-11-08 12.15.31

I have been presenting at conferences in Norway (Software 2014), Sweden (Javaforum, Øredev), Germany (Javaland), Poland (JDD), Ukraine (JEEConf, JavaDayKiev) and Morocco (JMaghreb). In addition to my speaker appearances, I was also able to attend JavaOne in San Francisco where I got to meet a lot of people in the JCP and ended up being selected to the Expert Group for JSR 371 – MVC 1.0.

I hope to continue speaking at a lot of conferences next year as well. Talks have already been accepted by jDays and Javaland, so it looks promising.

Upcoming Talks

I think time is due for a small update post. Right now I am preparing code samples and slides for the upcoming talks this winter:

  • Javaforum, Gothenburg – Spring 4, Java EE 7 or Both?
  • Software 2014, Oslo – Organizing for Continuous Delivery
  • JavaLand 2014, Brühl – Spring 4, Java EE 7 or Both? and Implementing Batch Processing in Java EE 7

My profile at Lanyrd is also kept up-to-date.

Views From a Speaker at JDD 2013

JDD 2013

I have just come home after spending three amazing days in Krakow as one of the speakers at the Java Developer Days Conference there. The organizers of this conference takes well care of their speakers and you feel welcome all the time. And I am sure the attendees feel the same.

Apart from my talk, my greatest achievement at the conference was to win a a signed copy of Practical API Design by implementing a simple application using bck2brwser. My contribution: Duke2Brwser. Hope this may inspire you to try it out. Just activate the HTML/Java Project Support plugin in NetBeans and go ahead!

Continuous Delivery at Javaforum Malmö

It was an excellent Javaforum meeting in Malmö at FooCafé Yesterday with three brilliant presentations….or at least two brilliant! I will leave the verdict for the last up to you since I am kind of biased…
Well, anyway, here are the slides from my presentation. Below, you will find some comments and thoughts from the discussions under and following the presentation.

Branching Strategy

This is always a hot topic when brought up. I still believe that excessive branching is evil, especially in the context of Continuous Delivery. The longer period of time a piece of code is kept away from the main part of the code, it is more likely to fail. Thus pulling and pushing (or the equivalent of your preferred VCS or DVCS) is the key to make sure that all developers are actually working on the same code base. Frequent pull/push combined with the right techniques, such as Branch by Abstraction, makes the use of the evil feature branches unnecessary even when performing so called major refactorings.

The use of Gerrit was also discussed in this context. Even though it involves a manual step (the approval) and use branching as underlying technique, I think that as long as you see it as a part of the Commit Stage and do not let the unapproved code branches batch up it is an excellent tool for securing the quality of the code base. The caveat is if the approvals starts lacking and you end up with a lot of small parts of code in their own gerrit generated branch awaiting approval that nobody is aware of.

Deployment Scrips

Should you run deployment scrips even on your local development environment? Well, it depends. Normally, you will get much faster feedback by running the application by using the application server support in your IDE. Most IDEs supports hot deploying on save nowadays. But if you make changes to the code that is likely to affect the deployment scrips, or if you are developing the deployment scripts, you should of course test them locally to be sure that they run as expected. Remember that the deployment scripts are also a part of your code base.

Another example is if the target environment is Linux and the developers are running Windows. If the target environment is not likely to change, I see no reason why you should clutter the deployment scripts with OS-specific code or, God forbid, have two versions of the scripts.