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.10

metracer_logoNew bugfixing release of metracer is available – 1.3.10. This release fixes:

  • object’s dumping in case class contained a self referencing field (issue #54)
  • broken console state when program is closed via Ctrl+C (issue #55)

While working on this release it became clear that object’s dumping must be more smart and tunable – otherwise there is lots of noise when metracer encounters complex system objects. This would be addressed in a next metracer release.



metracer – New Release 1.3.9

After some tough fight a new metracer release is available – 1.3.9 (along with 1.3.8). These releases bring two outstanding features:

  1. Dumping content of arbitrary objects. This rocketlaunches inspection / investigation of Java programs to a completely new heights! All information flowing around inspected program is at your fingertips. E.g.:

    Dumping Content of Custom Objects

    Dumping Content of Custom Objects

  2. Single .jar in distribution without additional launcher scripts – all logic of launches scripts is incorporated into a single jar which makes the distribution. To start using metracer do two simple steps:
  • download a .jar file from latest release
  • launch: java -jar metracer.jar

Have fun and glad to see your feedback!



metracer — New Release 1.3.7

I’m happy to announce a new 1.3.7 release of metracer. Comparing to previously announced 1.3.3 released there were many significant changes including:

  • vertical instrumentation (issue #27)
  • better printing of return values (issue #44)
  • auto-quit when target JVM dies (issue #20)
  • and of course Windows support (issues #28#49#50#51)

Full release notes are available on respective pages: 1.3.4, 1.3.5, 1.3.6 and 1.3.7.


Unbuffered Standard Input in Java Console Applications

Say you’re writing a Java console application and want to handle user input in an unbuffered mode. That’s said you don’t want the user to press Enter / Return after some typing – you want that every keyboard hit is delivered to your program immediately. Something similar is implemented in metracer for closing the program when user presses ‘q’.  Let’s see how to implement this in Linux.


metracer — New Release 1.3.3

I’m happy to announce a new 1.3.3 release of metracer. This release brings several small but very useful features and fixes couple of nasty bugs. See below for a discussion of most notable changes.

Full change list as well as binaries are available on release notes page.


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 – metracer.sh – 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 — New Release 1.2.0

New version of metracer 1.2.0 was just released. Main changes are:

# Change Description
1 Use of ASM for instrumentation  A move was made towards ASM instrumentation framework instead of Javassist. This allowed to:

  • increase performance
  • lower memory footprint
  • get rid of creation of proxy methods – now a tiny pieces of code are injected directly into target methods
2 Reporting of return values Now there is information of return values of instrumented methods, e.g.:metracer_return_value_
3 Extended reporting of exceptions Now the string representation of exception is printed for instrumented methods, e.g.:metracer_exceptions

With these changes metracer became more efficient, lightweight. Changes provide an opportunity for “hot” code instrumentation (without program restart).