Category Archives: javaee

Domain Driven Design using Java EE (Hanginar #5)

javaee,

Domain Driven Design

 

Domain Driven Design (DDD) is very well suited for typical three-tier Java EE applications and allows a close collaboration between technical and domain experts to iteratively define a model. Learn all about the basics of DDD and how to create a non-trivial Java EE application using DD in this webinar with Reza Rahman (@reza_rahman).

The source code shows:

  • Well established architectural patterns/blueprints for enterprise development with Java EE using pretty close to a real world application.
  • Demonstrate a concrete implementation of DDD concepts.
  • Showcase some core Java EE technologies (JSF, CDI, WebSocket, Batch, JAX-RS, JMS, Bean Validation, and others)
  • Select set of representative tools that complement Java EE well such as Maven, JUnit, Cargo, JMeter, soapUI, Arquillian, PrimeFaces and DeltaSpike

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!

Modular Java EE applications with OSGi (Hanginar #3)

javaee, , , ,

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)

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!

 

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

javaee, , , , ,

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.

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!

Continuous Deployment with Java EE 7, WildFly, and Docker – (Hanginar #1)

conferences, javaee, , ,

This blog is starting a new hanginar (G+ hangout + webinar) series that will highlight solutions, frameworks, application servers, tooling, deployment, and more content focused on Java EE. These are not the usual conference-style monologue presentations, but are interactive hackathons where real working stuff is shown, and is mostly code-driven. Think of this as a mix of, and inspired by, Nighthacking (@_nighthacking), Virtual JUG (@virtualjug), and virtual JBUG (@vjbug) but focussing purely on Java EE technology.

There are so many cool things happening in the Java EE platform and ecosystem around it, and they need to be shared with the broader community, more importantly at a location where people can go back again and again. Voxxed.com has graciously offered to host all the videos and be the central place for this content.

The first such webinar, with none other than Adam Bien (@adambien), in that series just went live. It discusses how to do Continuous Deployment with Java EE 7 and Docker. It will also show how to go from “git push” to production in less than a minute, including rebooting your Docker containers and restarting all your microservices.

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.

What would you like to see ? Spec leads ? App servers ? Why this over that ? Design patterns and anti-patterns ? Anonymous customer use cases ? What frequency would you like to see ? Use G+ hangout on air ?

As with any new effort, we’ll learn and evolve and see what makes best sense for the Java EE community.

So what’s the mantra ? Code is king, give some love to Java EE!

 

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!

Java EE 7 Video Course on voxxed.com

conferences, javaee,

java-ee-logo voxxed

Voxxed.com is a new initiative by the successful team behind Devoxx. This was announced at Devoxx 2014 Belgium keynote. Some of the key aspects of Voxxed are:
  • It’s a space to share ideas – whether that means submitting articles, tutorials, or blog posts, or telling the Voxxed editorial team about some news or ideas you’ve got that you’d like them to broadcast on your behalf to the whole community.
  • “Devoxx everyday,” bringing together the best of the conversation from the Java ecosystem into one portal.
  • A place to facilitate discussion and wider learning with curated links to wider Parleys presentations and interviews.
  • A new kind of media portal which will be hugely influenced by the community that uses it.

Stephan Janssen (@stephan007), the serial entrepreneur and the man behind Devoxx had to say the following about this initiative:

The Voxxed story starts with Devoxx, which I started in part so that I could get my personal fix of the best tech content around. I’m proud of how important Devoxx has become for developers in this community, but it only happens a few times a year. Where can I go then for a daily community hit, especially with online media so fragmented? So I thought, let’s bring everything together by pulling in blog feeds, reporting news, and housing tutorials, presentations and training courses – everything that people share that makes Devoxx what it is, into one place

There are so many people out there with amazing tech know-how that fly under the radar. I hope Voxxed can be the place where they share their stories. It’s also somewhere for new talent to shine. The Rockstars of our sector probably had their first speaking gig at a local community event. But not everyone enjoys the sometimes terrifying arena of a few hundred people staring back at them. By letting the community publish online, Voxxed gives new voices a platform. Today is just the first stage – a site that looks good, is easy to use and has great content. The next stage is for the community to drive it with excellent content and ideas”

Lucy Carey (@Lucyrushi), editor of Voxxed, says:

I love the creativity and energy of the tech sector, and one of the best parts of my job is being able to share stories from the people behind all the exciting stuff that this huge community is generating. When I heard that there was an opportunity to get involved with a new site developed by the people behind Parleys and Devoxx, I was hugely keen to come on board.

I’m proud and excited to be part of the inaugural launch of voxxed.com with a video course on Learning Java EE 7 Essentials, check out a preview:

The first version of this course provide introduction to the following Java EE 7 technologies:

  • Java API for WebSocket (JSR 356)
  • Java API for JSON Processing (JSR 353)
  • Batch Processing for the Java Platform (JSR 352)
  • Concurrency Utilities for Java EE (JSR 353)
  • Java API for RESTful Services (JSR 339)
  • Java Message Service (JSR 343)
  • Contexts & Dependency Injection (JSR 346)

The four new technologies in the course, WebSocket, JSON-P, Batch, and Concurrency, are explained in detail. Key features of JAX-RS 2.0, JMS 2.0, and CDI 1.1 are explained in detail, with a clearly marked emphasis on new features added in Java EE 7.

This is purely a technology-focused course. So whether you are using WildFly, GlassFish, or TmaxSoft JEUS today or will be using JBoss EAP 7+, WebLogic 12.1.4+, WebSphere Liberty Profile or any other Java EE 7 compliant application server, this course would be a great way to understand the key concepts of technology.It discusses the patterns and anti-patterns of different technologies using code-extensive slides.

Buy the course here!

If your team is embarking on a new project that uses Java EE 7 technology, this course will server as a great introduction as well. The usual benefits of parleys.com such as offline viewing, synchronized slides + video, ability to skip slides etc are all available as well.

Future additions planned for this course are:

  • JavaServer Faces (JSR 344)
  • Java Servlets (JSR 340)
  • Java API for Persistence (JSR 338)
  • Enteprise JavaBeans (JSR 345)
  • Develop/Deploy/Debug a Java EE 7 Application Eclipse
  • Develop/Deploy/Debug a Java EE 7 Application using NetBeans
  • Develop/Deploy/Debug a Java EE 7 Application using IntelliJ
  • Java EE 7 Development/Deployment on OpenShift

The course is available at an introductory low price of €69.99. Bulk pricing discounts are also available, drop a comment on the blog for that. However this price will increase as more course items are added in the next few weeks. If you purchase the course today, then future updates/additions are free!

So, act now and purchase this course today :-)

Many thanks to Carlo and rest of the Parleys team for their wonderful support through out the process!

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!

WebSocket Chat on WildFly and OpenShift (Tech Tip #51)

javaee, techtip, wildfly, , ,

Chat is one of the most canonical sample to explain WebSocket. Its a fairly commonly used interface and allows to explain the fundamental WebSocket concepts very easily. Of course, Java EE 7 WebSocket has one too, available here! You can easily run it on WildFly using the following steps:

And then access it at http://localhost:8080/chat/.

One of the biggest advantage of WebSocket is how it opens up a socket over the same port as HTTP, 8080 in this case. If you want to deploy this application to OpenShift, then WebSocket is available on port 8000 for regular access, and 8443 for secure access. This is explained in the figure below:

openshift-websocket-routing

 If you want to run this Chat application on OpenShift, then use the following steps:

  1. Click here to provision a WildFly instance in OpenShift. Change the name to “chatserver” and everything else as default. Click on “Create Application” to create the application.
  2. Clone the workspace:
  3. Edit the first line of “javaee7-samples/websocket/chat/src/main/webapp/websocket.js”from:

    to
  4. Create the WAR file:
  5. Copy the generated WAR file to the workspace cloned earlier:
  6. Remove existing files and add the WAR file to git repository:

    And this shows the output as:

And now your chat server is available at: http://chatserver-milestogo.rhcloud.com and looks like:

techtip51-websocket-chat-output

Enjoy!

Securing WebSocket using wss and HTTPS/TLS (Tech Tip #50)

javaee, techtip, wildfly, ,

50th tip on this blog, yaay!

Tech Tip #49 explained how to secure WebSockets using username/password and Servlet Security mechanisms. This Tech Tip will explain how to secure WebSockets using HTTPS/TLS on WildFly.

Lets get started!

  1. Create a new keystore:

    Used “websocket” as the convenience password.
  2. Download WildFly 8.1, unzip, and copy “websocket.keystore” file in standalone/configuration directory.
  3. Start WildFly as
  4. Connect to it using jboss-cli as:
  5. Add a new security realm as:

    And configure it:
  6. Add a new HTTPS listener as:
  7. A simple sample to show TLS-based security for WebSocket is available at github.com/javaee-samples/javaee7-samples/tree/master/websocket/endpoint-wss. Clone the workspace and change directory to “websocket/endpoint-wss”. The sample’s deployment descriptor has:

    This ensures that any request coming to this application will be auto-directed to an HTTPS URL.
  8. Deploy the sample by giving the command:

Now accessing http://localhost:8080/endpoint-wss redirects to https://localhost:8080/endpoint-wss. The browsers may complain about self-signed certificate. For example, Chrome shows the following warning:

techtip50-certificate-chrome

And Safari shows the following warning:

techtip50-certificate

In either case, click on “Proceed to localhost” or “Continue” to proceed further. And then a secure WebSocket connection is established.

Another relevant point to understand is that a non-secure WebSocket connection cannot be made from an https-protected page. For example the following code in our sample:

will throw the following exception in Chrome Developer Tools:

Enjoy!