Category Archives: redhat

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

containers, techtip, wildfly, , ,

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!

Java EE Workflows on OpenShift (Tech Tip #64)

javaee, redhat, techtip, wildfly, , ,

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!

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)

containers, 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)

containers, 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)

containers, 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:

The image size in this case is 948.7 MB. A detailed understanding of this image is created was explained earlier in this blog.

Ubuntu-based WildFly image can be built and installed as shown below. Note this command is given from the “wildfly-ubuntu” directory of github.com/arun-gupta/docker-images/. And so the Dockerfile is at github.com/arun-gupta/docker-images/blob/master/wildfly-ubuntu/Dockerfile.

The list of Docker images can once again be seen as:

Docker image can run with docker run command. Some other related commands are:

  • docker ps: Lists containers
  • docker stop <id>: Stops the container with the given <id>

Run CentOS image as shown below. Specifying -i option will make it interactive and -t option allocates a pseudo-TTY. And port 8080 from the container is made accessible on port 80 of the container.

In a different shell, get the container’s IP address as:

And then access WildFly at http://192.168.59.103.

Similarly, running the WildFly Ubuntu image shows:

You can login to the host VM as shown:

Different layers of the image are stored in /var/lib/docker directory as shown:

VM image on Mac OSX is stored in ~/VirtualBox VMs/boot2docker-vm directory. This directory can grow up rather quickly if the intermediate containers are not removed. boot2docker-vm.vmdk on my machine is ~5GB for these different images.

You can reset it by running the following commands (WARNING: This will destroy all images you’ve downloaded and built so far):

Containers, as you can imagine, have a memory foot print.

More Docker goodness is coming in subsequent blogs!

Deployment Pipeline for Java EE 7 with WildFly, Arquillian, Jenkins, and OpenShift (Tech Tip #56)

javaee, techtip, wildfly, , , , ,

Tech Tip #54 showed how to Arquillianate (Arquillianize ?) an existing Java EE project and run those tests in remote mode where WildFly is running on a known host and port. Tech Tip #55 showed how to run those tests when WildFly is running in OpenShift. Both of these tips used Maven profiles to separate the appropriate Arquillian dependencies in “pom.xml” and <container> configuration in “arquillian.xml” to define where WildFy is running and how to connect to it.

This tip will show how to configure Jenkins in OpenShift and invoke these tests from Jenkins. This will create deployment pipeline for Java EE.

Lets see it in action first!

Configuration required to connect from Jenkins on OpenShift to a WildFly instance on OpenShift is similar to that required for  connecting from local machine to WildFly on OpenShift. This configuration is specified in “arquillian.xml” and we can specify some parameters which can then be defined in Jenkins.

On a high level, here is what we’ll do:

  • Use the code created in Tech Tip #54 and #55 and add configuration for Arquillian/Jenkins/OpenShift
  • Enable Jenkins
  • Create a new WildFly Test instance
  • Configure Jenkins to run tests on the Test instance
  • Push the application to Production only if tests pass on Test instance

Lets get started!

  1. Remove the existing boilerplate source code, only the src directory, from the WildFly git repo created in Tech Tip #55.
  2. Set a new remote to javaee7-continuous-delivery repository:
  3. Pull the code from new remote:

    This will bring all the source code, include our REST endpoints, web pages, tests, updated “pom.xml” and “arquillian.xml”. The updated “pom.xml” has two new profiles.

    Few points to observe here:

    1. “openshift” profile is used when building an application on OpenShift. This is where the application’s WAR file is created and deployed to WildFly.
    2. A new profile “jenkins-openshift” is added that will be used by the Jenkins instance (to be enabled shortly) in OpenShift to run tests.
    3. “arquillian-openshift” dependency is the same as used in Tech Tip #55 and allows to run Arquillian tests on a WildFly instance on OpenShift.
    4. This profile refers to “jenkins-openshift” container configuration that will be defined in “arquillian.xml”.

    Updated “src/test/resources/arquillian.xml” has the following container:

    This container configuration is similar to the one that was added in Tech Tip #55. The only difference here is that the domain name, application name, and the SSH user name are parametrized. The value of these properties is defined in the configuration of Jenkins instance and allows to run the test against a separate test node.

  4. Two more things need to be done before changes can be pushed to the remote repository. First is to create a WildFly Test instance which can be used to run the tests. This can be easily done as shown:

    Note the domain here is milestogo, application name is mywildflytest, and SSH user name is 546e3743ecb8d49ca9000014. These will be passed to Arquillian for running the tests.

  5. Second is to enable and configure Jenkins.In your OpenShift Console, pick the “mywildfly” application and click on “Enable Jenkins” link as shown below:techtip56-enable-jenkinsRemember this is not your Test instance because all the source code lives on the instance created earlier.Provide the appropriate name, e.g. jenkins-milestogo.rhcloud.com in my case, and click on “Add Jenkins” button. This will provision a Jenkins instance, if not already there and also configure the project with a script to build and deploy the application. Note down the name and password credentials.
  6. Use the credentials to login to your Jenkins instance.Select the appropriate build, “mywildfly-build” in this case. Scroll down to the “Build” section and add the following script right after “# Run tests here” in the Execute Shell:

    Click on “Save” to save the configuration. This will allow to run the Arquillian tests on the Test instance. If the tests pass then the app is deployed. If the tests fail, then none of the steps after that step are executed and so the app is not deployed.

  7. Lets push the changes to remote repo now:

    The number of dots indicate the wait for a particular task and will most likely vary for different runs.  And Jenkins console (jenkins-milestogo.rhcloud.com/job/mywildfly-build/1/console) shows the output as:

    Log files for Jenkins can be viewed as shown:

    This shows the application was successfully deployed at mywildfly-milestogo.rhcloud.com/index.jsp and looks like as shown:

    techtip56-mywildfly-output-tests-passing

Now change “src/main/webapp/index.jsp” to show a different heading. And change  “src/test/java/org/javaee7/sample/PersonTest.java” to make one of the tests fail. Doing “git commit” and “git push” shows the following results on command line:

The key statement to note is that deployment is halted after the tests are failing. And you can verify this by revisiting mywildfly-milestogo.rhcloud.com/index.jsp and check that the updated “index.jsp” is not visible.

In short, tests pass, website is updated. And tests fail, the website is not updated. So you’ve built a simple deployment pipeline for Java EE 7 using WildFly, OpenShift, Arquillian, and Jenkins!

Arquillian tests on a WildFly instance hosted on OpenShift (Tech Tip #55)

javaee, techtip, wildfly, , , ,

Tech Tip #54 explained how to enable Arquillian for an existing Java EE project. In that tip, the tests were run against a locally installed WildFly server. Would the same adapter work if this WildFly instance was running on OpenShift ? No!

Because the security constraints and requirement of a PaaS, as opposed to a localhost, are different. Lets take a look at what’s required to run our tests in javaee7-continuous-delivery on a WildFly instance hosted on OpenShift.

Lets get started!

  1. As explained in Tech Tip #52, create a WildFly application on OpenShift as shown:

    Note down the ssh user name from the log. This is the part before @ in the value corresponding to SSH to.
  2. Until FORGEPLUGINS-177 is resolved, we need to manually add maven profile and provide container configuration information in “arquillian.xml”. Add the following <profile> to “pom.xml”:

    This is using arquillian-openshift container and referring to arquillian-wildfly-openshift configuration that will be matched with the appropriate container in “arquillian.xml”.

    So this is how the updated “arquillian.xml” look:

    Note the new <container> with the qualifier arquillian-wildfly-openshift. It provides information about where the server is located and some other configuration properties. The sshUserName property value should be the same from the WildFly instance created earlier.

  3. That’s it, now you can run the test against the WildFly instance on OpenShift:

The complete source code is available at github.com/arun-gupta/javaee7-continuous-delivery.

Enjoy!

Enable Arquillian on an existing Java EE project, using Forge Addon (Tech Tip #54)

javaee, jboss, techtip, , , ,

Tech Tip #34 explained how to create a testable Java EE 7 application. This is useful if you are starting a new application. But what if you already have an application and Arquillian-enable it ?

That’s where Forge and Forge-Arquillian add-on comes in handy. That’s how I added support for Arquillian in javaee7-simple-sample. The updated source code is at github.com/arun-gupta/javaee7-continuous-delivery.

Lets see what was done!

  1. Download and install Forge. You can download ZIP and unzip in your favorite location, or just use the following command that does it for you:
  2. Clone the simple-javaee7-sample repo
  3. Change the directory to javaee7-simple-sample and start Forge:
  4. Install the Forge-Arquillian add-on:
  5. Configure Arquillian add-on and install WildFly adapter:

    The list of adapters is diverse as shown:

    This allows you to configure the container of your choice. This will add the following profile to your “pom.xml”:

    The profile includes the “wildfly-arquillian-container-remote” dependency which allows Arquillian to connect with a WildFly running in remote “mode”. The default host is “localhost” and port is “8080”. The “maven-surefire-plugin” is passed a “arquillian.launch” configuration property with the value “arquillian-wildfly-remote”. This is matched with a “container” qualifier in the generated “arquillian.xml”.

    “arquillian.xml” is used to define configuration settings to locate or communicate with the container. In our case, WildFly is running on default host and port and so there is no need to update this file. The important part to note is that the “container” qualifier matches with the “arquillian.launch” qualifier value.

    This file. More details about this configuration file are available here.

  6. Until FORGE-2148 is fixed, you also need to add a JAX-RS implementation as well, and the corresponding JAXB provider. This test is using RESTEasy and so the following needs to be added:

    This can be added either in the profile or project-wide dependencies.

And now you are ready to test!

Download WildFly 8.1 and unzip. Start the server as:

Run the tests:

And now you’ve Arquillian-enabled your existing project!

Once again, the complete source code is available at github.com/arun-gupta/javaee7-continuous-delivery.

File any issues here.

Enjoy!

Slides from Nuts and Bolts of WebSocket at #Devoxx 2014

conferences, javaee, wildfly, , ,

Peter Moskovits from Kaazing (@peterm_kaazing) and I gave a university talk at Devoxx 2014 on Nuts and Bolts of WebSocket. The slides are now available at:

The entire session is recorded and will be made available on parleys.com in the coming weeks/months.

The complete script for the demo is available at github.com/arun-gupta/nuts-and-bolts-of-websocket (including pointers to the demos). Most of the demos are anyway available at the following links:

Positive feedback from twitter overall:

And it was rated the top talk for the day until 6pm:

devoxx14-websocket-talk-rank

With Red Hat spirit, “the more you share, the more you grow”, share the slides and demos all over and spread the love!

Happy Devoxx!

STOMP over WebSocket (Tech Tip #53)

techtip, wildfly,

STOMP is Simple Text Oriented Messaging Protocol. It defines an interoperable wire format that allows a STOMP client to communicate with any STOMP message broker. This provides easy and widespread messaging interoperability among different languages, platforms and brokers.

The specification defines what makes it different from other messaging protocols:

It is an alternative to other open messaging protocols such as AMQP and implementation specific wire protocols used in JMS brokers such as OpenWire. It distinguishes itself by covering a small subset of commonly used messaging operations rather than providing a comprehensive messaging API.

STOMP is a frame-based protocol. A frame consists of a command, a set of optional headers and an optional body. Commonly used commands are:

  • CONNECT
  • SEND
  • SUBSCRIBE
  • UNSCUBSCRIBE
  • ACK
  • NACK
  • DISCONNECT

WebSocket messages are also transmitted as frames. STOMP over WebSocket maps STOMP frames to WebSocket frames.

Different messaging servers like HornetQ, ActiveMQ, RabbitMQ, and others provide native support for STOMP over WebSocket. Lets take a look at a simple sample on how to use STOMP over WebSocket using ActiveMQ.

The source code for the sample is available at github.com/arun-gupta/wildfly-samples/tree/master/websocket-stomp.

Lets get started!

  1. Download ActiveMQ 5.10 or provision an ActiveMQ instance in OpenShift as explained at github.com/arun-gupta/activemq-openshift-cartridge.
  2. Download WildFly 8.1 zip, unzip, and start as bin/standalone.sh
  3. Clone the repo and deploy the sample on WildFly:
  4. Access the application at localhost:8080/websocket-stomp-1.0-SNAPSHOT/ to see the page as:techtip53-default-page
  5. Specify text payload “foobar and usse ActiveMQ conventions for topics and queues to specify a queue name as “/queue/myQ1″. Click on Connect, Send Message, Subscribe, and Disconnect buttons one after the other. This will display messages on your browser window where WebSocket connection is established, STOMP message is sent to the queue, subscribed to the queue to receive the message, and then finally disconnected.STOMP frames can be seen using Chrome Developer Tools as shown:

    techtip53-websocket-frames

    As you can see, each STOMP frame is mapped to a WebSocket frame.

In short, ActiveMQ on OpenShift is running a STOMP broker on port 61614 and is accessible on localhost:61614 by port-forwarding. Clicking on Connect button uses the Stomp library bundled with the application to establish a WebSocket connection with ws://localhost:61614/. Subsequent buttons send STOMP frames over WebSocket as shown in the Frames tab of Developer Tools.

Read more details about how all the pieces work together at jmesnil.net/stomp-websocket/doc/. Jeff has also written an excellent book explaining STOMP over WebSocket and lot more other interesting things that can be done over WebSocket in his Mobile and Web Messaging book.

 

Create WildFly OpenShift application using Command Line Tools (Tech Tip #52)

java, redhat, techtip, wildfly,

A new instance of WildFly can be easily provisioned on OpenShift by using the quick start. Just a single click, and you are ready to go!

Generally power users of OpenShift use Command Line Tools. However you could not create WildFly cartridge using the CLI tools. But bug# 1134134 is now resolved.

And so now rhc cartridge-list shows:

The newly added cartridge of WildFly 8 is shown in bold.

And so now a new WildFly instance can be easily provisioned using the CLI as:

And then the application’s main page is accessible as shown:

techtip52-main-page

And the application can be deleted as:

Simple, isn’t it ?

See several other OpenShift getting-started related blog entries here.

Ceylon JUG Tour 2014 Summary

conferences, redhat

Gavin King and Stéphane Épardaud talked about Ceylon in some of the Java User Groups in the East Coast of USA the past month. Knowing both the speakers, the feedback from different JUGs is not surprising:

The presentation was great – best introduction to a new language. Gavin made a great case for Ceylon.

The attendees stuck around until 9:30 asking questions (except for 1 or 2 people). The meeting was a success – especially for a new language.

The language looks very exciting – the cross-VM support is especially interesting. Gavin did an excellent job of showing the benefit of Ceylon versus Java and during the Q&A of discussing it in relation to Scala.

I think the talk went well.  Gavin did a great job at presenting some of problems Ceylon tries to solve. I really appreciated his walk through of the type system.  There were between 30 and 40 people there and there was also some good QnA about the platform. There was interest about Ceylon on Android and also the state of the tooling, debugging, etc.

Thank you for your great presentations and for visiting our JUG.  It was definitely one of the best technical presentations I’ve seen.

And some feedback received on twitter:

Ryan Cuprak (@rcuprak) highlighted their visit to Connecticut JUG and couple of points seem to come out strong:

Ceylon looks to be a significant leap forward

I would prefer it over JavaScript any day of the week. Ceylon also looks more approachable than Scala

We are planning JUG tours in other parts of the world, stay tuned. In the meanwhile, would you be interested in a G+ hangout for your JUG by these two wonderful speakers ?

Have you tried Ceylon recently ? Try Ceylon compiler, IDE, and SDK.

ceylon-logo