Enterprise grade Java.
You'll read about Conferences, Java User Groups, Java, Integration, Reactive, Microservices and other technologies.

Wednesday, December 24, 2014

2014, twenty fourteen going on fifteen. Happy Holidays!

00:00 Wednesday, December 24, 2014 Posted by Test No comments:
, ,
I can't recall when I started doing those end-of-the-year blog-posts. But it became something that I am really looking forward to do. Getting into the mood of looking back at 12 months, 365.242 days, 8765.808 hours and even more seconds. By the average 6.8 hours of sleep per night, this gives us ~17 hours per day. A decent percentage of this went into my jobs and hobbies. I've always been passionate about what I've been doing. And this did not change since mid July, when I decided to join Red Hat. I've meet so many great people and it was fun to explore and learn the Red Hat way.
My special thanks to the communities around the many amazing JBoss open source projects. You guys rock! It is fun to watch how everything evolves and all the pieces come together. I am truly looking forward to spread the word about all the exciting new things coming to a bunch of my favorite projects.

But for now, this year is over. And it is time to close a book with may colorful pages. It'll take some time, until I open the first page of 2015. The time in between the years will be all about family and presents and food and smiles and glazing eyes for Christmas.
I wish you a prosperous and happy new year and hope to see you soon somewhere on any of the upcoming conferences or Java User Group sessions or on the virtual JBUG.

“We are the authors of our destinies. No one can see the vision any clearer, believe in and work any harder to make it a reality more than the visionary.”
― Nike Campbell-Fatoki

Tuesday, December 23, 2014

Riding Camel on Java EE 7 - REST Services with Swagger Documentation

11:05 Tuesday, December 23, 2014 Posted by Test No comments:
, , ,
Camel comes with a bunch of features out of the box. One of them is the Swagger integration. Unfortunately, most of the already-there features heavily rely on Spring. But this should not stop us from using them in plain Java EE 7 applications, because it sometimes is just the more lightweight variant of doing things. But I don't want to start a discussion about this again. Instead, I think that there is a technology choice for all situations and if you run across a project you just want to use Camel with Java EE 7 and you need REST services and want to document them with Swagger, this is the right post for you.

Bootstrapping Camel in EE 7
The first thing you need, is to bootstrap Camel in a singleton startup bean. I already wrote an article, about how to do this. The other option is to actually use the wildfly-camel subsystem which is also available, but this requires you to be on JBoss WildFly 8.x.

Swagger And Camel Rest Dependencies
The Swagger integration in Camel as of today is supported for Spring applications only. So, to make this work, we do have to implement a bit and configure a bit more than usual. But I promise, that it is not too complicated and done in a minute. Let's start:
First thing to add to the basic Camel EE 7 example are the additional dependencies for camel:


Returning The Camel Context For Swagger
If we can't use what is there, we need to implement our own CdiRestSwagger-Camel context lookup. There are some things cooking for upcoming Camel versions, but for now we have to do it on our own. Which is surprisingly simple, because we need to overwrite one method of the  RestSwaggerApiDeclarationServlet. And this does nothing else than simply return the injected CdiCamelContext.

public class CdiRestSwaggerApiDeclarationServlet extends RestSwaggerApiDeclarationServlet {

    CdiCamelContext context;

    public CamelContext lookupCamelContext(ServletConfig config) {
        return context;

Some Further Configuration
We're not done yet. You still have some more configuration to do. As Camel is designed to run in many different environments and there is no specific Java EE 7 version, it still rely on web.xml configuration for the mapping servlets. Please pay extra attention to the CdiRestSwaggerApiDeclarationServlet init-parameters. In this simple example, I did not bother with finding them out, but still rely on them. So, depending on the final name of your application that you set in the Maven build, this needs to be tweaked.

        <!-- to use Java DSL -->

    <!-- to setup Camel Servlet -->
       <display-name>Camel Http Transport Servlet</display-name>

    <!-- to setup Camel Swagger api servlet -->
        <!-- we are using our own swagger-cdi binding servlet -->
            <param-value>         http://localhost:8080/camel/api-docs          </param-value>
            <param-value>User Services</param-value>
            <param-value>Camel Rest Example with Swagger that provides an User REST service</param-value>

    <!-- swagger api declaration -->

    <!-- define that url path for the Camel Servlet to use -->

    <!-- enable CORS filter so people can use swagger ui to browse and test the apis -->


Enough Configuration - To The Logic!
When you're done with that, you need some logic. The example I'm using here was taken from the official Camel examples and is called camel-example-servlet-rest-tomcat. Please note, that this example contains both, a XML DSL based definition and the Java DSL based definition of the rest-service. I only used the Java DSL and specifically the route defined in the UserRouteBuilder class.
Make sure to add a @Named annotation to the UserService and the User and add the route from the UserRouteBuilder to your startup bean.

   context.addRoutes(new UserRouteBuilder());

That is it. Now you can browser your API by accessing http://localhost:8080/camel/api-docs. If you want to use the Swagger UI you have to add it to your application. The example application contains everything in the build section, that is needed to do this. So, have a look at the complete GitHub project to find out how to browse the API with the Swagger UI.

Monday, December 22, 2014

I'm speaking at JDK.IO 2015, 19 - 20 January in Copenhagen, Denmark

12:00 Monday, December 22, 2014 Posted by Test No comments:
Another confirmation came in. JDK.IO will be my first stop in 2015. This is the annual conference of the Danish Java User Group (Java Gruppen) and it has been extended this year. Instead of one day it is going to be a full two day conference.
The name is an acronym for Java Denmark Input Output - ie a conference for people who reside and work in Denmark with an interest in the Java programming language as such, and all the libraries and platform based on Java.

The confirmed sessions:

Monday 19th January 2015, 12.30-14.00
Architecting Large Enterprise Java Projects
In the past I've been building component oriented applications with what I had at hand. Mostly driven by the features available in the Java EE standard to be "portable" and easy to use. Looking back this has been a perfect fit for many customers and applications. With an increasing demand for highly integrated applications which use already available services and processes from all over the place (departmental, central or even cloud services) this approach starts to feel more and more outdated. And this feel does not come from a technology perspective but from all the requirements around it. Having this in mind this post is the starting point of a series of how-to's and short tutorials which aim to showcase some more diverse ways of building (Java EE) applications that fit better into today's requirements and landscapes.

Tuesday 20th January 2015, 16.00-17.30
Wild Flies and a Camel - Java EE Integration Stories
Apache Camel is one of the most complete integration frameworks out there. With more than 150 components and a large community it clearly has it's fans. Deploying the lightweight core is easy. Getting into modules and even more components makes this challenging. There are different approaches to ride that Camel. How to get the most out of it with Java EE and WildFly is exactly the topic of this session. It will introduce you to both Java EE 7 and Apache Camel in a very brief way and follows up with the different integration and deployment scenarios along with introducing the tools which help you the most on the way to your integration solution.

Monday, December 15, 2014

Running Java Mission Control and Flight Recorder against WildFly and EAP

00:00 Monday, December 15, 2014 Posted by Test No comments:
, , ,
Java Mission Control (JMC) enables you to monitor and manage Java applications without introducing the performance overhead normally associated with these types of tools. It uses data which is already getting collected for normal dynamic optimization of the JVM resulting in a very lightweight approach to observe and analyze problems in the application code. The JMC consists of three different types of tools. A JMX browser which let's you browse all available JVM instances on a machine and a JMX console which let's you browse through the JMX tree on a connected JVM. Last but not least the most interesting aspect is the Java Flight Recorder (JFR). This is exactly the part of the tooling which does the low overhead profiling of JVM instances.

Disclaimer: A Word On Licensing
The tooling is part of the Oracle JDK downloads. In particular the JMC 5.4 is part of JDK 8u20 and JDK 7u71 and is distributed under the Oracle Binary Code License Agreement for Java SE Platform products and commercially available features for Java SE Advanced and Java SE Suite. IANAL, but as far as I know this allows for using it for your personal education and potentially also as part of your developer tests. Make sure to check back with whomever you know that could answer this question. This blog post looks at it as a small little how-to and assumes, that you know what you are doing from a license perspective.

Adding Java Optional Parameters
Unlocking the JFR features requires you to put in some optional parameters to your WildFly 8.x/EAP 6.x configuration. Find the  $JBOSS_HOME/bin/standalone.conf|conf.bat and add the following parameters:
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder

You can now use jcmd command like described in this knowledge-base entry to start a recording. Another way is actually to start a recording directly from JMC.

Starting A Recording From JMC
First step is to start JMC. Find it in the %JAVA_HOME%/bin folder. After it started you can use the JVM Browser to find the WildFly/EAP instance you want to connect to. Right click on it to see all the available options. You can either start the JMX Console or start a Flight Recording. The JMX console is a bit fancier than the JConsole and allows for a bunch of metrics and statistics. It also allows you to set a bunch of triggers and browser MBeans and whatnot. Please look at the documentation for all the details. What is really interesting is the function to start a Flight Recording. If you select this option, a new wizard pops up and lets you tweak the settings a bit. Beside having to select a folder where the recording gets stored you also have the choice between different recording templates.

A one minute recording with the "Server Profiling" template with barely any load on the server results in a 1.5 MB file. So, better keep an eye on the volume you're storing all that stuff at.
You can also decide the profiling granularity for a bunch of parameters further down the dialogues. But at the end, you click "Finish" and the recording session starts. You can decide to push it to the background and keep working while the data gets captured.

Analyzing Flight Recorder Files
This is pretty easy. You can open the recording with JMC and click through the results. If you enabled the default recording with the additional parameter:

you can also directly dump the recording via the JVM browser. It is easy to pick a time-frame that you want to download the data for or alternatively you can also decide to download the complete recording.

Thursday, December 11, 2014

Docker All The Things for Java EE Developers - On Windows with Maven

12:00 Thursday, December 11, 2014 Posted by Test 1 comment:
, , ,
Everybody seems to do Docker these days. And the whole topic gets even more attraction with Microsoft committed to integrate it into Windows. As many middleware developers are running Windows, I thought I give it a try myself and also give some more tips along the way about how to build and run images with the least possible amount of struggle with Docker containers, hosts and guests and command line options. Arun did a very nice introduction to Docker on a recent blog-post. I'm skipping this here and directly dive into it.

Installing Boot2Docker
The Docker Engine uses Linux-specific kernel features, so to run it on Windows we need to use a lightweight virtual machine. There is a helper application called Boot2Docker which makes installing and running everything pretty straight forward. The first step is to download the latest version of the binary installer and execute it. It will install Oracle VirtualBox, MSYS-git, the boot2docker Linux ISO, and the Boot2Docker management tool. Next stept is to run the Boot2Docker start script (there's a little whale icon on your desktop after the install). It will setup the Docker host and connect via ssh to the host. If you want to do that again at a later state, you can simply type: boot2docker ssh.

There is no Docker client for Windows based systems for now. So, ssh basically is a workaround which works pretty good and is probably also a well known way. With Microsoft's recently announced new partnership with Docker, this might change soonish. If you want to build your own Docker client, you find some more information in Khalid Mouss' blog post about it.
Some tips for you. You need to have the %MSYS-git_INSTALL%/bin directory in your PATH. It contains a  cmd line ssh client. If you want to use PUTTY make sure to connect to the Docker host using user "root" and password "tcuser".
If you are running any kind of VPN client, you will absolutely run into trouble. Docker normally runs in Host-only mode and and installed VPN client turns this into NAT. Go to the VirtualBox management console and open the settings for the boot2docker-vm and add a port forwarding rule for the Docker API. We will need this later.

A little warning: The default Docker API port is 2375. In my case this wasn't true, so I had to first find out which port the Docker API is listening on. Do this with netstat on your host. So, I basically used a direct guest to host mapping on 2376 in this example. All done. Now you're ready to launch the hello world example. Just type "docker run hello-world" and wait for a "Hello from Docker.". Now you're good to go.
If you need a complete reference for Boot2Docker, this is a very helpful site.

Why Exactly Do We Do Docker?
What is the hype around Docker these days? There is a little history in it and it might on the long run also support microservice deployments by just defining complete packages that can be deployed. Including the infrastructure requirements. Think of Docker containers as application servers which can run defined images. And think of images as large Maven archives which does not only contain your application but also the OS and all the parts that are needed to run your application. Like it or not, but everybody is playing around with it and at the end of the day, it is a way to solve some problems. I'm not telling you, that I fell in love with it instantly, but at least I want it to help me with demos and showcases. And the thought, that I only have to define a bunch of dependencies and Maven Plugins in my Java EE applications and everything magically just runs is something I like. But let's look at what it takes and how to do it.

Already Available Images - e.g. WildFly
Speaking of images: There are a bunch of images ready to go. We at JBoss have a special microsite ready for you with all the Docker images that we have ready for you to run. If you want to use any of them you basically just install them in your container and start it. By doing this, you can just have any component running, basically like you would have it running locally on your machine. The only difference is, that it runs in your "Docker Host". If you want to start WildFly all you have to do is to issue the following Docker command:
docker run -it -p 9990:99 jboss/wildfly
Docker automatically pulls the relevant bits (which might take a while) and starts a container from this image. The port mapping actually is between the host and the container. Remember the VPN problems from above? Make sure to add the port mapping in VirtualBox also if you want to try that out. The outcome is pretty clear: You now have a WildFly running in a container. Map the needed ports and just use it as you would normally use a remote instance. If you want even more images, you can browse and search the Docker Hub. There's plenty out there already.
Using Docker like that is not exactly the idea behind it. Actually, the image should contain not only the base component but also a completely configured application in it. 

Building You Own Images - All The Different Ways
Therefore you need to build your own images. There are different ways of doing that. You can either update a container created from an image and commit the results to an image. Or create your own Dockerfile to specify instructions to create an image or you can use a build tool like Maven to create your image. The Dockerfile approach is very powerful and requires quite a bit of typing and vi-magic. I was looking for an easy way to create an image from Maven. Because, this is what I use for projects anyway.

Building A Docker Image With Maven
There are many different Maven plugins out there which actually offer this kind of feature I was looking for. At the end of the day, the Fabric8 team was using the Maven-Docker-Plugin made by Roland Huß. The plugin can build and publish images but also start and stop containers for integration testing and development. I struggled a bit with setting it up and I am still playing around with the best ways to integrate it into my applications, so this is basically a first first list of my findings and solutions and no complete user-guide. Please look at the samples and the official user guide of the plugin for more details. I will build a complete example in one of my next blog posts and walk you through it.

DOCKER_HOST Environment variable
First thing for this plugin to work is obviously the DOCKER_HOST environment variable. As the whole experience of Windows is a bit clumsy for now, this variable isn't set when you start your vm. Good news is, that you already figured everything you need to know out by installing and doing the port mapping. So, you basically just set it:
set DOCKER_HOST=tcp://
Make sure to point your general <configuration> section in the maven-docker-plugin to the same

Certificates and HTTPS Connections
Since 1.3.0 Docker remote API requires communication via SSL and authentication with certificates when used with boot2docker. So, you need to configure the certificates. Find them in the .boot2docker/certs folder and make sure to also add this path to your plugin configuration.

That's it for now. Let me know if you also have experiences about how to work with Docker on Windows.

Saturday, December 6, 2014

Setting Timeout for the JAX-RS 2.0 / Resteasy Client

07:40 Saturday, December 6, 2014 Posted by Test No comments:
, ,
Adam asked me about that at NetBeans Day in Munich. One part of the JAX-RS Client API isn't fully standardized but still very important looking at today's microservice architectures. I am talking about timeouts here. Adam showed how to set them for Jersey and I just needed to find out how to do the same with Resteasy.

import javax.ws.rs.client.Client;
import org.jboss.resteasy.client.jaxrs.ResteasyClient;
import org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder;

 Client client = new ResteasyClientBuilder()
                .establishConnectionTimeout(100, TimeUnit.SECONDS)
                .socketTimeout(2, TimeUnit.SECONDS)

ResteasyClientBuilder is basically an abstraction for creating Clients which uses Apache Http Client under the covers. That's it.

Friday, December 5, 2014

Camel Subsystem for WildFly 8 integrates Java EE - Getting Started

15:00 Friday, December 5, 2014 Posted by Test No comments:
, , , ,
Just three days ago, the team around Thomas Diesler (@tdiesler) released the 2.0.0.CR1 version of the WildFly-Camel subsystem it allows you to add Camel Routes as part of the WildFly configuration. Routes can be deployed as part of JavaEE applications. JavaEE components can access the Camel Core API and various Camel Component APIs.
This release in particular added a number of new camel components to the subsystem and added support for the WildFly domain mode. Other than packaging and bootstrapping Camel in Java EE 7 yourself, this subsystem installs Camel directly into your WildFly 8.x server. As far as I know it even works with the latest 8.2.0.Final but isn't tested against it. Not, that there is a very light and easy way to bootstrap Camel in Java EE 7, but this approach enables even more integrations with Java EE standards. The ultimate goal for the subsystem is to provide Camel features as a directly usable option in WildFly without the need to configure or deploy anything. This is the main difference between a simple module and a complete subsystem.

Getting Started
Install WildFly 8.x by downloading the "Java EE7 Full & Web Distribution" from wildfly.org. Install by just extracting it into a folder of your choice. Next step is to download the distribution patch (53 MB, tar.gz) for WildFly from the JBoss Maven repository. After the download, navigate to the WildFly folder and extract the archive into it. That's it. Now start either standalone or domain mode with the respective *-camel.xml:
$ bin/standalone.sh|bat -c standalone-camel.xml

Some More Configuration
After we did that, you need to add some more users. First of all the management user.
$ bin/add-user.sh|bat 
Call it whatever you like. For convenience reasons I tend to name it admin with the password admin. But please keep in mind, that this is the worst practice you could apply ;)
After you're done with that, add another application user. To make it simple, we just name it the same with the same, insecure password.

Exploring What's There
After you integrated the subsystem into your WildFly you can find the Apache Camel and JBoss modules in the module folder. The standalone\deployments folder contains two war-files. One of them is HawtIo and the other one is the wildfly-camel.war which is basically the camel-cdi example but more on that later. First of all, point your browser to: http://localhost:8080/hawtio/ and login with the application user you created.

You can see, that the ActiveMQ and Camel tabs are enabled, which means both modules have been deployed and discovered by HawtIo. Drilling down into the Camel tab you can see two deployed routes. The versions used for the integration are Apache Camel 2.14.0, HawtIo 1.4.22 and Arquillian 1.1.2.Final.

High Level Features
The strategy of wildfly-camel is, that a user can “just use” the camel core/component APIs in deployments that WildFly supports already. In other words, Camel should “just work” in standard Java EE deployments. The binaries are be provided by the platform. The deployment should not need to worry about module/wiring details.
Defining and Deploying Camel Contexts can be done in different ways. You either can directly define a Context in your standalone-camel.xml server configuration or deploy it as part of your web-app either as a single XML file with a predefined -camel-context.xml file suffix or as part of another WildFly supported deployment as META-INF/jboss-camel-context.xml file.
The WildFly Camel test suite uses the WildFly Arquillian managed container. This can connect to an already running WildFly instance or alternatively start up a standalone server instance when needed. A number of test enrichers have been implemented that allow you have these WildFly Camel specific types injected into your Arquillian test cases; you can inject a CamelContextFactory or a CamelContextRegistry as an  @ArquillianResource.

Next Steps
You can simply undeploy the wildfly-camel.war and start over with your own application. You can either dig into the existing examples on GitHub or wait for my next blog-post to walk you through that a bit.
If you don't want to mess around with installing and patching, you can look at the ready available docker images which were published at wildflyext/wildfly-camel.

More Information
Apache Camel Website
WildFly Camel Integration GitBook
Planned Roadmap

I'm now a NetBeans Dream Team Member!

09:00 Friday, December 5, 2014 Posted by Test No comments:
, , ,
The NetBeans Dream Team is a community-driven group of highly skilled NetBeans users and contributors. They participate at NetBeans developer events, on mailing lists and developer forums, providing new, interesting and informative content as well as developing new and creative ways to promote and enhance NetBeans. And as of today, I'm accepted as a new member to this exclusive group of passionate people.
This might look a little odd, as most of my readers know that I am working at Red Hat and we have our "own" IDE. This is a good time to remember all of you about what open source is and that contributing isn't limited to companies or products. As long as the software is great, there is always a chance to work together. And looking at NetBeans and Red Hat/JBoss technologies a lot has been done in the past and many other parts are evolving.

WildFly Integration
Emmanuel Hugonnet (@ehsavoie) is the maintainer of the WildFly Plugin for NetBeans. Since NetBeans 8.0.1 this is built into the core and available for everybody to use WildFly directly from NetBeans. If you want to know more, make sure watch my developer interview with him.

OpenShift Integration
Cojan van Ballegooijen (@cvanball) is working on tooling to integrate Red Hat OpenShift as a Cloud service into NetBeans. You can contribute to his efforts by just forking the repository and sending patches.

And There Is More
I am convinced, that there is a lot more to do. A Camel integration would be a perfect next step. I might start doing one myself. If you are interested, I would love to organize a little project around it.

A big thanks to the NB team and the dream team members for accepting me. It will be a pleasure to work with you.

Thursday, December 4, 2014

Developer Interview (#DI 9) - Antoine Sabot-Durand (@antoine_sd) about CDI 2.0 and Java EE 8

12:00 Thursday, December 4, 2014 Posted by Test No comments:
, , ,
Time for another episode in my developer interview series. Yesterday I had the pleasure to talk to Antoine Sabot-Durand (@antoine_sd) who is the co-spec-lead of JSR 365 (Contexts and Dependency Injection for Java 2.0). Besides working on the CDI specification, he is also responsible for the CDI ecosystem at Red Hat - currently focused on DeltaSpike. He's also tech lead on Agorava, a CDI framework helping social media consuming.
He has been an IT consultant since 1996, and a Java developer since 2000. Today he is a senior software engineer at Red Hat.

Antoine often fly from his Paris home to meet the community by speaking at Devoxx, Java One, or various JUGs. When not writing specification, coding, tweeting or giving talks, Antoine likes spending time with his wife and 3 children.

Sit back, relax and get a #Coffee+++! Thanks Antoine  for taking the time!

Tuesday, December 2, 2014

Java EE with NetBeans on OpenShift

15:00 Tuesday, December 2, 2014 Posted by Test No comments:
, , ,
Today was NetBeans Day in Munich. I had the pleasure to present one session about the integration of Red Hat's products with my famous IDE. So, I've been talking about WildFly, EAP, Git, OpenShift Online and showed all the different ways optimize your development workflow with that tool-set.

It's been roughly 100 attendees and it was a pleasure to be there. Thanks everybody for making it, even if half of Germany was on strike or close to a traffic collapse. Here are the slides for your viewing pleasure. Please make sure to check out all the links in it.