jGitFlow: "CheckoutConflictException: Checkout conflict with files"

This error probably means the master and develop have diverged and develop is behind master. Just merge master to develop and try building again.

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>

F5 VPN Client under Linux

It looks like many places have outdated or plain wrong instructions about connecting to f5 VPN under Linux is a bit outdated so a quick reminder:

1. Ignore web plugin/extension, it probably won't work anyway under 64 bit browser with disabled NPAPI support
2. download and extract https://vpn.somehost.com/public/download/linux_sslvpn.tgz
3. execute Install.sh
4. f5fpc --start -t vpn.somehost.com

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.

ORA-00932: inconsistent datatypes: expected - got (N)CLOB

If you are modifying query and suddenly started getting ORA-00932 out of nowhere, remember that this error comes not only from comparing CLOB column with something else but also from using distinct on table that has CLOB columns.

Spammers hall of (f|sh)ame

I decided to reward  all spammers that are able to bypass gmail filters with place on this short list. It helps me remember which companies can't afford to pay for real marketing, have inferior product and think that best way to gain a customer is to waste their tame and annoy them.

• Volkswagen Group Polska Sp. z o.o. 
• TERG S.A. (Media Expert)
• T-MOBILE POLSKA S. A. +1

Spring component-scan classpath pitfall

There is one non-intuitive behavior with Spring's component-scan - it works on _current_ classpath. For example:

Project A

context-a.xml:

    <component-scan package="x">


Project B

context-a.xml:

    <import resource="classpath:/a.xml" /> 

    <component-scan package="x.y">

This will load all components from  package "x.y" already at <import> tag.  It can lead to very strange errors in bigger projects (sudden appearance of "NoSuchBeanDefinitionException: No qualifying bean of type" errors) and  trying to cherry-pick used imports/components might be hard or even impossible.
There is similar issue with integration tests - Spring will scan all classes in package, including test files, for components. If you are using inner static classes to override context configuration spring will pick up all of them. And that problem might propagate if you are reusing test support code (<classifier>tests</classifier>). Lucky this one is easy to deal with: it is possible to filter it out:

<context:component-scan base-package="my.package" >
        <context:exclude-filter type="annotation" expression="org.springframework.context.annotation.Configuration" />
        <context:exclude-filter type="regex" expression=".*IT" />
        <context:exclude-filter type="regex" expression=".*Test" />
</context:component-scan>