Jeff Mesnil

Working @ IBM

2025-09-01T12:52:18+00:00

Short story: As of today, I'm working for IBM. Same team, same project - with a shorter email.

Long story: Back in February, Red Hat announced that they were transferring their middleware division to IBM.

My position as a Software engineer was moved as a part of this transfer, and I've chosen to continue the journey here.

In the near term, I'll keep working on WildFly and JBoss EAP - focusing on their cloud & provisioning capabilities, user experience, and more. Business as usual.

As for the longer term, we'll see...

I had a great time at Red Hat and I will always look back fondly. Many of my colleagues in middleware are also moving to IBM, but I’ll miss those who stayed behind.

Red is in the past, blue is the color of the future. Here's to the next chapter of my career!

Script to format GitHub links

2025-05-06T09:47:36+00:00

Almost all my code contributions go in various GitHub projects, either the original repositories or my forks.

Every time I use an URL to a GitHub issue or PR in Google Docs, Markdown or Asciidoc document, I update the link text to be more descriptive so instead of displaying the raw URL as https://github.com/wildfly/wildfly.org/pull/787, it is displayed as [wildfly/wildfly.org#787] Add Jeff Mesnil GPG Signing info.

I'm changing these links so often that I wrote a simple bash script to do it for me. The script can take an GitHub issue or PR argument and will output the corresponding text: [<org>/<repo>#<pr_or_issue>] <title>:

#!/bin/bash

# Get URL from argument or clipboard
if [ -n "$1" ]; then
 URL="$1"
elif command -v pbpaste &>/dev/null; then
 URL="$(pbpaste)"
else
 echo "No URL provided and pbpaste is not available."
 exit 1
fi

# Extract repo and number from GitHub issue or PR URL
if [[ "$URL" =~ github\.com/([^/]+/[^/]+)/(issues|pull)/([0-9]+) ]]; then
 REPO="${BASH_REMATCH[1]}"
 NUMBER="${BASH_REMATCH[3]}"
else
 echo "Invalid GitHub issue or pull request URL: $URL"
 exit 1
fi

# Fetch and parse the <title> content
HTML_TITLE=$(curl -s "$URL" | sed -n 's:.*<title>\(.*\)</title>.*:\1:p' | head -n1)

# Decode HTML entities
HTML_TITLE=$(echo "$HTML_TITLE" | sed -e "s/&#39;/'/g" -e 's/&quot;/\"/g' -e 's/&amp;/\&/g')

# Remove ' by AUTHOR' (before any dot)
HTML_TITLE=$(echo "$HTML_TITLE" | sed -E 's/ by [^·]+//')

# Remove everything after the first literal '·' (U+00B7), regardless of spacing
CLEAN_TITLE=$(echo "$HTML_TITLE" | sed 's/·.*//')

# Final formatted output
OUTPUT="[$REPO#$NUMBER] $CLEAN_TITLE"

# Copy to clipboard
if command -v pbcopy &>/dev/null; then
 echo "$OUTPUT" | pbcopy
else
 echo "Warning: Clipboard tool not found."
fi

# Output to terminal
echo "$OUTPUT"

afplay /System/Library/Sounds/Tink.aiff

To make it even simpler to use on my Mac, if there are no argument, it will instead use the content from the clipboard with pbpaste. It also copies the title to the clibpboard with pbcopy and play a sound when it is finished.

I saved this script as a "Format GitHub Link" shortcut with Apple Shortcuts to further streamline its use:

Run the script as an Apple Shortcut

Now, When I want to add a GitHub link to a document, all I need to do is:

copy its link address (⌘ C)
paste it in my doc (⌘ V)
use the Spotligh launcher to run the script (⌘ <space bar> > "Format")
After I hear the sound, copy the formatted title from the clipboard (⌘ V)

Prototyping WildFly Applications with JBang (Video)

2025-03-26T08:34:33+00:00

Yesterday was held the WildFly mini conference - March 2025 where I presented how you can use JBang to prototype Entreprise Java applications with WildFly.

The presentation was streamed on YouTube WildFly channel:

Unfortunately, the streaming was a bit compressed and made it difficult to read the code so you might be bettre looking at the slides directly.

The conference was a great success. Don't hesitate to provide some feedback about the presentation and if you are interested to have similar content about the user experience improvements we are making around WildFly.

⇨ Prototyping WildFly with JBang @ WildFly Mini Conference

2025-03-17T10:06:19+00:00

Next week, I'll talk about prototyping WildFly application with JBang at the WildFly mini-conference on March 25th.

JBang is a tool to create, edit and run self-contained source-only Java programs with unprecedented ease. In this presentation, I will show how we can use JBang to prototype simple WildFly applications from a single Java source file. We start with a simple Web application and will prototype an AI chat bot.

The JBang integration was added to WildFly in this proposal and you can already use it and learn about it from the WildFly Glow documentation.

The presentation will be done live on the WildFly YouTube channel. See you there!

⚑

Deliver Go applications as containers

2024-10-31T11:07:26+00:00

I switched to a Apple Silicon laptop running on a ARM architecture and I often want to develop Go applications that are running both on ARM architecture (to run it on my laptop) as well as on Intel.

Go makes it very easy to target different architectures at build time but it makes the delivery of the software more complex as I have to deliver multiple binaries (linux on ARM, linux on Intel, Darwin on ARM, Darwin on Intel, etc.) There are tools for this such as GoReleaser but it still makes the deployment of the software more complex. A potential solution is to have a script file that determines the OS & architecture of the target platform and then download the appropriate executable.

Another solution that I am using more often is to deliver the software as a multi-arch container image. The user then just has to pull the image and run it with podman or docker.

As as simplistic example, let's say I need to write a Go application that gives the SHA-256 checksum of strings.
To do so, I can create a Go module with a simple checksum application:

$ mkdir checksum
$ cd checksum
$ go mod init checksum
$ mkdir cmd
$ touch cmd/checksum.go

The content of the cmd/checksum.go is:

package main

import (
 "crypto/sha256"
 "encoding/hex"
 "fmt"
 "os"
)

func main() {

 if len(os.Args) == 1 {
 fmt.Printf("No arguments\n")
 fmt.Printf("Usage: checksum <list of strings to hash>\n")
 os.Exit(1)
 }

 strs := os.Args[1:]

 hash := sha256.New()

 for i, str := range strs {
 h.Reset()
 hash.Write([]byte(str))
 checksum := hash.Sum(nil)
 if i > 0 {
 fmt.Printf(" ")
 }
 fmt.Printf("%s", hex.EncodeToString(checksum))
 }
 fmt.Printf("\n")
}

I can test that the application is working as expected by running it with go run:

$ go run ./cmd/checksum.go foo
2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae

Now, I need to create a container that provides this application for both the ARM and Intel architectures.

I need a simple Containerfile to do so:

FROM golang:1.23 AS go-builder

WORKDIR /workspace/
COPY . .
RUN GOOS=linux go build -o ./build/checksum ./cmd/checksum.go

FROM scratch

COPY --from=go-builder /workspace/build/checksum /
ENTRYPOINT [ "/checksum" ]

The container build is done in two stages:

I use the golang:1.23 builder to compile the code, targeting the linux operating system.
I create an image from scratch that only contains the executable compiled from the first stage.

Then I can use podman to build a multi-arch image (for both linux/amd64 and linux/arm64):

$ podman build --platform linux/amd64,linux/arm64 --manifest localhost/checksum .

The resulting localhost/checksum image is small and contains only the checksum executable.

I can run it locally with podman:

$ podman run localhost/checksum foo

2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae

Podman will run the linux/arm64 image on my ARM laptop but an user on a Intel machine would use the linux/amd64 image. I can force Podman to use the Intel variant on my ARM laptop and it would run fine too (with a warning that the image no longer matches my platform)

$ podman run --platform linux/amd64 localhost/checksum foo

WARNING: image platform (linux/arm64) does not match the expected platform (linux/amd64)
2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae

At this point, to make the application available for others, I just need to push it to a container registry on Quay.io or ghcr.io and they will be able to use it as I do on my laptop.

This solution works fine for programs that don't need heavy integration with the host operating system. If my input would need to access the file system, I would have to mount directories with -v to make them available inside the image. If the integration with the host starts to be more complex, it would be better to provide a shell script that pulls the image and run Podman with the right configuration parameters.

Dikembe Mutombo (1966-2024)

2024-10-01T13:31:24+00:00

Dikembe Mutombo All Star Card

I learnt yesterday the sad news that Dikembe Mutombo passed away at the age of 58 from a brain cancer.

He started his career in 1991 as I got interested in the NBA. He was a great player to watch as I enjoy the defensive side of Basket ball.

I fondly remember when he fell down the floor after upsetting the Seattle SuperSonics of Gary Payton and Shawn Kemp. That was the first time a 8^th seed won against a 1^st seed and his joy was contagious.

23 years later, I still have player cards from him that I scanned for this post.

Dikembe Mutombo Player Card

Next time I play with my kids, I'll show them how he was wagging his finger when he blocked an opponent shot :)

20-year anniversary of jmesnil.net

2024-09-12T12:17:15+00:00

I missed the date but I posted the first article on this blog on June, 11th 2024.

Twenty years later, and 350 posts later, my server is still there serving all the content I wrote from the start.

I went through different hosts and visual presentation until I settled down with using a AWS S3 Buck to host this static server built with Awestruct.

Out of nostalgia, I played with the Wayback Machine to remember of my web site looked over the years.

The initial version was hosted on Movable Type using their standard template. I made some terrible visual choice that I quickly removed for a cluttered look before going full page on the content that I stripped down to the current design.

On the technical side, I don't remember all the solutions but I used Movable Type, BlogPost, WordPress. Eventually, I switched to a static generation of the content from Markdown pages in a Git repository that are pushed to a AWS S3 Bucket.

The latest technical changes I did were to use a container image to manage all the Ruby dependencies from Awestruct and adding a TLS Certificate to the server.

I have had bursts of activity on my web site and long periods of neglects but it is still great to have a place I can call my own on the Web...

My Professional Mission Statement

2024-09-10T10:09:11+00:00

[This week is Career Week at my company and a great opportunity to reflect on my career and what lies ahead]

A few years ago, my manager, Stefano, introduced me to the concept of defining personal Mission and Vision statements to help me guide my career.

I updated my About page some time ago with my professional mission statement but never elaborated on it. This post is a good opportunity to do so.

My professional mission statement is:

I aim to build software based on sustainability, openness, and humane values, driving towards a more equitable world.

I'm an engineer at heart so building software is what I do and what I enjoy the most.

We are facing a climate change that is impacting all humanity and it is our duty for ourselves and future generations to do as much as we can to circumvent it. In my profession, the best I can do is build sustainable software that have minimal carbon impact on the planet.

There are many approaches to build software, but I only want to do it in a way that fosters openness, transparency and human-centered values. I have been fortunate to work for many years with great colleagues and users that are kind, knowledgeable, willing to listen, giving and receiving constructive feedback.

I can't imagine switching to another working environment as I believe in a variant of Conway's law:

Organizations which design systems are constrained to produce designs which copy the behaviours of these organizations.

By acting with transparency and empathy, we are more likely to build software that creates a more open and humane world.

All I am doing professionally is making sure that I contribute to a better world for my kids, and the world I want for them is an equitable one where every individual has opportunities to grow, learn, and accomplish their goals.

I do not want to build software that benefits a few at the expense of the rest of the humanity. That is what attracted me to Open Source development at the beginning of my career, and I still believe in it more than 20 years later.

Unfortunately, my mission statement is at odds with most of the IT industry which aims for infinite growth at the expense of users, citizens, its own employees and the planet.

I have to live with that dichotomy and do my best to align the world with my values and beliefs. My mission statement is a simple effective way to never lose sight of what is truly meaningful to me.

Engineering is Problem-solving

2024-09-09T08:57:50+00:00

Last weekend, I discussed with a friend the different approaches we had in our jobs.

I told him an anecdote from my study years.

I have a mathematical background and studied applied mathematics with a sprinkle of computing and applied physics.

During a trimester, our Physics teacher taught us a single theorem (sadly, I can't remember which one...). We had an upcoming exam and what could it be about if not this theorem? The day of the exam, we all applied the theorem as expected... and we all failed the exam.

During the correction, our teacher told us that we all applied the theorem to the stated problem without verifying that the constraints and boundaries were applicable. They were not and the theorem was not a solution to the problem.

The teacher explained to us that he "tricked" us on purpose. His objective was not to make us learn and apply the theorem but to make us think by ourselves:

First, understand the problem, its constraints, and its boundaries.
Then see if there is an equation, a theorem that could apply to its resolution.
Finally, use this tool to solve the problem optimally.

I told this anecdocte to my friend because that might be the best advice I got during all my studies.

As an engineer, my main task is to solve "problems" that our users face with the toolkits at their disposal.

The toolkits in the IT industry are ever expanding (Cloud! Microservices! Blockchains! Now AI!) and an increasing part of my work is to figure out if a tool is relevant for a given problem.

The reasoning should follow the advice of my teacher: first understand the problem to solve, then find the solutions that can be applied to it and finally find the optimal solution for the problem.

Of course, it is easier said than done as there is a strong industry push to find a technical solution to then apply it to any problem.

Let's move all our workloads to the cloud!
Let's add a chatbot to our applications!
Let's split our monolithic application into microservices!

These tools are fine and definitely suitable for many cases, but they are never universally applicable.

Following trends without ensuring they address the specific issue at hand can lead to wasted effort and resources, leaving us with all the downsides of a new technology without reaping its benefits.

Problem-solving is the most creative aspect of my engineering job, the one I enjoy the most and (talking about the latest IT trend) the one least likely to be replaced by artificial intelligence.

WildFly - The GitOps Way

2024-03-05T11:54:32+00:00

We have improved the Maven plug-in for WildFly to be able to provision and configure WildFly application server directly from the application source code. This make it very simple to control the server configuration and management model and make sure it is tailor-made for the application requirements.

This is a good model for DevOps team where a single team is responsible for the development and deployment of the application.

However, we have users that are in a different organisational structure where the Development team and the Operational team work in silos.

In this article, we will show how it is possible to leverage the WildFly Maven plugin to handle the configuration and deployment of WildFly separately from the application development in a loose GitOps manner.

Provision the WildFly Server

We will use a Maven project to control the application server installation and configuration.

mkdir wildfly-gitops
cd wildfly-gitops
touch pom.xml

The pom.xml will configure the provisioning and configuration of WildFly

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>org.wildfly.gitops</groupId>
 <artifactId>wildfly-gitops</artifactId>
 <version>1.0.0-SNAPSHOT</version>

 <packaging>pom</packaging>
 <properties>
 <!-- Specify the version of WildFly to provision -->
 <version.wildfly>31.0.0.Final</version.wildfly>
 <version.wildfly.maven.plugin>4.2.2.Final</version.wildfly.maven.plugin>
 </properties>

 <build>
 <plugins>
 <plugin>
 <groupId>org.wildfly.plugins</groupId>
 <artifactId>wildfly-maven-plugin</artifactId>
 <version>${version.wildfly.maven.plugin}</version>
 <configuration>
 <feature-packs>
 <feature-pack>
 <groupId>org.wildfly</groupId>
 <artifactId>wildfly-galleon-pack</artifactId>
 <version>${version.wildfly}</version>
 </feature-pack>
 </feature-packs>
 </configuration>
 <executions>
 <execution>
 <id>provision-widfly</id>
 <phase>package</phase>
 <goals>
 <goal>provision</goal>
 </goals>
 </execution>
 </executions>
 </plugin>
 </plugins>
 </build>
</project>

This pom.xml will provision (install and configure) WildFly. The version of WildFly is configured with the version.wildfly property (set 31.0.0.Final in the snippet above).

Let's now install it with:

mvn clean package

Once the execution is finished, you have a WildFly server ready to run in target/server and you can run it with the command:

cd target/server
./bin/standalone.sh

The last log will show that we indeed installed WildFly 31.0.0.Final:

13:21:52,651 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 31.0.0.Final (WildFly Core 23.0.1.Final) started in 1229ms - Started 280 of 522 services (317 services are lazy, passive or on-demand) - Server configuration file in use: standalone.xml

At this point you can init a Git repository from this wildfly-gitops directory and you have the foundation to manage WildFly in a GitOps way.

The Maven Plugin for WildFly provides rich features to configure WildFly including:

using Galleon Layers to trim the server according to the deployment capabilities
Running CLI scripts to configure its subsystems (for example, the Logging Guide illustrates how you can add a Logging category for your own deployments)

[Aside] Create Application Deployments

To illustrate how to manage the deployments of application in this server without direct control of the application source code, we must first create these deployments.

When Dev and Ops teams are separate, the Dev team will have done these steps and the Ops team would only need to know the Maven coordinates of the deployments.

For this purpose, we will compile and install 2 quickstarts examples from WildFly in our local maven repository:

cd /tmp
git clone --depth 1 --branch 31.0.0.Final https://github.com/wildfly/quickstart.git
cd quickstart
mvn clean install -pl helloworld,microprofile-config

We have only built the helloworld and microprofile-config quickstarts and put them in our local Maven repository.

We now have two deployments that we want to deploy in our WildFly Server with the Maven coordinates:

org.wildfly.quickstarts:helloworld:31.0.0.Final
org.wildfly.quickstarts:microprofile-config:31.0.0.Final

Assemble The WildFly Server With Deployments

Now that we have deployments to work with, let's see how we can include them in our WildFly server in a GitOps manner.

We will use a Maven assembly to control the deployments in our server. To do so, we will create a assembly.xml file in the wildfly-gitops directory:

<assembly xmlns="http://maven.apache.org/ASSEMBLY/2.1.1"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.1 http://maven.apache.org/xsd/assembly-2.1.1.xsd">
 <id>gitops-server</id>
 <formats>
 <format>dir</format>
 </formats>
 <fileSets>
 <fileSet>
 <directory>target/server</directory>
 <outputDirectory/>
 </fileSet>
 </fileSets>

 <dependencySets>
 <dependencySet>
 <includes>
 <include>*:war</include>
 </includes>
 <outputDirectory>standalone/deployments</outputDirectory>
 <outputFileNameMapping>${artifact.artifactId}.${artifact.extension}</outputFileNameMapping>
 </dependencySet>
 </dependencySets>
</assembly>

All this verbose file does is:

create a directory that is composed of:
- the content of the target/server (that contains the WildFly Server)
- add any war dependency to the standalone/deployments of this directoy
  - and rename them to xxx.war (instead of the whole Maven coordinates)

We also need to update the pom.xml to use this assembly:

<project>
 [...]
 <build>
 [...]
 <plugins>
 [...]
 <plugin>
 <artifactId>maven-assembly-plugin</artifactId>
 <configuration>
 <finalName>wildfly</finalName>
 </configuration>
 <executions>
 <execution>
 <id>make-assembly</id>
 <phase>package</phase>
 <goals>
 <goal>single</goal>
 </goals>
 <configuration>
 <descriptors>
 <descriptor>assembly.xml</descriptor>
 </descriptors>
 </configuration>
 </execution>
 </executions>
 </plugin>
 [...]
</project>

We can now run a Maven command to assemble our server:

mvn clean package

When the command is finished, we now have an assembled server in target/wildfly-gitops-server/wildfly

cd target/wildfly-gitops-server/wildfly
./bin/standalone.sh

NOTE: There are 2 different "servers" after mvn package is executed:

target/server contains the provisioned WildFly Server
target/wildfly-gitops-server/wildfly contains the WildFly server (copied from the previous directory) with any additional deployments.

But we did not add any deployment! Let's do it now.

In the wildfly-gitops/pom.xml, we will add a dependency to specify that we want to include the helloworld quickstart:

<project>
 [...]
 <dependencies>
 <dependency>
 <groupId>org.wildfly.quickstarts</groupId>
 <artifactId>helloworld</artifactId>
 <version>31.0.0.Final</version>
 <type>war</type>
 </dependency>
 </dependencies>

And that's it!

Let's now run once more mvn clean package.

If we now list the standalone/deployments directory of the assembled server, the helloworld.war deployment is listed:

ls target/wildfly-gitops-server/wildfly/standalone/deployments
README.txt helloworld.war

When we run the assembled server, the HelloWorld application is deployed and ready to run:

cd target/wildfly-gitops-server/wildfly
./bin/standalone.sh

...
14:01:25,307 INFO [org.jboss.as.server] (ServerService Thread Pool -- 45) WFLYSRV0010: Deployed "helloworld.war" (runtime-name : "helloworld.war")

We can access the application by opening our browser at localhost:8080/helloworld/

At this stage, we have complete control of the WildFly server and the application(s) we want to deploy on it from this wildfly-gitops Git repository.

Let's see what we could do from here.

Add Another Deployment to The Server

We can now add the microprofile-config deployment to the assembled server by adding it as a dependency in the pom.xml:

<project>
 [...]
 <dependencies>
 [...]
 <dependency>
 <groupId>org.wildfly.quickstarts</groupId>
 <artifactId>microprofile-config</artifactId>
 <version>31.0.0.Final</version>
 <type>war</type>
 </dependency>
 </dependencies>

Let's package the server again and start it:

mvn clean package
cd target/wildfly-gitops-server/wildfly
CONFIG_PROP="Welcome to GitOps" ./bin/standalone.sh

The microprofile-config application is deployed and can be accessed from localhost:8080/microprofile-config/config/value

We have added deployments using Maven dependencies but it is also possible to include them in the assembled server by other means (copy them from a local directory, fetch them from Internet, etc.). The Assembly Plugin provides additional information for this.

Update The WildFly Server

The version of WildFly that we are provisioning is specified in the pom.xml with the version.wildfly property. Let's change it to use a more recent version of WildFly 31.0.1.Final

<project>
 [...]
 <properties>
 <!-- Specify the version of WildFly to provision -->
 <version.wildfly>31.0.1.Final</version.wildfly>

We can repackage the server and see that it is now running WildFly 31.0.1.Final:

mvn clean package
cd target/wildfly-gitops-server/wildfly
...
14:15:23,909 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 31.0.1.Final (WildFly Core 23.0.3.Final) started in 1938ms - Started 458 of 678 services (327 services are lazy, passive or on-demand) - Server configuration file in use: standalone.xml

Use Dependabot to Be Notified of WildFly Updates

WildFly provisioning is using Maven artifacts. We can take advantage of this to add a "symbolic" dependency to the WildFly Galleon Pack artifact in our pom.xml so that Dependabot will periodically check and propose updates when new versions of WildFly are available:

<project>
 [...]
 <dependencies>
 [...]
 </dependency>
 <!-- We add the WildFly Galleon Pack as a provided POM dependency
 to be able to use dependabot to be notified of updates -->
 <dependency>
 <groupId>org.wildfly</groupId>
 <artifactId>wildfly-galleon-pack</artifactId>
 <version>${version.wildfly}</version>
 <type>pom</type>
 <scope>provided</scope>
 </dependency>

We use a provided scope as we don't want to pull this dependency but this will ensure that Dependabot is aware of it and triggers updates when a new version is available.

Summary

In this article, we show how you can leverage the WildFly Maven Plug-in to manage WildFly in a GitOps way that is not directly tied to the development of the applications that are be deployed to the server.

The code snippets used in this article are available on GitHub at github.com/jmesnil/wildfly-gitops.

⇨ An Illustrated Guide to 12 Factor Apps

2023-09-13T13:19:31+00:00

Right after writing a wall of text that use the Twelve-Factor App methodology to frame what WildFly provides to develop and operate "cloudy" Entreprise Java applications, a colleague pointed me to this article on Red Hat web site that nicely illustrates each factor.

⚑

WildFly and the Twelve-factor App Methodology

2023-09-13T07:30:04+00:00

In my daily job at Red Hat, I'm focused these days on making WildFly run great on container platforms such as Kubernetes.

"Traditional" way to develop and run applications with WildFly

WildFly is a "traditional" application server for Entreprise Java applications. To use it on the cloud, we are making it more flexible and closer to "cloud-native" applications so that it can be used to develop and run a 12-Factor App.

Traditionally, if you were using WildFly on your own machine, the (simplified) steps would be:

Download WildFly archive and unzip it
Edit its XML configuration to match your application requirements
In your code repository, build your deployment (WAR, EAR, etc.) with Maven
Start WildFly
Copy your deployment
Run tests

At this point, your application is verified and ready to use.

There are a few caveats to be mindful of.

Whenever a new version of WildFly is available, you have to re-apply your configuration change and verify that the resulting configuration is valid.
You run tests against your local download of WildFly with your local modifications. Are you sure that these changes are up to date with the production servers?
If you are developing multiple applications, are you using different WildFly downloads to test them separately?

"Cloudy" way to develop and run applications with WildFly

When you want to operate such application on the cloud, you want to automate all these steps in a reproduceable manner.

To achieve this, we inverted the traditional application server paradigm.

Before, WildFly was the top-level entity and you were deploying your applications (ie WARs and EARs) on it. Now, your application is the top-level entity and you are in control of the WildFly runtime.

With that new paradigm, the steps to use WildFly on the cloud are now:

In your code repository, configure WildFly runtime (using a Maven plugin)
Use Maven to build your application
Deploy your application in your target container platform

Step (2) is the key as it automates and centralizes most of the "plumbing" that was previously achieved by hand.

If we decompose this step, it actually achieves the following:

Compile your code and generate the deployment
"Provision" WildFly to download it, change its configuration to match the application requirements
deploy your deployment in the provisioned WildFly server
Run integration tests against the actual runtime (WildFly + your deployments) that will be used in production
Optionally create a container image using docker

Comparing the two ways to develop and run WildFly can look deceiving. However, a closer examination shows that the "Cloudy" way unlocks many improvements in terms of productivity, automation, testing and, at least in my opinion, developer joy.

What does WildFly provide for 12-Factor App development?

The key difference is that your Maven project (and its pom.xml) is the single 12-factor's Codebase to track your application. Everything (your application dependencies, WildFly version and configuration changes) is tracked in this repo. You are sure that what is built from this repository will always be consistent. You are also sure that WildFly configuration is up to date with production server because your project is where its configuration is updated. You are not at risk of deploying your WAR in a different version of the server or a server that has not been properly configured for your application.

Using the WildFly Maven Plugin to provision WildFly ensures that all your 12-factor's Dependencies are explicitly declared. Wheneve a new version of WildFly is released, you can be notified with something like Dependabot and automatically test your application with this new release.

We have enhanced WildFly configuration capabilities so that you can store your 12-factor's Config in your environment. WildFly can now use environment variables to change any of its management attributes or resolve their expressions. Eclipse MicroProfile Config is also available to store any of your application config in the environment.

Connecting to 12-factor's Backing Services is straightforward and WildFly is able to connect to a database with a few env vars representing its URL and credentials with the datasources feature pack.

Using the WildFly Maven Plugin in your pom.xml, you can simply have different stages to 12-factor's Build, release, run and make sure you build once your release artifact (the application image) and runs it on your container platform as needed.

Entreprise Java application as traditionally stateful so it does not adhere to the 12-factor's Processes unless you refactor your Java application to make it stateless.

WildFly complies with 12-factor's Port binding and you can rely on accessing its HTTP port on 8080 and its management interfance on 9990.

Scaling out your application to handle 12-factor's concurrency via the process model is depending on your application architecture. However WildFly can be provisioned in such a way that its runtime can exactly fit your application requirements and "trim" any capabilites that is not needed. You can also split a monolith Entreprise Java application in multiple applications to scale the parts that need it.

12-factor's Disposability is achieved by having WildFly fast booting time as well as graceful shutdown capabilities to let applications finish their tasks before shutting down.

12-factor's Dev/prod parity is enabled when we are able to use continuous deployment and having a single codebase to keep the gap between what we develop and what we operate. Using WildFly with container-based testing tool (such as Testcontainers) ensures that what we test is very similar (if not identical) to what is operated.

WildFly has extensive logging capabilities (for its own runtime as well as your application code) and works out of the bow with 12-factor's Logs by outputting its content on the standard output. For advanced use cases, you can change its output to use a JSON formatter to query and monitor its logs.

12-factor's Admin processes has been there from the start with WildFly that provides a extensive CLI tool to run management operations on a server (running or not). The same management operations can be executed when WildFly is provisioned by the WildFly Maven Plugin to adapt its configuration to your application.

Summary

We can develop and operate Entrprise Java applications with a modern software methodology. Some of these principles resonate more if you targeting cloud environment but most of them are still beneficical for traditional "bare metal" deployments.

I. Codebase

Use the WildFly Maven Plugin to store WildFly information with your application code.

II. Dependencies

All dependencies (including WildFly) are managed by your application pom.xml.

III. Config

Use Eclipse MicroProfile Config and WildFly capabilities to read configuration from the environment.

IV. Backing Services

Jakarta EE is designed on this principle (eg JDBC, JMS, JCA, etc.).

V. Build, release, run

With a single mvn package, you can build your release artifact and deploy it wherever you want. The WildFly Maven Plugin can generate ate a directory or an application image to suit either bare-metal or container-based platform.

VI. Processes

WildFly can run stateless application but you will have to design them this way :)

VII. Port Binding

8080 for the application, 9990 for the management interface :)

VIII. Concurrency

Entreprise Java application have traditionally be scaling up so there is some architecture and application changes to make them scale out instead. The lightweight runtime from WildFly is definitely a good opportunity for scaling out Entreprise Java applications.

IX. Disposability

WildFly boots fast and gracefully shuts down.

X. Dev/prod parity

Use the WildFly Maven Plugin to control WildFly, container-based testing to reduce the integration disparity and keep changes between dev, staging and production to a minimum.

XI. Logs

WildFly outputs everything on the standard output. Optionally, you can use a JSON formatter to query and monitor your application logs.

XII. Admin processes

WildFly tooling provides CLI scripts to run management operations. You can store them in your codebase to handle configuration changes, migration operations, maintenance operations.

Conclusion

Using the "cloudy" way to develop and operate entreprise applications unlocks many benefits regardless of the deployment platform (container-based or bare metal).

It can automate most of the mundane tasks that reduce developer joy & efficiency while improving the running operations of WildFly improving operator joy & efficiency.

TLS certificate on jmesnil.net

2023-09-13T06:29:02+00:00

Web browers now treats sites served by HTTP as "Not secure". I finally caved in and added a TLS certificate to jmesnil.net.

Displayed Padlock achievement: completed

If you are visiting jmesnil.net, you can now browse it safely and be sure that your credit cards numbers will not be stolen. That's progress I suppose...

I host my site on Amazon AWS and use a bunch of their services (S3, Route 53, CloudFront, Certificate Manager) to be able to redirect the HTTP traffic to HTTPS (and the www.jmesnil.net URLs to jmesnil.net). I will see how much this increase the AWS bill...

More interestingly, I used Let's Encrypt to generate the certificates. It took me less than 5 minutes to generate it (including the acme challenge to verify the ownership of the jmesnil.net domain name). This project is a great example of simplifying and making accessible a complex technology to web publishers.

Health Update

2023-07-03T12:26:37+00:00

On October 17th of last year, while playing basketball, I suffered a ruptured Achilles tendon.

Unfortunately, an initial misdiagnosis and a lengthy waitlist for necessary medical examinations resulted in me having to postpone surgery until December 9th. The tendon rupture measured approximately 6cm, necessitating the use of tissue from adjacent areas of my feet to construct a completely new tendon.

This led to a period of immobilization lasting 45 days. Although the Christmas break was not particularly enjoyable, I consider myself fortunate to have an incredible wife and children who provided unwavering support, showering me with love and kindness throughout the ordeal. My managers and colleagues at Red Hat were also very supportive so that I could focus on my health during that period.

When my boot was finally removed, I caught sight of my foot for the first time, revealing a 15cm scar that I could proudly boast about if I were on the "Jaws" boat :)

Scar of my Achilles tendon © Jeff Mesnil

By the end of January, I cautiously began walking again, albeit with a noticeable limp. Since then, my rehabilitation has been a gradual journey with its fair share of ups and downs. Yesterday, I was able to run 5 km, but today climbing stairs causes discomfort. I am hopeful that I will achieve a full recovery. As a symbolic "endpoint" to my rehab, I have set a goal to participate in a semi-marathon next year.

Although my competitive basketball days are over, I am still enthusiastic about playing with my kids and continuing to enjoy the sport. I'll play it less and watch it more :) Walking, running, and hiking at my own pace have become my main physical activities, whether I'm by myself or accompanied by friends and family. They provide me energy, focus and a deep appreciation of a functional body.

⇨ DPReview.com to close

2023-03-22T10:09:34+00:00

Over the years, DPReview has been an invaluable help when I was searching for camera gears.

I seldom browse it now as I am mostly using my phone to take pictures but I am still subscribed to their newsfeed.

If I were to look for a replacement for my aging camera, I'm not sure which site would provide the same quality of technical reviews...

⚑

⇨ Writing Greener Java Applications

2023-03-01T09:23:45+00:00

Holly Cummins, a colleague at Red Hat and Java Champion, is making a lot of great content about making software greener.

Her presentation focuses on Quarkus which is a greenfield ¹ Java framework focused on Cloud-native applications while my job is on WildFly and JBoss EAP, Java application servers that predate the Cloud.

Her presentation resonates with me professionally and personally.

Professionally, my focus these days is on making WildFly and EAP run great on the Cloud. Doing so in a sustainable manner is important as it has direct impact on our users' costs and performance.

Personally, and more importantly, it resonates with my vision of my work and my life. All my career has been done around Open Source projects. They fit my idea of a good humane society with core values of Openness, Meritocracy and Accountability. Developping Open Source code is now a given for me and I don't envision other ways to perform my job.

The next frontier is now to develop Sustainable code that reduces our impact on the planet. I deeply believe now that any advancements we are making, whether it's the Cloud, Cryptocurrency, Machine-Learning, can not be at the expense at the planet and our future generations.

It's not simple to see how that translates in my daily tasks but we are past the point where we should include sustainability into our guiding principles and I'm making a deliberate conscious choice to do that now at my own level.

Pun intended ↩

⚑

Storm Over Lake

2017-07-31T15:09:50+00:00

Storm Over Lake © Jeff Mesnil

Fuji X-T2 1/170 ƒ/8 ISO 200 55 mm

Yesterday, we made a 3-hour cruise on the Lac du Bourget and the storm was coming right before we left the boat.

Eclipse MicroProfile Config 1.0 and WildFly implementation

2017-07-27T14:10:47+00:00

Eclipse MicroProfile Config 1.0 has been released.

It is quite a milestone as it is the first specification released by the Eclipse MicroProfile project. It covers a simple need: unify the configuration of Java application from various sources with a simple API:

@Inject
@ConfigProperty(name = "app.timeout", defaultValue = "5000")
long timeout;

The developer no longer needs to check for configuration files, System properties, etc. He or she just specifies the name of the configuration property (and an optional default value). The Eclipse MicroProfile Config specification ensures that several sources will be queried in a consistent order to find the most relevant value for the property.

With Eclipse MicroProfile Config 1.0 API available, I have released wildfly-microprofile-config 1.0.1.

This project contains an implementation of the specification:

<dependency>
 <groupId>org.wildfly</groupId>
 <artifactId>wildfly-microprofile-config</artifactId>
 <version>1.0.1</version>
</dependency>

This implementation passes the MicroProfile Config 1.0 TCK. It can be used by any CDI-aware container/server (i.e. that are able to load CDI extensions).

This project also contains a WildFly extension so that any application deployed in WildFly can use the MicroProfile Config API. The microprofile-config subsystem can be used to configure various config sources such as directory-based for OpenShift/Kubernetes config maps (as described in a previous post) or the properties can be stored in the microprofile-config subsystem itself):

<subsystem xmlns="urn:wildfly:microprofile-config:1.0">
 <config-source name="appConfigSource">
 <property name="app.timeout" value="2500" />
 </config-source>
 <config-source name="configSourceFromDir" dir="/etc/config/numbers-app" />
</subsystem>

Finally, a Fraction is available for WildFly Swarm so that any Swarm application can use the Config API as long as it depends on the appropriate Maven artifact:

<dependency>
 <groupId>org.wildfly.swarm</groupId>
 <artifactId>microprofile-config</artifactId>
 <version>1.0.1</version>
</dependency>

It is planned that this org.wildfly.swarm:microprofile-config Fraction will eventually move to Swarm own Git repository so that it Swarm will be able to autodetect applications using the Config API and load the dependency automatically. But, for the time being, the dependency must be added explicitely.

If you have any issues or enhancements you want to propose for the WildFly MicroProfile Config implementation, do not hesitate to open issues or propose contributions for it.

A Look At Eclipse MicroProfile Healthcheck

2017-07-07T12:44:18+00:00

I recently looked at the Eclipse MicroProfile Healthcheck API to investigate its support in WildFly.
WildFly Swarm is providing the sample implementation so I am very interested to make sure that WildFly and Swarm can both benefit from this specification.

This specification and its API are currently designed and anything written in this post will likely be obsolete when the final version is release. But without further ado...

Eclipse MicroProfile Healthcheck

The Eclipse MicroProfile Healthcheck is a specification to determine the healthiness of an application. It defines a HealthCheckProcedure interface that can be implemented by an application developer. It contains a single method that returns a HealthStatus: either UP or DOWN (plus some optional metadata relevant to the health check). Typically, an application would provide one or more health check procedures to check healthiness of its parts. The overall healthiness of the application is then determined by the aggregation of all the procedures provided by the application. If any procedure is DOWN, the overall outcome is DOWN. Else the application is considered as UP.

The specification has a companion document that specifies an HTTP endpoint and JSON format to check the healthiness of an application.

Using the HTTP endpoint, a container can ask the application whether it is healthy. If it is not healthy, the container can take actions to deal with it. It can decide to stop the application and eventually respin a new instance. The canonical example is Kubernetes that can configure a liveness probe to check this HTTP health URL (OpenShift also exposes this liveness probe).

WildFly Extension prototype

I have written a prototype of a WildFly extension to support health checks for applications deployed in WildFly and some provided directly by WildFly:

https://github.com/jmesnil/wildfly-microprofile-health

The microprofile-health subsystem supports an operation to check the health of the app server:

[standalone at localhost:9990 /] /subsystem=microprofile-health:check
{
 "outcome" => "success",
 "result" => {
 "checks" => [{
 "id" => "heap-memory",
 "result" => "UP",
 "data" => {
 "max" => "477626368",
 "used" => "156216336"
 }
 }],
 "outcome" => "UP"
 }
}

It also exposes an (unauthenticated) HTTP endpoint: http://localhost:8080/health/

$ curl http://localhost:8080/health/
{
 "checks":[
 {
 "id":"heap-memory",
 "result":"UP",
 "data":{
 "max":"477626368",
 "used":"160137128"
 }
 }
 ],
 "outcome":"UP"
}

This HTTP endpoint can be used to configure OpenShift/Kubernetes liveness probe.

Any deployment that defines Health Check Procedures will have them registered to determine the overall healthiness of the process. The prototype has a simple example of a Web app that adds a health check procedure that randomly returns DOWN (which is not very useful ;).

WildFly Health Check Procedures

The Healthcheck specification mainly targets user applications that can apply application logic to determine their healthiness. However I wonder if we could reuse the concepts inside the application server (WildFly in my case). There are "things" that we could check to determine if the server runtime is healthy, e.g.:

The amount of heap memory is close to the max
some deployments have failed
Excessive GC
Running out of disk space
Some threads are deadlocked

These procedures are relevant regardless of the type of applications deployed on the server.

Subsystems inside WildFly could provide Health check procedures that would be queried to check the overall healthiness. We could for example provide a health check that the used heap memory is less that 90% of the max:

HealthCheck.install(context, "heap-memory", () -> {
 MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
 long memUsed = memoryBean.getHeapMemoryUsage().getUsed();
 long memMax = memoryBean.getHeapMemoryUsage().getMax();
 HealthResponse response = HealthResponse.named("heap-memory")
 .withAttribute("used", memUsed)
 .withAttribute("max", memMax);
 // status is is down is used memory is greater than 90% of max memory.
 HealthStatus status = (memUsed < memMax * 0.9) ? response.up() : response.down();
 return status;
});

Summary

To better integrate WildFly with Cloud containers such as OpenShift (or Docker/Kunernetes), it should provide a way to let the container checks the healthiness of WildFly. The Healthcheck specification is a good candidate to provide such feature. It is worth exploring how we could leverage it for user deployments and also for WildFly internals (when that makes sense).

Eclipse MicroProfile Config in OpenShift

2017-06-16T14:51:29+00:00

This is another post that covers some work I have been doing around the Eclipse MicroProfile Config as a part of my job working on WildFly and Swarm (first post is here).

This post is about some updates of the project status and work being done to leverage the Config API in OpenShift (or other Docker/Kubernetes-based environment).

Project update

Since last post, WildFly and Swarm projects agreed to host the initial work I did in their GitHub projects and the Maven coordinates have been changed to reflect this. For the time being, everything is hosted at wildfly-extras/wildfly-microprofile-config.

The Eclipse MicroProfile Config 1.0 API should be released soon. Once it is released, we can then release the 1.0 version of the WildFly implementation and subsystem. The Swarm fraction will be moved to the Swarm own Git repo and will be available with future Swarm releases.

Until the Eclipse MicroProfile Config 1.0 API is released, you still have to build everything from wildfly-extras/wildfly-microprofile-config and uses the Maven coordinates:

<dependency>
 <groupId>org.wildfly.swarm</groupId>
 <artifactId>microprofile-config</artifactId>
 <version>1.0-SNAPSHOT</version>
</dependency>

Directory-based Config Source

We have added a new type of ConfigSource, DirConfigSource, that takes a File as a parameter.

When this ConfigSource is created, it scans the file (if that is a directory) and creates a property for each file in the directory. The key of the property is the name of the file and its value is the content of the file.

For example, if you create a directory named /etc/config/numbers-app and add a file in it named num.size with its content being 5, it can be used to configure the following property:

@Inject
@ConfigProperty(name = "num.size")
int numSize;

There are different ways to use the corresponding DirConfigSource depending on the type of applications.

WildFly Application

If you are deploying your application in WildFly, you can add this config source to the microprofile subsystem:

<subsystem xmlns="urn:wildfly:microprofile-config:1.0">
 ...
 <config-source name="numbers-config-source" dir="/etc/config/numbers-app" />
</subsystem>

Swarm Application

If you are using Swarm, you can add it to the MicroProfileFraction from your main method:

swarm.fraction(new MicroProfileConfigFraction()
 .configSource("numbers-config-source", (cs) -> {
 cs.ordinal(600)
 .dir("/etc/config/numbers-app/");
}));

Plain Java Application

If you are using the WildFly implementation of the Config API outside of WildFly or Swarm, you can add it to a custom-made Config using the Eclipse MicroProfile ConfigBuilder API.

OpenShift/Kubernetes Config Maps

What is the use case for this new type of ConfigSource?

It maps to the concept of OpenShift/Kubernetes Config Maps so that an application that uses the Eclipse MicroProfile Config API can be deployed in a container and used its config maps as a source of its configuration.

I have added an OpenShift example that shows a simple Java application running in a variety of deployment and configuration use cases.

The application uses two properties to configure its behaviour. The application returns a list of random positive integers (the number of generated integers is controlled by the num.sizeproperty and their maximum value by the num.max property):

@Inject
@ConfigProperty(name = "num.size", defaultValue = "3")
int numSize;

@Inject
@ConfigProperty(name = "num.max", defaultValue = "" + Integer.MAX_VALUE)
int numMax;

The application can be run as a standalone Java application configured with System Properties:

$ java -Dnum.size=5 -Dnum.max=10 -jar numbers-app-swarm.jar

It can also be run in Docker configured with environment variables:

$ docker run -e "num.size=2" -e "num.max=10" -p 8080:8080 numbers/numbers-app

It can also be run in OpenShift configured with Config Maps:

apiVersion: v1
kind: ConfigMap
metadata:
 name: numbers-config
 namespace: numbers
 ...
data:
 num.size: '5'
 num.max: '100'

This highlights the benefit of using the Eclipse MicroProfile Config API to configure a Java application: the application code remains simple and use the injected values from the Config API. The implementation then figures out all the sources where the values can come from (System properties, properties files, environment, and container config maps) and inject the appropriate ones.

Eclipse MicroProfile Config (Part I)

2017-04-25T15:00:10+00:00

This is the first post that will cover some work I have been doing around the Eclipse MicroProfile Config as a part of my job working on WildFly and Swarm.

In this post, I will show how to use the Config API from a Java application. The remaining posts will be about developing such new features within the WildFly and Swarm ecosystem.

Eclipse MicroProfile

As stated on its Web site, the mission of the Eclipse MicroProfile is to define:

An open forum to optimize Enterprise Java for a microservices architecture by innovating across multiple implementations and collaborating on common areas of interest with a goal of standardization.

One of the first new API that they are defining is the Config API that provides a common way to retrieve configuration coming from a variety of sources (properties file, system properties, environment variables, database, etc.). The API is very simple and consists mainly of 2 things:

a Config interface can be used to retrieve (possibly optional) values identified by a name from many config sources
a @ConfigProperty annotation to directly inject a configuration value using CDI

The API provides a way to add different config source from where the properties are fetched. By default, they can come from:

the JVM System properties (backed by System.getProperties())
the OS environment (backed by System.getenv())
properties file (stored in META-INF/microprofile-config.properties)

A sampe code to use the Config API looks like this:

@Inject
Config config;

@Inject
@ConfigProperty(name = "BAR", defaultValue = "my BAR property comes from the code")
String bar;

@Inject
@ConfigProperty(name = "BOOL_PROP", defaultValue = "no")
boolean boolProp;

...
Optional<String> foo = config.getOptionalValue("FOO", String.class);
...

There is really not much to the Config API. It is a simple API that hides all the complexity of gathering configuration from various places so that the application can focus on using the values.

One important feature of the API is that you can define the importance of the config sources. If a property is defined in many sources, the value from the config source with the higher importance will be used. This allows to have for example default values in the code or in a properties file (with low importance) that are used when the application is tested locally. When the application is deployed in a container, environment variables defined by the container will have higher importance and be used instead of the default ones.

Instructions

The code above comes from the example that I wrote as a part of my work on the Config API.

To run the example, you need to first install my project and then run the example project:

$ cd example
$ mvn wildfly-swarm:run
...
2017-04-14 10:35:24,416 WARN [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Eclipse MicroProfile Config - UNSTABLE net.jmesnil:microprofile-config-fraction:1.0-SNAPSHOT
...
2017-04-14 10:35:30,676 INFO [org.wildfly.swarm] (main) WFSWARM99999: WildFly Swarm is Ready

It is a simple Web application that will return the value of some variable and fields that are configured using the Config API:

$ curl http://localhost:8080/hello
FOO property = Optional[My FOO property comes from the microprofile-config.properties file]
BAR property = my BAR property comes from the code
BOOL_PROP property = false

We then run the application again with environment variables:

$ BOOL_PROP="yes" FOO="my FOO property comes from the env" BAR="my BAR property comes from the env" mvn wildfly-swarm:run

If we call the application, we see that the environment variables are now used to configure the application:

$ curl http://localhost:8080/hello
FOO property = Optional[my FOO property comes from the env]
BAR property = my BAR property comes from the env
BOOL_PROP property = true

The example is using Swarm and for those familiar with it, only requires to add two fractions to use the Config API:

<dependency>
 <groupId>org.wildfly.swarm</groupId>
 <artifactId>cdi</artifactId>
</dependency>
<dependency>
 <groupId>net.jmesnil</groupId>
 <artifactId>microprofile-config-fraction</artifactId>
 <version>1.0-SNAPSHOT</version>
</dependency>
</dependency>

I have not yet released a version of my implementation as it is not clear yet where it will actually be hosted (and which Maven coordinates will be used).

Conclusion

This first post is a gentle introduction to the Config API. The specification is not final and I have left outside some nice features (such as converters) that I will cover later.

The next post will be about my experience of writing an implementation of this API and the way to make it available to Java EE applications deployed in the WildFly application server or to MicroServices built with WildFly Swarm.

Dockerization of My Web Site

2016-03-09T20:18:59+00:00

This web site is composed of static files generated by Awestruct. I have extended the basic Awestruct project to provide some additional features (link posts, article templates, photo thumbnails, etc.) Unfortunately, some of these extensions uses Rubygems that depends on native libraries or uglier spaghetti dependencies.

I recently wanted to write an article but was unable to generate the web site because some Rubygems where no longer working with native libraries on my Mac. Using bundler to keep the gems relative to this project does not solve the issue of the native libraries that are upgraded either the OS or package system (such as Homebrew).

This was the perfect opportunity to play with Docker to create an image that I could use to generate the web site independantly of my OS.

I create this jmesnil/jmesnil.net image by starting from the vanilla awestruct image created by my colleague, Marek. I tweaked it because he was only installing the Awestruct gem from the Dockerfile while I have a lot of other gems to install for my extensions.

I prefer to keep the gems listed in the Gemfile so that the project can also work outside of Docker so I added the Gemfile in the Dockerfile before calling bundle install.

This web site is hosted on Amazon S3 and use the s3cmd tool to push the generated files to the S3 bucket. The s3cmd configuration is stored on my home directory and I need to pass it to the Docker image so that when the s3cmd is run inside it, it can used by secret credentials. This is done in a docker.sh script that I used to start the Docker image:

# Read the s3cmd private keys from my own s3cmd config...
AWS_ACCESS_KEY_ID=`s3cmd --dump-config | grep access_key | grep -oE '[^ ]+$'`
AWS_SECRET_ACCESS_KEY=`s3cmd --dump-config | grep secret_key | grep -oE '[^ ]+$'`

# ... and pass it to the s3cmd inside Docker using env variables
docker run -it --rm \
 -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
 -e AWS_SECRET_KEY=$AWS_SECRET_ACCESS_KEY \
 -v `pwd`/:/home/jmesnil/jmesnil.net \
 -p 4242:4242 \
 -w /home/jmesnil/jmesnil.net \
 jmesnil/jmesnil.net

Once the Docker image is started by this script, I can then use regular Rake tasks to run a local Web server to write articles (rake dev) or publish to Amazon S3 (rake production).

This is a bit overkill to use a 1.144 GB Docker image to generate a 6MB web site (that only contains text, all the photos are stored in a different S3 bucket) but it is worthwhile as it will no longer be broken every time I upgrade the OS or Brew.

The image is generic enough that it could serve as the basis of any Ruby project using Bundler (as long as required native libs are added to the yum install at the beginning of the Dockerfile).

⇨ Austin Mann's iPhone 6s Camera Review

2015-10-09T16:38:31+00:00

This is a great review of the iPhone 6s camera and summary of its new features.

Marion has bought an iPhone 6s and the camera is a definite improvement when I compare her photos to the ones from my iPhone 6.

Better low light performance and higher resolution are always a plus, but the new feature I prefer is Live Photos. When Apple announced it, I found that superfluous but I changed my mind after ~~looking at~~ watching photos of Raphaël and hearing him twittering...

⚑

Stepping Out From Personal Open Source Projects

2015-09-04T09:58:05+00:00

Our first child, Raphaël, is born last September and we will soon celebrate his first birthday.

This year has been the happiest of my life. However, having a baby means that I have less free time than before, and I want to spend this time with my family or doing personal projects I feel passionate about.

These days I feel more passionate about making photography (mostly of Raphaël and Marion) than writing software (I already have a full time job at Red Hat where I enjoy coding on WildFly).

Before our baby's birth, I could spend evenings and weekends working on personal Open Source projects. After one year, it is time to admit that I do not want to that anymore and act accordingly.

I have decided to flag my personal Open Source projects as not maintained anymore. Some of these projects are still quite used, the three main are all dealing with messaging clients:

stomp.js - a JavaScript library to write web apps/nodes.js client for STOMP protocol
StompKit - an Objective-C client for STOMP protocol
MQTTKit - an Objective-C client for MQTT protocol

I'll modify these projects READMEs to warn that they are no longer maintained (with a link to that post to give some context).

It's not fair to users to spend time using them, reporting bugs and have no warning that their issues will be ignored.

If you are using these projects, I understand that you may be upset that your bugs are not fixed or that the enhancement you request will not be fixed in the original project. Fortunately, these projects are licensed under the Apache License V2. You can fork them (they are hosted on GitHub and use Git as their version control system) and modify them to suit your needs.

I also had some discussion to donate stomp.js to Apache ActiveMQ.

It is a tough decision to not maintain these projects anymore but it is a decision that I have subconsciously made months ago. Now I just have to acknowledge it.

I may revisit this decision when my child is older or when I feel passionate about these project again. Or I may create other Open Source projects, who knows?

The key thing is that by releasing these projects under an Open Source license, I ensured that their use could outlast my initial contributions to it.

Civilian Sponsorship of Raphaël

2015-07-21T14:31:48+00:00

Earlier this month, we celebrated the civilian sponsorship¹ of our son, Raphaël. It was a great sunny day full of laughs and emotion.

Now our son has a godfather and godmother that will be there to take care of him.

Raphaël with his Godmother & Godfather © Jeff Mesnil

Fuji X-E2 1/80 ƒ/5.6 ISO 2500 35 mm

I took this opportunity to create a story on Exposure. I learnt about this service from Scott Kelby and this celebration was a good candidate to try this service.

Baptême Civil de Raphaël on Exposure

You can read the story (in French) here.

Exposure service is really good (I only used their free offer). The image layout options are basic but good enough for such an image-oriented story. There is only one place where I would have preferred to use a grid layout with same size for all images. I also would have liked more typography options to better distinguish the (sparse) text.

Scott Kelby's page provides some great examples of Exposure features.

I don't plan to upgrade to their pro offer but I'll keep playing with it as their offer improves.

A civilian sponsorship is not religious but republican. It is performed at the town hall and is a moral engagement ↩

Marion & Raphaël

2014-11-17T17:22:39+00:00

Over the week-end I experimented with portraits of Marion holding our baby, Raphaël. I wanted to go for an intimate moment between a mother and her baby. The idea was to have a soft portrait of Raphaël and Marion wrapped in shadows.

Regardless of the darkness that surrounds them, their love is a bright light that will not be dimmed.

Marion & Raphaël © Jeff Mesnil

Fuji X-E2 1/180 ƒ/5.6 ISO 400 56 mm

The end result looks like a chiaroscuro painting of La Vierge à l'Enfant.

Technical (boring) corner

Technically, this is a simple photo with a soft light to preserve this private moment.

I used a one-light setup with a Yongnuo YN-560 III flash reflected by a 34" white umbrella. I positioned the flash at their right, at 45° above them. The light is feathered so they only catch the edge of the light (retrospectively, I should have feathered it even more to increase the intimacy).

The background is a 40"x60" reflector with its black surface. Since the light is feathered, almost none reaches the black background and it remains pure black.

I positioned Marion so that Raphaël's face could catch most of the light and only her right side would be lit... plus a tiny bit of reflection on her left cheek thanks to the almost bald skull of our baby ;)

I used my Fuji X-E2 with its awesome 56mm ƒ/1.2 lens that I opened at ƒ/5.6 to have enough field of depth for both of them.

Raphaë was intrigued by the flash tests and I just had to make a few pictures to capture this one.

Simple stuff, and a lovely moment that all three of us shared.

⇨ O'Reilly Webcast: Using Messaging Protocols to Build Mobile and Web Applications

2014-11-17T09:57:38+00:00

Last week, I made a webcast for O'Reilly about using messaging protocols to build mobile and web applications to promote my book, Mobile & Web Messaging.

This webcast can be watched for free and you can also read the slides I used for the presentation. They contain most of the information I talked about during this 1-hour long webcast.

Thanks to the people at O'Reilly (and especially Yasmina Greco) to setup this presentation, it was a great and fun experience.

⚑

Raphaël Mesnil

2014-10-16T11:53:10+00:00

Our first child, Raphaël Mesnil, is born on September, 28^th at 52cm and 3.230kg.

Marion and the baby are fine and we enjoy every moment with him.

Raphaël Mesnil © Jeff Mesnil

Fuji X-E2 1/180 ƒ/2.8 ISO 400 56 mm

I am now a father which will make many photographs of his baby :)

I am already making good use of the Fujinon 56mm ƒ/1.2 lens that I bought a few months ago when we learnt that Marion was pregnant.

I am not accustomed to baby photography (or portraits in general) but this will change now that Raphaël is here. We were back at home for one day and I was already setting up a studio to shoot his portrait. Next step is to make photographs of Marion and the baby together.

So much fun, so much love.

Rainy Venezia

2014-09-09T16:17:13+00:00

We went to Venezia last May and had a rainy day during our trip. We spent almost the whole afternoon at a coffee shop and I was shooting the soaked people rushing to cross the street.

This old man stood out with his red umbrella and his leisurely pace.

Rainy Venezia © Jeff Mesnil

Fuji X-E2 1/100 ƒ/9 ISO 1000 55 mm

How To Shoot a Bottle of Beer — St. Stefanus Blonde

2014-09-05T11:21:42+00:00

For the past 18 months, I have photographed bottles of beer for my friends of Une Petite Mousse. On their web site, you subscribe to receive every month a box of six bottle of beers. The selection changes every month and contains a mix of well-known beers and others from micro-breweries. It is a great way to discover and taste new beers that you can not find in a store near you.

They need pictures of the bottles for their online catalogue and the paper guide that comes in the boxes.

Making photographs of a bottle of beer is suprisingly challenging. I want to give on overview of the color of the beer inside the bottle (which are often made of a dark glass) while highlighting the label on the front of the bottle. In order to build the catalogue, I want to have an uniform style for all pictures with a pure white background and a square format (to keep the respective size of the bottles).

In this post, I'll explain the process I have used for the latest box (available mid-september). For september 2014, one of the beers is the St. Stefanus Blonde, brewed in Belgium.

St. Stefanus Blonde © St Stefanus

The picture above is from their web site (I really like how the strips of white emphasize the roundness of the small bottle).

Gear

To photograph this bottle, I used the following material:

Fuji X-E2 camera
Fuji 56mm ƒ/1.2 lens (which is my lens with the longest focal length)
2 Flash Speedlights (Yongnuo YN560-III and Nikon SB-700) in manual mode. I plugged the Nikon SB-700 on a Yongnuo RF-603/N3 to trigger it remotely
a Yongnuo YN560-TX plugged on the camera hotshoe to control remotely the speedlights
my trusty Giotto's Vitruvian tripod to stabilize the camera
many white foam boards (for the background and below the bottle)
many black foam boards (used as gobos to block the light)

Before explaining my process, I heartily recommend to read Light Science and Magic: An Introduction to Photographic Lighting. This book is an invaluable help to understand how light plays with shapes and textures.

Setup

The first step is to place the bottle and the various white and black foam boards that will give the bottle a distinctive shape. In order to highlight the color of the beer inside the bottle, I will light white foam boards in the background. The light will bounce on the boards and go through the bottle before reaching the camera. The background will be overexposed to be pure white.

I also want to have well-defined edges on the bottle. I place two black foam boards on each side of the white background. These black boards will appear on the edges of the bottle and increase the contrast and sharpness of its shape. Without these black boards, the light coming from the white background would splill on the edges and make them too soft.

I put the bottle on a white foam board (with a plexiglass to have a small reflection at the bottom). Finally, I put other black foam boards on each side of the bottle and on top of it to prevent any leaking light to reach it.

I then place the camera at the right distance of the bottle to have it fill the image height. The image will be cropped to square in post-processing. I activate the X-E2 guides on its screen to have a good overview of the final size.

Setup © Jeff Mesnil

Once the camera is correctly placed, I fine tune the placement of the black boards on each side of the white background. They must be placed so that the edges of the bottle are dark but not too close so that they fill the inside of the bottle.

Placement of the black foam boards © Jeff Mesnil

I put the bottle on top of a small box to be able to place the flashes below it (so that they do not appear on the photos) and angle them appropriately to light the scene.

I want to control the lighting and block any ambient light (the garage where I took the photos has lights coming from windows that can not be easily blocked). I configure my camera to 1/180 (the highest sync speed for the X-E2) and ISO 400. The lens is stopped down to ƒ/8 to have enough depth of field.

With these settings, the image is so dark that I know I will not be bothered by any ambient light (the photo is cropped but no other postprocessing has been applied).

Ambient Light Only © Jeff Mesnil

Next step is to place the two flashes and provide the lighting.

Back (Main) Light

The main light is provided by the flash behind the bottle. It is directed towards the white background and will light the bottle after bouncing on the background. I use the Yongnuo YN560-III zoomed at 24 mm with a diffuser to spread the light on the white background.

When I take the picture, I can see that the beer inside the bottle is well lit and the background is overexposed to pure white. Thanks to the black foam boards, the edges of the bottle are dark and sharp enough (the photo below is cropped but no other postprocessing has been applied).

Back (Main) Light © Jeff Mesnil

Fuji X-E2 1/180 ƒ/8 ISO 400 56 mm

Front (Fill) Light

The liquid inside the bottle is lit but there is no light reaching the label on the front of the bottle.

I then to use the second flash (Nikon SB-700) to light only the label. The placement of the flash is tricky because it can easily create highlights on the glass if it is not properly directed. I place it below the bottle with an angle of 45° or so. It is fully zoomed at 135 mm to focus its light on the label. With this angle and zoom, the flash will lit the paper label but most of the light reaching glass will not be captured by the camera.

The photo below shows the bottle lit by the front flash only (the photo below is cropped but no other postprocessing has been applied).

Font (Fill) Light © Jeff Mesnil

Fuji X-E2 1/180 ƒ/8 ISO 400 56 mm

We can see there are two highlights on the bottom of the bottle and near its neck. They are small enough that I will be able to remove it in post processing.

Final Picture

Once the two speedlights are setup, I tweak their power to have a correct ratio between the back and front lights. At then, I use the following ratio:

Back (main) light 1/16 +0.3EV
Front (fill) light 1/64 -0.3EV

When I take the picture with both the back and front lights, I capture the final (cropped but unprocessed) picture below.

Fuji X-E2 1/180 ƒ/8 ISO 400 56 mm

Most of the work is now done and I just need a few touches of post-processing to finalize the image.

Post-Processing

I use Lightroom for the image post-processing.

Once the image is imported, I correct the lens distorsions and crop the image to a square format.

I slightly modify its global setting in the Basic module:

I fix its white balance (using a photo of the scene with a grey card)
I punch its Tone
- +0.75 Exposure
- +41 Contrast
- +26 White
- -63 Black
I increase its Presence
- +16 Clarity
- +26 Vibrance
- -4 Saturation
I also increase the sharpness in the Details module (+52 Sharpening).

The numbers are meaningless. They are different for each bottle, depending mainly on the color and texture of the liquid and glass. The goal with any of these settings is to have a pure white background and a bottle that is well exposed and contrasted.

I use the Spot Removal tool to remove the highlights caused by the front flash at the bottom of the bottle and near its neck.

Last step is to use a few Adjustment Brushes to finalize the images:

darken the bottle reflection on the plexiglass
lighten the bottom corners of the label (that's a mistake I did not catch when capturing the image)
sharpen and increase contrast of the label (to have the text standout)

I finally export it in JPEG and hand it over to Barbara, the graphist designer of Une Petite Mousse, that uses it for the paper guide and the web site.

Fuji X-E2 1/180 ƒ/8 ISO 400 56 mm

Since March 2013, I have photographed more than one hundred different beers¹ and each one is a different challenge. The shape of the bottle changes, the color of the liquid and the glass change too. Some have dark labels, others have golden labels. Some do not have labels at all and the text is put directly on the glass.

I am always tweaking and refining the process to capture all these subtle differences and I am sure that I will continue to do so for as long as I take pictures and enjoy it.

Santé! 🍻

and I have tasted all of them! :) ↩

Macarons au Chocolat

2014-04-21T18:35:56+00:00

Fuji X-E2 1/180 ƒ/8 ISO 200 56 mm

I am experimenting how to light a dark background and had no other subjects on hands than the macarons we just cooked :)

Architecture

2014-03-12T20:37:00+00:00

Fuji X-E2 1/480 ƒ/9 ISO 200 33 mm

Les Trois Pucelles

2014-02-24T11:57:00+00:00

Les 3 Pucelles, the Three Maiden, are three rocks high above Grenoble in the Vercors. It was an important location used by the Resistance during the 2^nd World War.

1/80 ƒ/8 ISO 250 25 mm

This 90-metre springboard was used for the ski jumping competion during the 1968 Winter Olympic Games at Grenoble. It has been closed since the 80s and can no longer be used.

210 ƒ/8 ISO 400 18 mm

La Fourchette d'André Kertész

2014-01-27T10:01:36+00:00

Yesterday, I was reading a book about André Kertész, one of my favourite photographers. I tried to reproduce one of his most famous photographs, La Fourchette, that he made in 1928.

1/180 ƒ/5.6 ISO 200 37 mm

The shape of my fork and plates are different from the original ones but the lighting is pretty similar. I used a single strobe to get a unidirectional hard light and tried several positions to get the shadows of the plate, the fork and the teeth close to the original:

The printing I have is more subtle and nuanced that this picture from Wikimedia that has too much contrast.

2013 in Photos

2014-01-02T12:32:41+00:00

2013 has ended and it's the opportunity to look back at all the photos I made during the year.

They are mostly landscapes from our trips (Tuscany, Brittany, Barcelona), food and a plethora of portraits of Marion :)

I expect more of the same in 2014 and continue to improve my craft and skills.

Rainy Sunday Cookies

2013-09-29T14:25:44+00:00

There is nothing better for a rainy sunday than cooking some cookies with my girlfriend and make pictures of them to play with my flash and reflectors.

1/80 ƒ/5.6 ISO 400 42 mm

Let's eat them now!

stomp.js for node.js apps

2013-09-25T17:50:49+00:00

stomp.js is a simple JavaScript library to send and receive STOMP messages from a Web browser using Web Sockets.

Today, I have released its version 2.3.0 that adds support for node.js. This makes it possible to send and receive STOMP message from any node.js app by connecting to a STOMP broker on its TCP port (usually 61613) or on its Web Socket.

I have registered a npm package stompjs that can be installed by typing:

npm install stompjs

and in the code, requiring the module:

var Stomp = require('stompjs');

To connect to a STOMP broker over a TCP socket, use the Stomp.overTCP(host, port) method:

var client = Stomp.overTCP('localhost', 61613);

To connect to a STOMP broker over a Web Socket, use instead the Stomp.overWS(url) method:

var client = Stomp.overWS('ws://localhost:61614/stomp');

Apart from this initialization, the STOMP API remains the same whether it is running in a Web browser or in node.js application.

A simple node.js app that sends and receives a STOMP message can be coded in a few lines:

var Stomp = require('stompjs');

// Use raw TCP sockets
var client = Stomp.overTCP('localhost', 61613);
// uncomment to print out the STOMP frames
// client.debug = console.log;

client.connect('user', 'password', function(frame) {
 console.log('connected to Stomp');

 client.subscribe('/queue/myqueue', function(message) {
 console.log("received message " + message.body);

 // once we get a message, the client disconnects
 client.disconnect();
 });
 
 console.log ('sending a message');
 client.send('/queue/myqueue', {}, 'Hello, node.js!');
});

In this example, the client connect to the STOMP broker on its TCP socket by calling Stomp.overTCP(host, port):

var client = Stomp.overTCP('localhost', 61613);

To connect on its Web Socket, you only need to change the creation of the client by calling instead Stomp.overWS(url):

var client = Stomp.overWS('ws://localhost:61614');

This means that if your code uses stomp.js, you can run the same code in the Web browser or in node.js That may prove handy for testing...

Why another STOMP client for node.js when there are already a dozen?

I believe the code of stomp.js is already the best of them.

It is distributed by the major STOMP brokers (ActiveMQ, Apollo, HornetQ, and RabbitMQ), widely used, thoroughly tested and documented.

The STOMP protocol implementation is the same whether the client is running in a Web browser or in node.js. The only differences are the timers and the socket implementations (native Web Socket for Web browser, net.Socket for node.js). The socket implementation can still be customized and many users run it over SockJS

There are likely some corner cases to iron out but the main features (including heart-beating) should work as expected.

Note that the node.js support is done outside the stomp.js file. If you only need to use STOMP from the Web browser, this changes nothing: you only need that file (or its minified version).

Enjoy!

Guitarist at Park Güell, Barcelona

2013-09-16T14:07:35+00:00

1/100 ƒ/5 ISO 800 40 mm

⇨ Teahupo'o: Inside the Monster

2013-09-16T09:31:43+00:00

Breathtaking documentary about Teahupo'o surf spot:

⚑

Writing a Book for O'Reilly about Mobile & Web Messaging

2013-09-09T13:39:35+00:00

The title says it all: I've agreed with O'Reilly Media to write a book about Mobile and Web Messaging.

Almost all my career has been spent developing messaging platforms or clients using messaging. The last few years, I have focused on messaging for Mobile and Web platforms.

I added STOMP support to HornetQ to be able to send and receive messages from iOS and Android apps.
I wrote stomp.js to send and receive messages from HTML5 Web Browsers¹. This small library is now used by the main Open Source messaging brokers (ActiveMQ, Apollo, RabbitMQ in addition to HornetQ).

This book is the result of all this work and will help mobile and Web developers leverage messaging protocols in their applications.

I plan to introduce messaging protocols and write about STOMP (and most likely MQTT too) in details. The book will come with examples for mobile platforms and Web browsers.

I have setup a web site at mobile-web-messaging.net to promote the book and will tweet about it at @mobilewebmsg.

The target release for the book is June 2014.

For a long time, I wanted to write a technical book and it is a chance to do it about an interesting subject and be published by the best editor for programming books. O'Reilly agreed to publish the book under an Open Source license and the source and examples will be hosted on GitHub (when I have some material to show).

This opportunity is only possible because my employer, Red Hat, allows me to spend some of my work time on this book. Red Hat is an awesome company to work for and we are hiring!

I am incredibly excited about this book and look forward to sharing some sample chapters. I just need to start writing them now! :)

That's why I just released a new version of stomp.js. I plan to write a chapter about it and found some shortcomings that I wanted to fix. ↩

stomp.js 2.1.0 is Released

2013-09-03T17:29:21+00:00

I have released a new version of Stomp over WebSockets.

During my summer holidays, I have simplified its API to make it more object-oriented instead of a simple translation of the protocol frames. The new API is backwards compatible except for the susbcription change.

The documentation has been updated to reflect the new API.

I also created a 2.1.0 release on GitHub to provide a well-known location to download stomp.js (and its minified version).

Connection

The connect() method accepts different number of arguments to provide a simple API to use in most cases:

client.connect(login, passcode, connectCallback);
client.connect(login, passcode, connectCallback, errorCallback);
client.connect(login, passcode, connectCallback, errorCallback, host);

where login, passcode are strings and connectCallback and errorCallback are functions (some brokers also require to pass a host String).

The connect() method also accepts two other variants if you need to pass additional headers:

client.connect(headers, connectCallback);
client.connect(headers, connectCallback, errorCallback);

where header is a map and connectCallback and errorCallback are functions.

Please note that if you use these forms, you must add the login, passcode (and eventually host) headers yourself:

var headers = {
 login: 'mylogin',
 passcode: 'mypasscode',
 // additional header
 'client-id': 'my-client-id'
};
client.connect(headers, connectCallback);

Acknowledgement

The message objects passed to the subscribe callback now have ack() and nack() methods to directly acknowledge (or not) the message.

var sub = client.subscribe("/queue/test",
 function(message) {
 // do something with the message
 ...
 // and acknowledge it
 message.ack();
 },
 {ack: 'client'}
);

Unsubscription

Instead of returning an id from client.subscribe(), subscribe() returns an object with an id property corresponding to the subscription ID and an unsubscribe() method.

var subscription = client.subscribe(...);
...
subscription.unsubscribe();

Transaction

The begin() method returns a JavaScript object with commit() and abort() methods to complete the transaction.

var tx = client.begin();
message.ack({ transaction: tx.id, receipt: 'my-receipt' });
...
tx.commit(); // or tx.abort();

A transaction ID is automatically generated when calling 'begin() and is available in the returned object's id property.

Miscellaneous changes and fixes

default onreceive method

When a subscription is automatically created on the broker-side, the received messages are discarded by the Stomp.client that find no matching callback for the subscription headers. To workaround that, the client can set a default onreceive callback that will be called if no matching subscription is found.

This is required to support RabbitMQ temporary queue destinations.
By default, debug messages are now written in window.console.
STOMP can now be used from a WebWorker (an example shows how to use it).
STOMP frame fragmentation

If the STOMP frames are big to send on a single WebSocket frame, some web server may have trouble process them. It is now possible to split a STOMP frame on multiple Web Socket frames by configuring the client.maxWebSocketFrameSize (in bytes). If the STOMP frame is bigger than this size, it will be send over multiple Web Socket frames (default is 16KiB).
use the 1st value for repeated headers

Stomp.js was keeping the last value of repeated headers. This has been fixed according to the specification to take the 1st value of repeated headers.
fix generation of timestamp on IE8

Sunset At Saint-Malo

2013-08-08T13:45:19+00:00

1/250 ƒ/8 ISO 100 58 mm

Velours de Mangue

2013-08-05T08:41:09+00:00

We bought a siphon for cooking some time ago and are having fun with it to prepare desserts and starters (we made a mousse de foie gras that was awesome). Yesterday, we prepared a velours de mangue (velvet of mango).

1/60 ƒ/2.8 ISO 100 35 mm

JMS 2.0: Shared Subscription

2013-06-27T17:14:26+00:00

JMS 2.0 has been released a few weeks ago. We are working hard to support it in HornetQ and WildFly and I plan to write a few articles about it.

The main features are described on Oracle Web site in What's New in JMS 2.0, Part One: Ease of Use and Part Two: New Messaging Features.

One of the most important new features is Shared Subscription.

Let's assume you are using a topic to send messages. There are several components subscribed to this topic that are processing the messages in different fashion (for example to process jobs A and B).

When a message M is sent to the topic, all consumers subscribed to the topic receive it:

 M +--------------+
 ---> | consumer CA1 | < a consumer for the job A >
 +----------+ M +-------+ / +--------------+
 | producer | ---> | topic | 
 +----------+ +-------+ \ M +--------------+
 ---> | consumer CB1 | < a consumer for the job B >
 +--------------+

The consumer CB1 is subscribed to the topic. Every time, it receives a message, it processes the job B.

Unfortunately, this job is time-consuming and we would like to scale it out by having several consumers for the job B running on different machines.

We can not have several consumers on the topic for this job, otherwise they would all receive copies of the same message and process it several times. What we need is a set of consumers that receives a single message from the topic amongst them.

If the component is running inside a Java EE application server, you can use a Message-Drive Bean for that. If the component is a Java SE application, you are out of luck.

Before JMS 2.0, each messaging brokers has different ways to provide this feature.

With HornetQ, the workaround is to use a divert:

Diverts allow you to transparently divert messages routed to one address to some other address, without making any changes to any client application logic.

We use a divert to route the messages sent to the topic to another queue (let's called it Queue_B since it's for the processing job B). Everytime a message is sent to the topic, a copy is also routed to the queue. Our divert is non-exclusive since we want it to still be received by the topic consumers.

We can then create as many consumers we want for Queue_B. Since this destination is a queue, only one of them will receive a message that was initially sent to the topic:

 M +--------------+
 ---> | consumer CA1 |
 +----------+ M +-------+ / +--------------+
 | producer | ---> | topic | 
 +----------+ +-------+ 
 \ +--------------+
  \ M ---> | consumer CB1 |
 divert \ / +--------------+
 \ +---------+ / +--------------+ 
 | Queue_B | -- ---> | consumer CB2 |
 +---------+ \ +--------------+
 \ M +--------------+
 ---> | consumer CB3 |
 +--------------+

Among CB1, CB2 and CB3, only CB3 received the message sent to the topic.

There are still many shortcomings of using diverts (or similar features) to share consumers of a topic.

for each set of shared consumers, a system administrator must create and administrate on the server one more divert and one more queue.
the shared consumers are no longer consuming from the original topic but from a specific queue. That makes the messaging topology more complex to setup and configure in the client applications.
the management of the messaging system becomes also more complex: there is no way to know how many subscribers are "really" listening to the topic, this information is lost when messages are routed by the divert.

Enter JMS 2.0 and its "shared subscription".

A non-durable shared subscription is used by a client which needs to be able to share the work of receiving messages from a topic subscription amongst multiple consumers. A non-durable shared subscription may therefore have more than one consumer. Each message from the subscription will be delivered to only one of the consumers on that subscription.

The basic idea behing sharing a subscription is to have a set of consumers (identified by a shared subscription name) receiving exclusively a message from a topic.

That solves all the issues we originally had in a standard fashion. We can now create many shared consumers with the shared subscription name << sub B >> to have them process messages for the job B and scale out nicely:

 M +--------------+
 ----------------> | consumer CA1 |
 / +--------------+
 / +--------------+
 +----------+ M +-------+ / ---> | consumer CB1 |
 | producer | ---> | topic | / +--------------+
 +----------+ +-------+ \ / M +--------------+
 << sub B >> -- ---> | consumer CB2 |
 \ +--------------+
 \ +--------------+
 ---> | consumer CB3 |
 +--------------+

Among the shared consumers CB1, CB2 and CB3, only CB2 received the message sent to the topic.

all our consumers are directly consuming from the topic
there are no additional resources to configure or administrate on the server

The JMS 2.0 API adds new methods to create shared consumer:

 JMSContext.createSharedConsumer(Topic topic, String sharedSubscriptionName)
 JMSContext.createSharedConsumer(Topic topic, String sharedSubscriptionName, String messageSelector)

It is also possible to create shared durable consumers:

 JMSContext.createSharedDurableConsumer(Topic topic, String name)
 JMSContext.createSharedDurableConsumer(Topic topic, String name, String messageSelector)

Sharability and durability of subscriptions are two orthogonal notions and all the combination are possible:

a unshared non-durable subscription can only have one consumer that will not receive messages sent while its consumer was offline
a unshared durable subscription can only have one consumer that will receive the messages sent while its consumer was offline
a shared non-durable subscription can have many consumers that will not receive messages sent while all consumers were offline.
a shared durable subscription can have many consumers that will not receive the messages sent while all consumers were offline.

JMS 2.0 is an incremental update to JMS that should simplify any Java application using messages. Shared subscription is one of this interesting new features.

⇨ Tim Duncan — The Big Fundamental

2013-06-03T17:53:14+00:00

Insightful portrait of Tim Duncan on the cusp of his 5th NBA finals (he won his first fours):

Sometimes people will mention the swimming when trying to pinpoint the origin of Duncan’s remarkable discipline and relentless consistency. Duncan swam until he was 14 and seemed on a path toward the Olympics like his sister, Tricia. That was when Hurricane Hugo roared through the Island and wrecked the swimming pool. More, that was the year his mother, Ione, died of cancer. She had been his greatest fan, the loudest cheers at the pool, the voice inside his head. He would talk about the little nursery rhyme that she would repeat to him over and over and over …

Good, better, best
Never let it rest
Until your good is better
And your better is your best

You can’t help but think that if you cut Tim Duncan open, those words would be etched on his heart.

There has never been a basket-ball player so consistent for the whole span of his career (stats per 36 minutes):

1st year - 21 year old, 19.4 points, 11 rebounds, 2.5 assists, 2.4 blocks, 57.7 true shooting %
7th year - 27 year old, 21.9 points, 12.2 rebounds, 3.0 assists, 2.6 blocks, 53.4 true shooting %
17th year - 36 year old, 21.3 points, 11.9 rebounds, 3.2 assists, 3.2, blocks, 55.4 true shooting %

I am rooting for the spurs for these finals! #GoSpursGo

(via kottke)

⚑

Uriage Cabriolet Classic

2013-05-27T14:29:10+00:00

This sunday was held the 2013 edition of Uriage Cabriolet Classic, a large gathering of classic (and more recent) cars.

I am not a connaisseur of cars but I can recognize a beautiful one when I see it. I really enjoy the attention to details of these cars and the love and care of their owners (the engines were all shining!).

1/1250 ƒ/5 ISO 400 46 mm

1/2000 ƒ/5.3 ISO 200 58 mm

1/250 ƒ/5.6 ISO 200 28 mm

This gathering is an opportunity to appreciate all the shapes and colours of cars. Even the most modest cars look fantastic with out of the ordinary colours.

1/400 ƒ/8 ISO 400 78 mm

1/60 ƒ/22 ISO 400 85 mm

We were lucky having a beautiful weather for the gathering and enjoyed the familial atmosphere.

Tuscany Countryside

2013-05-13T17:53:53+00:00

1/100 ƒ/8 ISO 400 38 mm

My girlfriend and I spent one week in Tuscany. We loved every moment of it.

⇨ David duChemin Reviews the Fuji XE-1

2013-05-13T16:15:19+00:00

Spoiler: he loves the camera and, unsurprisingly, makes beautiful pictures with it.

I bought his book, The Print and the Process, this week-end. It is a beautifully crafted book composed of 4 sections, Venic, Iceland, Kenya, and Antarctica providing a variety of scenes (it's mostly landscapes and portraits though, it's a David duChemin's book after all :) Each section is composed of a set of 20-30 images without any text that helps appreciate the flow of pictures without any interruption. At the end of each section, there is a text for each images where the author describes what his intent or feeling was when he took the picture.

The book is bound along the short edge in landscape mode. This design makes the beautiful landscape images really stand out.

Beautiful book, gorgeous photos and instructive reading. Heartily recommended.

⚑

⇨ WildFly Application Server

2013-04-22T11:28:58+00:00

After a long wait, it was announced at JUDcon Brazil that the JBoss Application Server has been renamed and is now WildFly ¹.

Onwards with WildFly!

With a upper case F, no relation with the Wildfly transformer ↩

⚑

⇨ Yahoo! Weather App

2013-04-19T10:32:16+00:00

The new weather app from Yahoo! looks gorgeous and is a pleasure to use with an intuitive navigation.

Yahoo! Weather App

The photos are geolocated and taken from Flickr photo pool. That's a great way to leverage Flickr.

With the updated Flickr app and this new weather app, Marissa Meyer is on the right track to hold her promise to make Flick awesome again.

⚑