encoding in jdk openj9 docker images

Recently I was looking into encoding problems and I was really surprised to find this:

docker run –rm adoptopenjdk/openjdk11-openj9:jre- java -XshowSettings 2>&1 | grep encoding

file.encoding = ANSI_X3.4-1968
file.encoding.pkg = sun.io
ibm.system.encoding = ANSI_X3.4-1968
os.encoding = ANSI_X3.4-1968
sun.io.unicode.encoding = UnicodeLittle
sun.jnu.encoding = ANSI_X3.4-1968

Even adding environment variables like LC_ALL or LANG did not help ūüôĀ

docker run –rm -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 adoptopenjdk/openjdk11-openj9:jre- java -XshowSettings 2>&1 | grep encoding

But the issue was fixed with a more recent version of the image:

docker run –rm adoptopenjdk/openjdk11-openj9:jre-11.0.6_10_openj9-0.18.1-alpine java -XshowSettings 2>&1 | grep encoding

file.encoding = UTF-8
file.encoding.pkg = sun.io
ibm.system.encoding = UTF-8
os.encoding = UTF-8
sun.io.unicode.encoding = UnicodeLittle
sun.jnu.encoding = UTF-8

Be aware of this insides of the images you use!

Happy coding

fault tolerance for jax-ws with resilience4j

In a recent project, we still have to use SOAP webservices and I wanted to apply some resilience pattern such as retry to my project.
Also a collegue just presented a java library called resilience4j so I wanted to use that one.

Of course, there are a lot of other possibilites like using other libraries (like Hystrix) or applying the sidecar pattern outside of my application in a cluster.

As you can see in the documentation, resilience4j is build for functional programming style and it supports some functional interfaces
which can be decorated to apply the retry mechanism to the function invocation. In the examples, you can always find a simple setup to pass the supplier and decorate it only for the particular method.

In my use case, I do not want to write the decoration code for each and every method (or function). I have a third party WSDL, generated the webservice interface and port via wsimport and now I want to generically apply the retry mechanism to the webservice client. But my solution is not very complicated, it is using a reflection proxy and invocation handler to direcly decorate and execute the method via the Retry classes.

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Proxy;
import io.github.resilience4j.retry.Retry;
public final class WebserviceFactory{
static <T> T decorateWithRetryer(final T service, Retry retry) {
InvocationHandler invocationHandler = (proxy, method, args) -> retry.executeCheckedSupplier(() -> method.invoke(service, args));
return (T) Proxy.newProxyInstance(service.getClass().getClassLoader(),
service.getClass().getInterfaces(), invocationHandler);

This way I am able to decorate my whole service interface.

One note I can make regarding the exception handling: In case of an exception, an InvocationTargetException is thrown. If you want to have the target one, you have to unwrap it.

The source code of my example is available at https://github.com/mwiede/jaxws-resilience4j.

Connecting Spring and Hibernate though BeanContainer

Recently I was working on a Spring Boot application and I wanted to put together Spring and Hibernate with JPA EntityListeners.

As you may know, any JPA EntityListener class is not in the scope of Spring or any Ioc, as long as you bring them together. If you have the requirement to do this, there are a lot of examples in blogs, describing workarounds like

http://esus.com/hibernate-4-integrator-pattern-springs-di/ or https://guylabs.ch/2014/02/22/autowiring-pring-beans-in-hibernate-jpa-entity-listeners which in the end are doing autowiring programmatically (i.e. by using org.springframework.web.context.support.SpringBeanAutowiringSupport).

In the recent versions of Spring and Hibernate, this work became obsolete (as I described also on https://stackoverflow.com/questions/47941717/spring-dependency-injection-into-jpa-entity-listener/55452014#55452014).

Since Hibernate 5.3 there is a so called org.hibernate.resource.beans.container.spi.BeanContainer, which makes Hibernate aware of Spring or CDI beans. Later, org.springframework.orm.hibernate5.SpringBeanContainer was added with Spring 5.1, so you do not need to handle autowiring any more. See details of this feature in https://github.com/spring-projects/spring-framework/issues/20852

As an example of a JPA EntityListener, you can add the @Component annotation and wire any Spring bean to it.


public class MyEntityListener{

  private MySpringBean bean;


  public MyEntityListener(MySpringBean bean){

    this.bean = bean;



  public void prePersist(final Object entity) {

¬†¬†¬† …



To make Hibernate aware of this component bean, there are two scenarios:

1) You are using Spring Boot: Then you do not have to do anything, because the configuration of LocalContainerEntityManagerFactoryBean is done automatically in org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaConfiguration.

2) Outside of Spring Boot, you have to register SpringBeanContainer to Hibernate like this:




    public LocalContainerEntityManagerFactoryBean entityManagerFactory(ConfigurableListableBeanFactory beanFactory) {

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† LocalContainerEntityManagerFactoryBean emfb = …

            emfb.getJpaPropertyMap().put(AvailableSettings.BEAN_CONTAINER, new SpringBeanContainer(beanFactory));

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† …

            return emfb;


Memory Footprints of hello-world microservices

I was curious reading about openj9 as a JVM being high performance and using a low memory footprint. I was working in a project, where the environment of software systems consisted of around 30 Java Applications, a few running on tomcat, a few on weblogic and the most running on dropwizard microservice framework. The desirable goal for every developer was to start the complete platform on his local notebook and therefor a virtalbox image was build using vagrant. As there were so many applications, each microservice itself consumed around 250MB of RAM and with the number of services growing we already hit 24GB image size of the virtualbox image. I found the blogpost https://codeburst.io/microservices-in-java-never-a7f3a2540dbb which describes the same issue and that if you those java microsevices in a cloud infrastructure, you would even have to pay even more money only because of the memory footprint.

Luckily there was somebody doing a comparsion of openj9 vs hotspot VM in his two blogpots https://royvanrijn.com/blog/2018/05/openj9-jvm-shootout/ and https://royvanrijn.com/blog/2018/05/openj9-hotsport-specjvm2008/ already. He was is showing some benchmarks and results.

My own simple comparison

I tested it on my own (just for curiosity) and came to the same result. In terms of memory consumption, there is a potential improvement with openj9 as JVM alternative.

I picked three helloworld examples using maven archetypes from dropwizard, helidon and Spring Boot.

First I packacked them into docker images using adoptopenjdk/openjdk8-openj9:alpine-slim on the one hand and adoptopenjdk/openjdk8:alpine-slim on the other hand.

Then I compared memory consumption using application metrics and dockers stats and could have a rough idea of the differences. Here is the result of the dropwizard app:

openj9 without any parameters to the jvm:

  • jvm.memory.heap.used = 10563328 B, jvm.memory.total.used = 37838048
  • docker container = 48.55MiB

hotspot without any parameters to the jvm:

  • jvm.memory.heap.used = 28511520 B, jvm.memory.total.used = 61381328
  • docker container = 118.3MiB


Whether you have the goal of running your complete software on your developer laptop or you want to save money running your services in a public cloud, openj9 provides a possibility to reduce the memory footprint of your java application by around 50%.

As it was mentioned in the other blog posts, there are also a few downsides with this, but if you test everything and the requirements (in terms of computation performance) are met, you should give it a try.

timezones known by java are not known by Oracle Database

Recently we had an issue with database connection, which led to the following eror:

ORA-00604: error occurred at recursive SQL level 1 ORA-01882: timezone region not found

Finally we found out, that the timezone coming from the operating system was known to Java JDK, but not to the Oracle Database we were using.

Oracle Database 12c Enterprise Edition Release – 64bit Production
PL/SQL Release – Production
CORE Production
TNS for Linux: Version – Production
NLSRTL Version – Production

These are the timezones which will lead to the issue:



How to solve it:

  • choose a timezone id known by Oracle database
  • set environment variable i.e. export TZ=UTC or
  • set java property -Duser.timezone=UTC


Response validation when using Feign as http client wrapper

If you have the requirement of validating the response of a rest interface, a good opportunity in Java is to use the bean validation api and its annotations. On top, if you use OpenFeign wrapper to define the client in your application, you can now assign those validation annotations directly to your interface.

If you have already seen in my previous blogpost about Feign Outbound metrics, I am trying to extend feign with some decorator classes to add missing functionality. metrics-feign is a library, which can be used to report outbound-metrics out of any invocation to the feign wrapper.

Now I created another library, which makes it possible to validate the response using bean validation api (JSR349). Its called feign-validation and you can find it at github or maven central.

The only thing you have to do after setting it up is to add annotations to the interface class you are using. Here is an example:

interface GitHub {
@RequestLine("GET /repos/{owner}/{repo}/contributors")
@Size(min = 1, max = 3)
List contributors(@Param("owner") String owner, @Param("repo") String repo);


static class Contributor {
@Size(min = 10)
String login;
int contributions;

public static void main(String... args) {

Validator validator = Validation.buildDefaultValidatorFactory().getValidator();

GitHub github = ExtendedFeign.builder(validator)//
.decoder(new GsonDecoder()).target(GitHub.class, "https://api.github.com");

// Fetch and print a list of the contributors to this library.
try {
List contributors = github.contributors("OpenFeign", "feign");
for (Contributor contributor : contributors) {
System.out.println(contributor.login + " (" + contributor.contributions + ")");
} catch (ConstraintViolationException ex) {


If you would run this class, you can see, that the response is being validated against the given annotations and all violations a printed to stdout.

  • First, the @Size annotation leads to a constraint violation, because the size of the list is checked, whether it has at least one or maximim three items.
  • Because of @Valid, each item in the list of contributors is validated
  • @Size in Contributor class is set to verify, that the login name must have at least 10 characters. Because not all contributors have such a long name, a few more violations are reported
  • as seen, you can use any annotation from the api to fulfil the need

So what are you waiting for?

  • add



    to your dependencies

  • exchange¬†feign.Feign.builder¬†with¬†com.github.mwiede.feign.validation.ExtendedFeign.builder
  • and add annotations like explained above.

Deploy an app to Heroku using Wildfly and Postgresql driver

Since a Postgres Database is the most simple persistent datastore at Heroku, I was trying to setup a jee application example using this SQL database. If you have already read some of my previous blogposts, I am using Buildpack API to deploy the application to a Dyno.

Since I already got an example working with Wildfly and Mysql, it was an easy step to conduct a buildpack to install the Postgresql driver into the Wildfly container. It’s now available at¬†https://github.com/mwiede/heroku-buildpack-wildfly-postgresql.

I also provide an example of the application, which uses maven properties to extract the database url and credentials from system properties and use them in persistence.xml.

Here are the build and deploy steps to make it work (compare to https://github.com/mwiede/greeter#usage)

$ git clone https://github.com/mwiede/greeter.git
$ cd greeter
$ heroku create
$ heroku addons:create heroku-postgresql:hobby-dev
$ heroku buildpacks:clear
$ heroku buildpacks:add heroku/java
$ heroku buildpacks:add https://github.com/mwiede/heroku-buildpack-wildfly
$ heroku buildpacks:add https://github.com/mwiede/heroku-buildpack-wildfly-postgresql
$ git push heroku master

encode special characters using maven-antrun-plugin

Recently I was deploying an java web application on heroku, but one of the fields, which were picked up from system properties to be used during the maven build to set the credentials of the datasource, contained a non escaped character, which brought the deployment to fail:

21:37:17,355 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ROOT.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ROOT.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ROOT.war"

        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at java.lang.Thread.run(Thread.java:748)

Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Unexpected character '<' (code 60) (expected a name start character)

 at [row,col {unknown-source}]: [25,26]

        at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:105)

        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)

        ... 5 more

Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '<' (code 60) (expected a name start character)

 at [row,col {unknown-source}]: [25,26]

        at com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:647)

        at com.ctc.wstx.sr.StreamScanner.parseFullName(StreamScanner.java:1933)

        at com.ctc.wstx.sr.StreamScanner.parseEntityName(StreamScanner.java:2057)

        at com.ctc.wstx.sr.StreamScanner.fullyResolveEntity(StreamScanner.java:1525)

        at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2748)

        at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1073)

        at com.ctc.wstx.sr.BasicStreamReader.getElementText(BasicStreamReader.java:670)

        at org.jboss.jca.common.metadata.common.AbstractParser.rawElementText(AbstractParser.java:166)

        at org.jboss.jca.common.metadata.common.AbstractParser.elementAsString(AbstractParser.java:153)

        at org.jboss.jca.common.metadata.ds.DsParser.parseDataSource(DsParser.java:1149)

        at org.jboss.jca.common.metadata.ds.DsParser.parseDataSources(DsParser.java:177)

        at org.jboss.jca.common.metadata.ds.DsParser.parse(DsParser.java:120)

        at org.jboss.jca.common.metadata.ds.DsParser.parse(DsParser.java:79)

        at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:90)

        ... 6 more

To come around this problem, we need to encode those characters as proper xml entities. So here is how I did this:

First, introduce the system property as maven property inside of the property section:


Second, define the maven-antrun-plugin as plugin to be executed during validate phase, the phase, before even resources are copied or filtered by maven. Important is that the flag exportAntProperties is set to true. I was not able to override an existing property, therefore I created new ones.

<script language="javascript">

if (!String.prototype.encodeHTML) {
String.prototype.encodeHTML = function () {
return this.replace(/&/g, '&amp;')
.replace(/</g, '&lt;')
.replace(/>/g, '&gt;')
.replace(/"/g, '&quot;')
.replace(/'/g, '&apos;');



Third, use the properties in any resouce file while filtering:

<datasources xmlns="http://www.jboss.org/ironjacamar/schema"
xsi:schemaLocation="http://www.jboss.org/ironjacamar/schema http://docs.jboss.org/ironjacamar/schema/datasources_1_0.xsd">
<!-- The datasource is bound into JNDI at this location. We reference
this in META-INF/persistence.xml -->
<datasource jndi-name="java:jboss/datasources/GreeterQuickstartDS"
pool-name="greeter-quickstart" enabled="true" use-java-context="true">


See the complete code example at my github repo https://github.com/mwiede/greeter.

Connecting from jconsole or VisualVM to wildfly swarm instances

Recently I was trying out to monitor a wildfly swarm application and I wondered why the standard java approach to connect via JMX RMI did not work. I was using parameters

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.rmi.port=9010 -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

and I was not able to connect via rmi.

But some articles (http://www.mastertheboss.com/jboss-server/wildfly-8/monitoring-wildfly-using-visualvm and https://dzone.com/articles/remote-jmx-access-wildfly-or) gave hints about the same issue with Jboss or Wildfly, so basically it works the same way. On the other hand, it would have been possible using jolokia, which reports via http endpoint, but it was driving me nuts, why I could’nt get it to work with jdk tools. Even in the wildfly swarm documentation, it is not really described.

Here are the steps, how to connect.

  • Check whether you have fraction jmx and or management inside your pom. jmx is mandatory, and management is important to know, because if you do not have it, you will be able to connect on the applications listening port (standard is 8080), otherwise, you can only connect via administration port (standard is 9990).
  • Start your application. I realized, that although you are trying to connect from your local to an application running on your local, the connection does not succeed. In any other scenario, for example, if you application is running in your docker host, then you have to configure the swarm to allow connections from remote anyway. When service is not configured to allow remote connections, the following appears in the log:
[org.wildfly.swarm.jmx] (main) JMX not configured for remote access

To allow remote connections, you have to start your app with parameter


or you have to provide this setting in the yaml.

  • If you do not have management as fraction, then you will find the following line in the logs
[org.wildfly.swarm.jmx] (main) JMX configured for remote connector: implicitly using standard interface
  • When using jconsole or jvisualvm you will need a jboss-client.jar which contains the implementation of the vendors protocol. As mentioned on the other sites, you can easily start jconsole with a script provided in any of the downloads of wildfly application server, which already included the required library.

To start jvisualvm, you need to do it like this:

jvisualvm.exe -cp:a $JBOSS_HOME\bin\client\jboss-client.jar

If you do not want to download the complete server package, you can also use the library itself. Maven coordinates:


or download link https://repo.maven.apache.org/maven2/org/wildfly/wildfly-client-all/12.0.0.Final/wildfly-client-all-12.0.0.Final.jar

  • If you do not have management fraction connect with string

or if you have management fraction included, connect with

  • If you are using service:jmx:http-remoting-jmx://localhost:9990 to connect, you will find a warning in the standard out
WARN: The protocol 'http-remoting-jmx' is deprecated, instead you should use 'remote+http'.

So please keep in mind, that the deprecated connection strings mentioned everywhere in the internet, will not work any more in the future.

Free tier hunt – howto combine heroku and openshift


Recently, RedHat shutdown its openshift platform v2. Now only openshift 3 is available and it is based on kubernetes and docker.

So why do I care?

I had some JEE projects running on openshift 2 and now I was forced to migrate them to the new infrastructure. Basically my applications consist of a tomcat or wildfly server running next to a mysql database. This setup was pretty easy and I could run this at no cost as long as I could tolerate, that the cartridges would be shutdown if they idle longer then 24 hours (meaning no http request was coming to the server during this time). But ok…

So now I had to migrate my projects following the migration guide provided by Redhat. But in parallel I was interested whether I have other options or if there are any other Paas providers giving out a free tier for personal small projects. And yes, there are plenty of them, but as I found, all have their limitations.

AWS is for 1 year, then pay. Google cloud … cant remember what was holding me back…Oracle cloud gives a certain amount of money, but evaluation phase is 3 month max. Microsoft…really?

Going with Heroku, but…

Then I found heroku offering “free dyno”, which also idles after 30min inactivity, but I wanted to give it a try. Later I found, that if you want to use a database with heroku, the limitations on the “free” database are like 5MB or 100 rows, so even if I have only a few playaround datasets, that was too small.

Then I had the idea of connecting two Paas providers. One giving me the application tier for free, the other one is giving me the database for free.

I ended up looking on how to connect to a database running on openshift from outside of the docker environment. What I found is the same way an admin would connect to it, via a tunnel and/or port forwarding.

Oh my god, the latency between application and database will be huge!

Yes, that is possible, but as I do not want to propose this setup for an enterprise application running in production, I am fine.

So here is my solution on how to connect from an application running in a heroku dyno to a mysql database running in openshift.

Heroku provides a mechanism which allows you to pack anything into your dyno, which you need to run your application. So if you need java, then the buildpack “heroku/java” is for you. If you need node, there is a buildpack for node and so on. The nice thing about the buildbacks is, that you can also create them on your own, using the buildback API

A buildpack can contain a shell script (profile.d), which is executed during startup of the container. The perfect way to create a tunnel and provide access to my remote database. You can find the buildpack at https://github.com/mwiede/heroku-buildpack-oc

So here is how you can create a heroku application having access to a remote database:

  1. install Heroku CLI
  2. create an app
  3. add my buildpack
    heroku buildpacks:add https://github.com/mwiede/heroku-buildpack-oc
  4. configure environment variables
    $ heroku config:set OC_LOGIN_ENDPOINT=https://api.starter-ca-central-1.openshift.com 
    $ heroku config:set OC_LOGIN_TOKEN=askdjalskdj 
    $ heroku config:set OC_POD_NAME=mysql-1-weuoi 
    $ heroku config:set OC_LOCAL_PORT=3306 
    $ heroku config:set OC_REMOTE_PORT=3306
  5. deploy the app
  6. look for the logs, whether connection works properly.

Advanced usage

The profile.d script contains a loop so whenever the connection of the tunnel shuts down, it tries to open it up again.

From the perspective of openshift, the database runs in a so called pods and unfortunely it’s name can change.

I tried to make this as robust as possible, so the name in¬†OC_POD_NAME should only contain a prefix of how the pod is named, for instance “mysql” is enough to detect the right one.