Category Archives: wildfly

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

javaee, techtip, wildfly, ,

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)

javaee, techtip, wildfly, , ,

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)

javaee, techtip, wildfly, ,

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!

 

Pushing Docker images to Registry (Tech Tip #58)

techtip, wildfly,

Tech Tip #57 explained how to create your own Docker images. That particular blog specifically showed how to build your own WildFly Docker images on CentOS and Ubuntu. Now you are ready to share your images with rest of the world. That’s where Docker Hub comes in handy.

Docker Hub is the “distribution component” of Docker, or a place to store and search images. From the Getting Started with Docker Hub docs …

The Docker Hub is a centralized resource for working with Docker and its components. Docker Hub helps you collaborate with colleagues and get the most out of Docker.

Starting and pushing images to with Docker Hub is pretty straight forward.

  • Pushing images to Docker Hub require an account. It can be created as explained here. Or rather easily by using docker login command.

    Searching on WildFly shows there are 72 images:

    Official images are tagged jboss/wildfly.
  • In order to push your own image, it needs to be built as a named image otherwise you’ll get an error as shown:

    This can be easily done as shown:

    docker build command builds the image, -t specifies the repository name to be applied to the resulting image.
  • Once the image is built, it can be verified as:

    Notice the first line shows the named image arungupta/wildfly-centos.
  • This image can then be pushed to Docker Hub as:
  • And you can verify this by pulling the image:

Enjoy!

 

Create your own Docker image (Tech Tip #57)

redhat, techtip, wildfly, ,

Docker simplifies software delivery by making it easy to build and share images that contain your application’s entire environment, i.e. operating system, JDK, database, WAR file, specific tuning required for your application, etc.

There are three main components of Docker:

  • Docker images are “build component” – a read-only template of application operating system.
  • Containers are “run component” – a runtime representation created from images.
  • Registry are “distribution component” – a place to store and distribute images.

Several JBoss projects are available as Docker images at www.jboss.org/docker. Tech Tip #39 explained how to get started with Docker on Mac. It also explained how to start the official WildFly Docker image.

Docker image is made up of multiple layers where each layer provides some functionality, and a higher layer can add functionality on top of it. For example, Docker mounts the root filesystem as read-only layer and then adds a read-write layer on top of it. All these layers are combined together using Union Mount to provide application operating environment.

The complete history of how the WildFly image was built can be seen as:

The exact command issued at each layer is listed in this output. If you scroll to the far right then you can see the total space consumed by each layer as well. For example, Fedora is used as the base image and consumes ~574 MB of the total image, Open JDK 7 is taking 217.5 MB and WildFly is 135 MB.

Docker images are built by reading the instructions from Dockerfile. This is a text file that contains all the commands, in order, needed to build a given image. It adheres to a specific format and use a specific set of instructions. The vocabulary of commands is rather limited but serves the purpose well. The image can be built by giving the command docker build. Docker Tutorial provides complete instructions on how to create your own custom image.

The official WildFly Docker image is built using Fedora 20 as the base operating system. The Dockerfile can be seen at github.com/jboss-dockerfiles/wildfly/blob/master/Dockerfile. It uses  jboss/base-jdk:7 as the base image, which uses jboss/base as the base image. Dockerfile of jboss/base shows Fedora 20 is used as the base image.

An alternative is to build this image using CentOS or Ubuntu as a base image. Dockerfiles for these images are available at github.com/arun-gupta/docker-images/.

Starting boot2docker shows the output as:

And then you can build the CentOS-based WildFly Docker image as shown below. Note this command is given from the “wildfly-centos” directory of github.com/arun-gupta/docker-images/. And so the Dockerfile is at github.com/arun-gupta/docker-images/blob/master/wildfly-centos/Dockerfile.

The list of Docker images can now be seen as:

The total image size is 619.6 MB. The official WildFly Docker image can be installed as shown:

And the complete list of Docker images can again be seen as: