Testing of JavaEE Applications with Arquillian

Consider following trivial JavaEE application:


Sample JavaEE application with module FooBean we want to test

We want to test FooBean. However FooBean uses database or a distributed cache (e.g. Infinispan) or even another EJB bean. I.e. it depends on expensive component.


Optimistic vs Pessimistic Locking in JPA

Issue Optimistic Pessimistic
Deadlocks No
execution goes straight without locking anything in database. Execution may fail if a concurrent thread modified the same record  ( OptimisticLockingException will be throw in this case)
database-level locks are acquired and hence deadlock may occur
Transaction Span Temporal and spatial span
entity version could be conveyed to client which can hold it as long as he wants. This allow a virtual transaction to span both temporal and spatial. Only during commit version check will be enrolled to ensure data integrity
No span
it would be a suicide to hold a database-level lock on an entity which is edited by client remotely. This would quickly exhaust all system resources. As such no transaction span is available
Changes Overwrite No
changes made to an entity in another thread are detected and transaction is aborted – this prevents unwanted overwrites
changes made to an entity in another thread are not detected – they are simply overwritten (last change wins)
Changes in Tables Required
need to add column into each table for storing a version counter  ( javax.persistence.Version)
everything needed is provided by database itself
Performance Better
doesn’t require and database interactions – recommended for web apps which must scale
requires explicit locking in database which is expensive




Exception Handling in JavaEE RESTful API

Challenges of Exception Handling

Let’s consider a JavaEE web application with an API exposed via RESTful endpoints. Exceptions… They are just everywhere and of course they will be raised in our API as well. As such during development of API following challenges will emerge:

  1. security risks – sensitive data from exceptions could leak from server to the client’s side;
  2. complicated API adoption – indistinguishably or hardly identifiable exceptions makes it hard to handle them on a client’s side and as consequence renders bad user experience (some user scenarios behave unpredictably or simply dumb);
  3. complicated troubleshooting in production – support dude must have an ability to localize in a moment any failure point happened in the past in logs / system journals.


metracer — New Release 1.3.2

New version of metracer 1.3.2 was just released. Compared to a previously announced 1.2.0 release following main changes happened:

# Change Description
 1 Dynamic instrumentation Now it’s possible to inject tracing into a running Java process without any restarts! One can repeat this many times for different classes and methods. After one is finished with experiments all instrumentation traces can be removed leaving application in an original state.
To ease metracer.jar launching a frontend script – – was introduced. One only needs this single script (without any additional bits) to start working! There are a built-in usage notice and help message for a quick on-boarding.
Such dynamic instrumentation was made possible by the use of Java Attach API and  JMX technologies
2 No more promiscuous patching of  ClassLoader Such patching was introduced as an aid against isolation imposed by JavaEE app servers (e.g. WildFly).
It was found another more elegant way to workaround this based on the fact that metracer bits are loaded into a system ClassLoader (see here). Given this one could easily resolve reference to a com.develorium.metracer.Runtime class from any point of program via code:

By using the code snippet above one doesn’t need anymore to patch any class loaders!
3 Improved stability of instrumentation Several design flaws and bugs in an instrumentation code were identified and fixed which lead to java.lang.VerifyError:

  • each call to Runtime.traceEntry or Runtime.traceExit is guarded with try / catch  block. As such any failures there won’t affect inferior application itself
  • proper boxing / unboxing of return value / exception on the stack
  • proper placement of RETURN opcode which is crucial for some reason for static class initializers ( <clinit>  method)

With these changes metracer is now a fully functional developer tool ready for hard use in production! Enjoy the POWER of METRACER!


metracer – Java Code Instrumentation and Stack Map Frames

Stack Map Frames in Java is a contradictory addition to the language: they speed up class loading but the same time make big troubles for a code instrumentation tools. During adoption of an ASM framework to a metracer I have stumbled with following main two issues:

  1. necessity to resolve a “common super class” during instrumentation which causes many ClassNotFoundException
  2. VerifyError exceptions with message like ‘Stack map does not match the one at exception handler’


metracer – No Runtime Dependencies + Nice Indentation

Based on my experiments with adoption of metracer to JavaEE (link) a new version of metracer 1.0.5 was released. Source code of new 1.0.5 version: svn co


metracer – Adoption to Java EE

Main target audience of a metracer are meant to be enterprise Java applications – metracer must enhance logging of such applications. As such I’ve tried to adopt metracer to a production level Java EE application which runs under WildFly AS. Speaking in terms of RPG games – tons of experience was earned :-). Results of my experiments are below.