Async Profiler - quick profiling for any application

Are you tired of setting up Java APM agents, configuring some arcane ENV variables (does "org.jboss.logmanager" ring any bells)? Just try Async Profiler ( https://github.com/jvm-profiling-tools/async-profiler ). It is even trivial to use on your already *running* docker images. For example: 

$ kubectl -n my-namespace cp ./async-profiler-2.8-linux-x64.tar.gz my-pod:/root
$ winpty kubectl -n my-namespace exec -it my-pod bash  
root@my-pod:/# cd /root
root@my-pod:~# tar xf async-profiler-2.8-linux-x64.tar.gz
root@my-pod:~# cd async-profiler-2.8-linux-x64
root@my-pod:~/async-profiler-2.8-linux-x64# ./profiler.sh -d 1200 -i 10ms -f profile.html 6
Profiling for 1200 seconds
Done
root@@my-pod:~/async-profiler-2.8-linux-x64# exit
kubectl -n my-namespace cp my-pod:/root/async-profiler-2.8-linux-x64/profile.html ./profile.html

Where "-i 10ms" was how often to run sampling and "6" was the pid of java process (you can check for one with `jps` or plain old `ps`). You can view the resulting flame graph (the local "profile.html" file) in any browser.

Wildfly: NoSuchMethodError: Logger.tracef

When adding Arquillian based integration tests to older projects I often encounter exception:

Exception in thread "Remoting "endpoint" task-4" java.lang.NoSuchMethodError: org.jboss.logging.Logger.tracef(Ljava/lang/String;I)V
        at org.jboss.remotingjmx.VersionedConectionFactory$ClientVersionReceiver.handleMessage(VersionedConectionFactory.java:158)
        at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
        at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

It is caused a mismatch in versions of jboss-logging. The solution is to find additional version:

$ mvn dependency:tree |grep jboss-logging
...

[INFO] +- com.google.guava:guava:jar:18.0:compile
[INFO] +- org.jboss.resteasy:resteasy-client:jar:3.0.19.Final:compile
[INFO] |  +- org.jboss.resteasy:resteasy-jaxrs:jar:3.0.19.Final:compile
[INFO] |  |  +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:compile
[INFO] |  |  +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:compile
[INFO] |  |  +- javax.activation:activation:jar:1.1.1:compile
[INFO] |  |  +- commons-io:commons-io:jar:2.1:compile
[INFO] |  |  \- net.jcip:jcip-annotations:jar:1.0:compile
[INFO] |  \- org.jboss.logging:jboss-logging:jar:3.1.4.GA:compile

And to exclude it in pom.xml:

        <dependency>
            <groupId>org.jboss.resteasy</groupId>
            <artifactId>resteasy-client</artifactId>
            <version>3.0.19.Final</version>
            <scope>provided</scope>
            <type>jar</type>
            <exclusions>
                <exclusion>
                    <groupId>org.jboss.logging</groupId>
                    <artifactId>jboss-logging</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Most common (anti-)pattern

I guess that by now everyone knows that Singleton is considered mostly harmful and definitely overused. Many people have said that it hinders testing but there is nothing more convincing that unit test that completes fine on its own but mysteriously fails when whole suite is launched. It looks strange when even after doing reset() and adding new when() rules the mock created by Mockito behaves in wrong way. It is a lot less mysterious when you find a singleton that was injected with mock object on class load and ignores the fact that whole Spring context was created and destroyed multiple times ever since.