Snoop becomes SnoopEE [ˈsnuːpı]

SnoopEE [ˈsnuːpı] The lean and simple discovery mechanism for Java EE based microservices.

What’s in a name, really?

Naming is hard! When I came up with the name Snoop for my discovery mechanism for microservices based on Java EE, my though was to associate the name with snooping around for services to discover”. It seems, however, that most people’s thought goes to Snoop Dogg when hearing the name and that was never my intention.

That is one of the reasons for the renaming. Another consideration is that I want to point out that the best fit for SnoopEE is for Java EE!

At the same time I don’t want to signal that it is only for Java EE. I want it to be just as lean and simple no matter what technology used to implement the services. That is the only reason why I have been a little reluctant to the renaming.

SnoopEE has a nicer feel and as the twitter poll indicates, I am not alone thinking this.

For the record, I have nothing at all against Snoop Dogg! I just feel that Snoopy the dog is a little bit cuter…

I have crated a new page for SnoopEE, but as for everyhing else, such as GitHub repo, maven coordinates and naming, it all stays as it is until properly announced otherwise.

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:

The build section may be just as any swarm application:

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

A more complete example 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.

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

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.

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.

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

Here are a couple of examples:

Get ubuntu images from Docker Hub:

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

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 (

Build the image:

And run the application on port 80:

These were just a couple of easy examples to get you startet. Try the Docker tutorial at to try it out without installing anything locally.