Book review: Continuous Enterprise Development in Java

This is a very short review of the Continuous Enterprise Development in Java book.

The book can be easily split in two parts.

The first part of the book from chapter 1 to chapter 4 javaArguillian contains general information about the difficulty of testing the JEE applications, about the software development cycles, the types of testing and some more technical details about the testing frameworks (JUnit and TestNG), about build tools like Maven and (JBoss) Forge, about version control (only Git deserves a paragraph) and (finally) about the Arquillian which is presented as “an innovative and highly extensible testing platform for the JVM”.

A very nice introduction is done to the ShrinkWrap  which is an API to create programmatically deployable JEE archives (jars, wars, ears).

An entire chapter (Chapter 3) is dedicated to write and deploy some business code and the associated Arquillian tests. Almost all the tools used in this chapter are JBoss or RedHat tools; Forge for the build of the application, JBoss Application Server to deploy the application, JBoss Developper Studio to deploy on the (Red Hat) OpenShift cloud service.

The second part of the book from chapter 4 to chapter 12 contains the implementation of the application, which is the JEE application. Every chapter is treating one aspect of the application: chapter 5  treats the persistence layer, chapter 6 the integration with NoSql data bases, chapter 7 the services layer, chapter 8 the REST services, chapter 9 the security, chapter 10 the user interface and chapter 11 the deployment on live.

Every chapter follow the same pattern, it starts with an introduction to the technology that will be used within the chapter, then the use cases and the business requirements are presented then it follows the implementation of the requirements and lastly the testing of the implementation using Arquillian.

I will conclude my ticket with a few points about what i like and what i don’t like about this book.

What i like about this book:

  • The author clearly masters the different JEE components; the technology introduction paragraphs of each chapter of the second part of the book are very clear and easy to understand.
  • The author knows the Arquillian framework inside out; all the examples are well explained and the introduction to ShrinkWrap is very well done.
  • Some of the chapters contains very valuable external references, like PicketLink for the security or Richardson Maturity Model for REST.

What i do not like about this book:

  • Too much marketing of the RedHat/JBoss products; I would have preferred to have more vendor agnostic examples of use for the Arquillian framework.
  • The subtitle of the book is “Testable Solutions with Arquillian” so it suppose to focus more on the testing part of the applications. Unfortunately, for me the book is not focusing on testing the applications but rather tries to  present how to continuously develop (JEE) applications and integration testing is only one part of this.
  • Nothing is said about the integration of Arquillian with other Java (non JEE) projects/frameworks like Spring and Guice and how Arquillian could ease (if it it can) the testing of the applications using these frameworks.

How to fix ElasticSearch client exception “A binding to org.elasticsearch.shield.transport was already configured at _unknown_. at _unknown_”

This ticket explains a possible solution  for the “A binding to org.elasticsearch.shield.transport was already configured at _unknown_. at _unknown_” exception when a Java ElasticSearch client tries to connect to a (ElasticSearch) cluster using Shield.


ElasticSearch version: 1.7.3

Shield version: 1.3.3


The way to connect a Java ElasticSearch client to a cluster using Shield is quite straightforward; you can see the ElasticSearch documentation. The most important part (at least in the context of this problem) is the creation of the Settings instance:

Settings settings = ImmutableSettings.settingsBuilder()
                .put("", clusterName)
                .put("shield.ssl.keystore.path", jksPath)
                .put("shield.ssl.keystore.password", jksPassword)
                .put("shield.transport.ssl", "true")
                .put("plugin.types", "org.elasticsearch.shield.ShieldPlugin")

When the client is executed, the following strange stacktrace is thrown:

Full stacktrace

1) A binding to org.elasticsearch.shield.transport.filter.IPFilter was already configured at _unknown_.
  at _unknown_
2) A binding to org.elasticsearch.shield.transport.ClientTransportFilter was already configured at _unknown_.
  at _unknown_
3) A binding to org.elasticsearch.shield.ssl.ClientSSLService was already configured at _unknown_.
  at _unknown_
4) A binding to org.elasticsearch.shield.ssl.ServerSSLService was already configured at _unknown_.
  at _unknown_
4 errors
       at org.elasticsearch.common.inject.internal.Errors.throwCreationExceptionIfErrorsExist(
       at org.elasticsearch.common.inject.InjectorBuilder.initializeStatically(
       at org.elasticsearch.common.inject.Guice.createInjector(
       at org.elasticsearch.common.inject.Guice.createInjector(
       at org.elasticsearch.common.inject.ModulesBuilder.createInjector(
       at org.elasticsearch.client.transport.TransportClient.<init>(
       at org.elasticsearch.client.transport.TransportClient.<init>(


Root cause

The root cause of this problem is the line:

.put("plugin.types", "org.elasticsearch.shield.ShieldPlugin")

If this line is removed then the problem is solved. This property should be exclusively used with the 2.0 version of Shield and not with  1.3.3 version.

The moral of this story ? First of all you should use the right version of the ElaticSearch documentation (in my case I was running the 1.7.3  version but I used the documentation for the 2.o). The second point is  that ElasticSearch API is not very user friendly (I even dare to say that is badly designed). I would preferred that ImmutableSettings.Builder class to have a put method with a Java enum as first parameter not a Java String.

AppDynamics Pro – basics

The goal of this ticket is to present and explain the basic notions of the AppDynamics Pro product.

  • Node – a node is the basic unit of processing that AppDynamics monitors. A node is instrumented by an AppDynamics agent.
  • Tier – a tier represents an instrumented service or multiple services that perform the exact same functionality. It represents a more logical view of the application.A tier is composed of one or multiple nodes.
  • Application – multiple tiers gathered together.
  • Business Transaction – represents a distinct logical user activity. The entire application traffic is organized in Business Transactions.
  • Transaction Snapshot -set of diagnostic data, taken at a certain point in time, for a specific Business Transaction across all the tiers though which the transaction has passed. The Transaction Snapshots are triggered periodically (every 10 minutes) or automatically for the slow and error business transactions.
  • Metrics -application performance informations sent from the App Server Agents and Machine Agents to the controller.
  • Baselines – set of metrics within a time range.
  • Baseline Deviations – degree of deviation from baseline at any given point in time and by default are calculated by a number of standard deviations above the average.
  • Service Endpoint – performance metrics focused on a particular service or set of services independent of business transactions.
  • Health Rule – defines a condition or set of conditions in terms of metrics. The condition compares the performance metrics that AppDynamics collects with some static or dynamic threshold that you define. If performance exceeds the threshold, a health rule violation event is triggered. There are two types of thresholds: Warning and Critical.
  • Diagnostic Session – the goal is to collect extra Transaction Snapshots for one or more Business Transactions for a period of time.
  • Events – emitted when the application state change. Eight type of events:
    • Health rules violation
    • Too many slow transactions
    • Too many errors
    • Code problems
    • Application changes
    • JVM and CLR (.NET) Crashes
    • AppDynamics Config Warnings
    • Discovery (new application, tier or done discovered)
  • Errors – AppDynamics treat as errors the following events:
    • unhandled exceptions
    • HTTP error codes from 400 to 505 (the error codes to catch are configurable)
    • Error or Fatal logging events (Log4j or java.util.logging)
  • Information Points – collects metrics outside the context of Business Transactions and across several Business Transactions. For me it looks similar with the Service Endpoints.
  • Data Collectors – collects extra-information at the Business Transaction level like application code arguments, return values, and variables and displays the information in the Call Drill Down panels. There are two types of Data Collectors : method invocation date collectors and HTTP data collectors.

How to use an external JavaScript file in a BIRT report

In a recent assignment I had to write some custom Java Script code to treat some table cells from an Eclipse BIRT report.

This ticket explains the setting of an external Java Script file in a BIRT report.

Define the resources folder for your BIRT project.

First step is to define the resources folder for your BIRT project. Go to the project properties -> Report Design ->Resource (as shown in the following screenshot). In our case the BIRT project is a (Java) Maven project so all the external resources are in the folder src/ressources.


Add the external Java Script file(s) to the BIRT report

In the property editor of the BIRT report, define the external resource files (in the following screenshot the “CustomFunctions.js” was added an external JavaScript file).


After adding the JS file, the rptdesign file the will look something like :

<report xmlns="" version="3.2.23" id="1">
 <property name="createdBy">Eclipse BIRT Designer Version 4.3.1.v201309091055 Build <4.3.1.v20130917-1035></property>
    <list-property name="includeScripts">

Use the custom JavaScript functions in the report

In the BIRT expression builder, use the custom JavaScript function (as in the following screenshot):


Update the BIRT web viewer

When the war file will be created, the src/ressources content will be copied under the folder WEB-INF/classes so, the BIRT web viewer servlet should be instructed where to find the resources folder under using a context parameter:

 <!-- Resource location directory. Defaults to ${birt home} -->

Generating Excel files with Apache POI – Removed Feature: Format from /xl/styles.xml part (Styles)

The problem

Some (big) Excel files generated using Apache POI cannot be correctly open by Excel (none of the styles applied to the cells are rendered). The error message shown by Excel is the following one :

Removed Feature: Format from /xl/styles.xml part (Styles)
Repaired Records: Cell information from /xl/worksheets/sheet1.xml part
Cell information from /xl/worksheets/sheet2.xml part
Repaired Records: Cell information from /xl/worksheets/sheet3.xml part

The cause

The root cause is that Excel can handle only a limited number of cell styles by workbook; Excel 2010 for example can handle 4000 cell style by workbook (see Excel specifications and limits).

The solution

The solution is quite simple (in theory). You have to limit the number of unique instances of used in your workbook. For this you can use the POI utility class

GenericSignatureFormatError while deploying SOAP web services

This ticket will present some problem that I encountered using  JAXB.


  • OS: Windows 7
  • Servlet container : Tomcat 7.X
  • JRE: Sun Java 1.6.0_11
  • JAXB version: 2.2.1

Stack trace

Trying to deploy a web application containing (SOAP) web services  failed with the following stack trace:

WSSERVLET11: failed to parse runtime descriptor: 
at sun.reflect.generics.parser.SignatureParser.error(
at sun.reflect.generics.parser.SignatureParser.parseSimpleClassTypeSignature(
at sun.reflect.generics.parser.SignatureParser.parseClassTypeSignatureSuffix(
at sun.reflect.generics.parser.SignatureParser.parseClassTypeSignature(

Cause of the exception

One of the web services had as return value a list of enums. The enum was defined something like :

public enum Season { WINTER, SPRING, SUMMER, FALL }

(no default constructor).

In order to fix the problem it must add a no parameter contructor; something like:

public enum Season { 
 Season() {}

aoplib4j-0.0.4 is out !

A new version of the aoplib4j is out. The library contains (only one) new aspect for transform a test assertion into a verify (see TransformAssertToVerifyForTests) and some other minor changes (see here).