Monthly Archives: December 2014

WildFly/JavaEE7 and MySQL linked on two Docker containers (Tech Tip #66)

Tech Tip #61 showed how to run Java EE 7 hands-on lab on WildFly Docker container. A couple of assumptions were made in that case:

  • WildFly bundles H2 in-memory database. The Java EE 7 application uses the default database resource, which in case of WildFly, gets resolved to a JDBC connection to that in-memory database. This is a good way to start building your application but pretty soon you want to start using a real database, like MySQL.
  • Typically, Application Server and Database may not be residing on the same host. This reduces the risk by avoiding a single point of failure. And so WildFly and MySQL would be on to separate host.

There is plethora of material available to show how to configure WildFly and MySQL on separate hosts. What are the design patterns, and anti-patterns, if you were to do that using Docker?

Lets take a look!

In simplified steps:

  1. Run the MySQL container as:
  2. Run the WildFly container, with MySQL JDBC resource pre-configured, as:
  3. Find the IP address of the WildFly container:
    If you are on a Mac, then use boot2docker ip to find the IP address.
  4. Access the application as:
    to see the output as:
    The application is a trivial Java EE 7 application that publishes a REST endpoint. Access it as:
    to see:

If you are interested in nitty gritty, read further details.

Linking Containers

The first concept we need to understand is how Docker allows linking containers. Creating a link between two containers creates a conduit between a source container and a target container and securely transfer information about source container to target container. In our case, target container (WildFly) can see information about source container (MySQL). The important part to understand here is that none of this information needs to be publicly exposed by the source container, and is only made available to the target container.

The magic switch to enable link is, intuitively, --link. So for example, if MySQL and WildFly containers are run as shown above, then --link mysqldb:db links the MySQL container named mysqldb with an alias db to the WildFly target container. This defines some environment variables, following the defined protocol, in the target container which can then be used to access information about the source container. For example, IP address, exposed ports, username, passwords, etc. The complete list of environment variables can be seen as:

So you can see there are DB_* environment variables providing plenty of information about source container.

Linking only works if all the containers are running on the same host. A better solution will be shown in the subsequent blog, stay tuned.

Override default Docker command

Dockerfile for this image inherits from jboss/wildfly:latest and starts the WildFly container. Docker containers can only run one command but we need to install JDBC driver, create JDBC resource using the correct IP address and port, and deploy the WAR file. So we will override the command by inheriting from jboss/wildfly:latest and use a custom command. This command will do everything that we want to do, and then start WildFly as well.

The custom command does the following:

  • Add MySQL module
  • Add MySQL JDBC driver
  • Add the JDBC data source using IP address and port of the linked MySQL container
  • Deploy the WAR file
  • Start WildFly container

Note, WildFly is starting with -b 0.0.0.0 that allows it to be bound to any IP address. Also, the command needs to run in foreground so that the container stays active.

Customizing security

Ideally, you’ll poke holes in the firewall to enable connection to specific host/ports. But these instructions were tried on Fedora 20 running in Virtual Box. So for convenience, the complete firewall was disabled as:

In addition, a Host-only adapter was added using Virtual Box settings and looks like:

techtip65-host-only-adapter

That’s it, that should get you going to to use WildFly and MySQL on two separate containers.

Also verified the steps on boot2docker, and it worked seamlessly there too:

Source code for the image is at github.com/arun-gupta/docker-images/tree/master/wildfly-mysql-javaee7.

Enjoy!

Resolve “dial unix /var/run/docker.sock” error with Docker (Tech Tip #65)

I’ve played around with Docker configuration on Mac using boot2docker (#62, #61, #60, #59, #58, #57) and starting to play with native support on Fedora 20. Boot2docker starts as a separate VM on Mac and everything is pre-configured. Booting a fresh Fedora VM and trying to run Docker commands there gives:

Debugging revealed that Docker daemon was not running on this VM. It can be easily started as:

And then enable it to start automatically with every restart of the VM as:

Simple, isn’t it?

Enjoy!

Java EE Workflows on OpenShift (Tech Tip #64)

This webinar shows how create a Java EE workflow on OpenShift using WildFly, JBoss Tools, Forge, Arquillian, and OpenShift. Specifically it talks about:

  • How a Java EE application can be easily developed using JBoss Developer Studio and deployed directly to OpenShift
  • Set up Test and Production instances on OpenShift
  • Enable Jenkins to provide Continuous Integration
  • Run the tests on Test and push the WAR to Production

More detailed blog entries are at:

And a lot more at blog.arungupta.me/tag/openshift/.

Enjoy!

Modular Java EE applications with OSGi (Hanginar #3)

This hanginar (#1, #2) with Paul Bakker (@pbakker) shows how to build modular Java EE applications.

Learn all about:

  • Why is it important to build modular Java EE applications?
  • How OSGi enables modular applications?
  • See bndtools plugin in action using Eclipse
  • Learn how to transform an existing Java EE application to be modular
  • How to take a modular application to production?
  • Learn about Amdatu – open source OSGi components that enable Java EE modular applications

Many thanks to Paul Bakker (@pbakker) and Luminis for all the great work on enabling modular Java EE applications and participating in this series! Most of the work shown in this webinar is also explained in an O’Reilly book: Building Modular Clouds Apps with OSGi (co-authored with @BertErtman).

A tentative list of speakers for upcoming hanginars is identified at github.com/javaee-samples/webinars. Each speaker is assigned an issue which allows you to ask questions. Feel free to file an issue for any other speaker that should be on the list.

The next hanginar will be advertised ahead of time so that any body can participate!

Patching Weld 3 in WildFly 8.2 – First Experimental RI of Java EE 8 (Tech Tip #63)

Java EE 8 is moving along and several new component JSRs have been filed. JSR 365 will define the specification for CDI 2.0. Red Hat has already started working on the implementation prototype in Weld 3 and Alpha3 was released recently.

The Java EE 8 compliant application server from Red Hat will be WildFly where all the different technologies will be implemented. In the meanwhile, how do you try out these early experimental releases?

Tech Tip #29 showed how to patch WildFly 8.x from a previous release. This tip will leverage that mechanism to install Weld 3 Alpha3 in WildFly 8.2. You can also download Weld 3 Alpha3 Standalone or Weld 3 Alpha3 as patch to WildFly 9.0 Alpha1.

The instructions are rather simple:

  1. Download and unzip WildFly 8.2:
  2. Download Weld 3 Alpha3 Patch for WildFly 8.2:
  3. Apply the patch as (also available in README bundled in the patch):
  4. Start WildFly:
  5. Run a simple CDI test from javaee7-samples:
    and see output in the WildFly console as:
    Note that the Weld version of “3.0.0 (Alpha 3)” is shown appropriately in the logs.

In terms of features, here is what is available so far:

  • Declarative ordering of observer methods using @Priority
  • Ability for an extension to veto and modify an observer method
  • Support for Java 8 repeatable annotations as qualifiers and interceptor bindings
  • Enhanced AnnotatedType API
  • Asynchronous events
  • Simplified configuration of Weld-specific properties
  • Guava is no longer used internally

More details, including code samples, are explained in Weld 3.0.0 Alpha1 Released and An update on Weld 3. All the prototyped API is in org.jboss.weld.experimental package indicating the early nature.

Here are some resources for you to look at:

  • Javadocs
  • Maven coordinates
  • Feedback at Weld forums or the cdi-dev mailing list.

Created Java EE 8 Samples repository and will start adding some CDI 2.0 samples there, stay tuned.

Enjoy!

Run Java EE Tests on Docker using Arquillian Cube (Tech Tip #62)

Tech Tip #61 showed how to run Java EE 7 Hands-on Lab using Docker. The Dockerfile used there can be used to create a new image that can deploy any Java EE 7 WAR file to the WildFly instance running in the container.

For example github.com/arun-gupta/docker-images/blob/master/javaee7-test/Dockerfile can be copied to the root directory of javaee7-samples and be used to deploy jaxrs-client.war file to the container. Of course, you first need to build the sample as:

The exact Dockerfile is shown here:

If you want to deploy another Java EE 7 application, then you need to do the following steps:

  • Create the WAR file of the sample
  • Change the Dockerfile
  • Build the image
  • Stop the previous container
  • Start the new container

Now, if you want to run tests against this instance then mvn test alone will not do it because either you need to bind the IP address of the Docker container statically, or dynamically find out the address and then patch it at runtime. Anyway, the repeated cycle is little too cumbersome. How do you solve it?

Meet Arquillian Cube!

Arquillian Cube allows you to control the lifecycle of Docker images as part of the test lifecyle, either automatically or manually.

The blog entry provide more details about getting started with Arquillian Cube, and this functionality has now been enabled in “docker” branch of javaee7-samples. Arquillian Cube Extension Alpha2 was recently released and is used to provide integration. Here are the key concepts:

  • A new “wildfly-docker-arquillian” profile is being introduced
  • The profile adds a dependency on:
  • Uses Docker REST API to talk to the container. Complete API docs shows the sample payloads and explains the query parameters and status codes.
  • Uses WildFly remote adapter to talk to the application server running within the container
  • Configuration for Docker image is specified as part of maven-surefire-plugin.:
    Username and password are specified are for the WildFly in arungupta/javaee7-samples-wildfly image. All the configuration values can be overridden by arquillian.xml for each test case, as explained here.

How do you try out this functionality?

Here is a complete log of running simple-servlet test:

REST payload from the client to Docker server are shown here. This was verified on a Fedora 20 Virtual Box image. Here are some quick notes on setting it up there:

  1. Install the required packages
  2. Configure Docker
  3. Verify Docker TCP configuration

Boot2docker on Mac still has issue #49, this is Alpha2 after all :-)

Try some other Java EE 7 tests and file bugs here.

Enjoy!

Java EE 7 Hands-on Lab on WildFly and Docker (Tech Tip #61)

Java EE 7 Hands-on Lab has been delivered all around the world and is a pretty standard application that shows design patterns and anti-patterns for a typical Java EE 7 application. It shows how the following technologies can be used in a close-to-real-world application:

  • WebSocket 1.0
  • JSON Processing 1.0
  • Batch 1.0
  • Contexts & Dependency Injection 1.1
  • Java Message Service 2.0
  • Java API for RESTFul Services 2.0
  • Java Persistence API 2.0
  • Enterprise JavaBeans 3.1
  • JavaSever Faces 2.2

However the lab requires you to download NetBeans (Java EE 7 tooling) and WildFly or GlassFish (Java EE 7 runtime).

If you don’t want to follow the instructions and create the app, a pre-built solution zip file is available. But this still requires you to download Maven and build the app. You still have to download the runtime, which is pretty straight forward for WildFly, but still an extra task.

Maven step can be reduced using a pre-built WAR file, but runtime is still required.

Docker containers allows you to simplify application delivery by packaging all the key components together in an image. So how do you get the first feel of Java EE 7 hands-on lab with Docker ?

If you are new to Docker, Tech Tip #39 provide more background and details on how to get started. After initial setup, you can pull the Docker image that contains WildFly and pre-built Java EE 7 hands-on lab WAR file as shown:

And then you can run it as:

Find out the IP address where your container is hosted using boot2docker ip command. And now access your Java EE 7 application at http://<IP>/movieplex7. The app would look like:

techtip61-output

Here is the complete log shown by the Docker container:

Source code for this Dockerfile is pretty straight forward and at github.com/arun-gupta/docker-images/blob/master/javaee7-hol/Dockerfile.

Enjoy!

 

jOOQ and how it relates to JDBC, Java EE, Hibernate, etc (Hanginar #2)

Following up from Hanginar #1, this latest hanginar with Lukas Eder (@lukaseder) share more details about jOOQ.

Learn all about:

  • What is jOOQ ?
  • Why JOOQ when there is JDBC and JPA ?
  • How does it fit with Java EE apps ? Does it uses underlying JPA persistence provider or some other connection ?
  • Pros/cons over JPA ? Pure Hibernate ?
  • How well does it scale ?
  • Show code sample in a Java EE application
  • jOOQ for CRUD-based or domain-rich application ?
  • How can eventually all the work in jOOQ be integrated in JPA and be standardized ? Or would it be more of JDBC ?

Many thanks to Lukas Eder (@lukaseder) for all the great work on jOOQ and participating in this series!

A tentative list of speakers is identified at github.com/javaee-samples/webinars. Each speaker is assigned an issue which allows you to ask questions. Feel free to file an issue for any other speaker that should be on the list.

Remove Docker image and container with a criteria (Tech Tip #60)

You have installed multiple Docker images and would like to clean them up using rmi command. So, you list all the images as:

Then try to remove the “arungupta/wildfly-centos” image as shown below, but get an error:

So you follow the recommendation of using -f switch but get another error:

What do you do ?

This message indicates that the image is used by one of the containers and that’s why could not be removed. The error message is very ambiguous and a #9458 has been filed for the same.

In the meanwhile, an easy way to solve this is to list all the containers as shown:

There are lots of containers that are using “arungupta/wildfly-centos” image but none of them seem to be running. If there are any containers that are running then you need to stop them as:

Remove the containers that are using this image as:

The criteria here is specified as a grep pattern.

docker ps command has other options to specify criteria as well such as only the latest created containers or containers in a particular status. For example, containers that exited with status -1 can be seen as:

All running containers, as opposed to meeting a specific criteria, can be removed as:

And now the image can be easily removed as

Just like removing all containers, all images can be removed as:

Enjoy!