Snoop in Swarm

If you want to run a Snoop enabled microservice in WildFly Swarm, you will need to add some more dependencies to get it to work. This is because Snoop relies on being run in a Java EE 7 compliant application server. And you will need to tell Swarm what parts you need to be able to run it.

In addition to the Swarm modules your microservice depend on, you will also need to add the following dependencies that Snoop requires:

<dependencies>
  <dependency>
    <groupId>eu.agilejava</groupId>
    <artifactId>snoop</artifactId>
    <version>1.3.0-SNAPSHOT</version>
  </dependency>
  <dependency>
    <groupId>org.glassfish</groupId>
    <artifactId>javax.json</artifactId>
    <version>1.0.4</version>
  </dependency>
  <dependency>
    <groupId>org.wildfly.swarm</groupId>
    <artifactId>wildfly-swarm-jaxrs</artifactId>
    <version>1.0.0.Alpha4</version>
    <scope>provided</scope>
  </dependency>      
  <dependency>
    <groupId>org.wildfly.swarm</groupId>
    <artifactId>wildfly-swarm-ejb</artifactId>
    <version>1.0.0.Alpha4</version>
    <scope>provided</scope>
  </dependency>      
  <dependency>
    <groupId>org.wildfly.swarm</groupId>
    <artifactId>wildfly-swarm-weld</artifactId>
    <version>1.0.0.Alpha4</version>
    <scope>provided</scope>
  </dependency>      
</dependencies>

The build section may be just as any swarm application:

<build>
  <plugins>
    <plugin>
      <groupId>org.wildfly.swarm</groupId>
      <artifactId>wildfly-swarm-plugin</artifactId>
      <version>1.0.0.Alpha4</version>
      <executions>
        <execution>
          <goals>
            <goal>package</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Doing this will enable you to run your application as a JAR:

java -jar myservice-swarm.jar

A more complete example can be found here:

https://github.com/ivargrimstad/snoop/tree/master/snoop-examples/snoop-swarm

Snoop 1.0.0 Released

Snoop..what…?

An explanation may be in order. Snoop is an experimental open source discovery service for Java EE that I created as a demo for my presentation at JavaLand earlier this year. After that I have developed it a little further and now I deem it good enough to be showcased more publicly.

The artifacts are published in Maven Central and has the following coordinates:

<dependency>
   <groupId>eu.agilejava</groupId>
   <artifactId>snoop</artifactId>
   <version>1.0.0</version>
</dependency>
<dependency>
   <groupId>eu.agilejava</groupId>
   <artifactId>snoop-client</artifactId>
   <version>1.0.0</version>
</dependency>

The Snoop Service is also available in Maven Central and for convenience available as a Docker image.

$ docker run -it -p 8081:8080 ivargrimstad/snoop-service:1.0.0

The GitHub project contains the source code as well as more documentation.

https://github.com/ivargrimstad/snoop

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

An update from JSR 371 (MVC 1.0)

The work in the Expert Group for JSR 371 progresses and here is a small update. A couple of decisions have been made and the most important one is that the JSR will be layered on top of JAX-RS. The decision was made by voting between this and the alternative of layering it on top of the Servlet API.

What this means for you as a developer is that the stuff you are familiar with from JAX-RS is directly transferable to MVC. As you can see in the simple example below, the only thing that differs from JAX-RS is the @Controller and @View annotations.

Note that this code is highly experimental and will most likely change as the work with the specification continues.

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;

import javax.mvc.Controller;
import javax.mvc.View;

@Path("count")
public class CountController {

   @GET
   @Controller
   @Produces("text/html")
   @Path("{id}")
   @View("counter.jsp")
   public void view(@PathParam("id") String id) {
   }
}

A more complete example with a little more details can be found at https://github.com/ivargrimstad/mvc-samples. I will continue evolving this example as we go.

The latest versions of the spec and reference implementation can be found here:

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.

 

Joining the Experts

I have been a member of the Java Community Process (JCP) for nearly ten years. My contribution so far has been to vote in elections and respond to surveys.

But recently this changed as I was selected to be a part of the Expert Group for JSR 371: Model-View-Controller (MVC 1.0) Specification. This JSR is targeted to be a part of Java EE 8.

I am looking very much forward to participating in this JSR and will post updates here now and then.

A Little Status Update

My schedule for the upcoming months are beginning to fill up as a result of submitting talks to a lot of CFPs during summer. The scheduled talks so far are:

There are still some room, so if you are organizing a conference and need talks to fill up, feel free to contact me. My profile on Lanyrd is kept updated at all time.

But first of all I am going to JavaOne! This year as an attendee, so it is all about networking, community building and interesting technical sessions and keynotes.

nbjavaone_icon_125_2014