Category Archives: JAVA

Mockito : how to mock method return value based on argument ?

When using mockito to mock some methods behaviour, you may want to change your mocked method return value based on an argument value.

This is not obvious, but quite simple to achieve, thanks to this SO post :

when(mockObject.myMethod(anyString()))
     .thenAnswer(invocation -> invocation.getArgument(0, String.class));

Spring Data and JpaRepository method naming convention

Spring Data can infer SQL queries from JpaRepository method name. That’s a great tool to uniformize query generations, and make code more readable. Obviously, this only works for simple SQL queries, wchich is indeed what you should strive for.

The documentation about the JpaRepository method naming convention is available here :

https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#jpa.query-methods

Key points :

  • “Order by” is represented by the keyword “OrderBy”, followed by the name of the entity member variable. Keyword “Asc” and “Desc” indicates the sort direction. You can sort by multiple columns by specifying each colum and its sort direction.
    Ex : findByDossierOrderByDateAscIdAsc(Dossier dossier)

Named parameter not found in JPA/Hibernate native SQL queries

When using named parameters in native SQL queries with Hibernate implementation of the Java Persistence API (JPA), you may run into the following error
[code lang=java]
org.springframework.dao.InvalidDataAccessApiUsageException: Parameter with that name [orderId] did not exist;
nested exception is java.lang.IllegalArgumentException: Parameter with that name [orderId] did not exist
[/code]

This happens even if the named parameter was properly set, as in the following example :

For example :
[code lang=java]
void update(EntityManager em) {
Query q = em.createNativeQuery(“SELECT * FROM orders where id = :orderId;”);
q.setParameter(“orderId”, “1234”);
q.executeUpdate();
}
[/code]

The issue comes from Continue reading

Solving Eclipse/maven error : dependency/ a.b.c (managed from x.y.z)

If Eclipse/M2E reports a maven dependency version conflict, with message “managed from x.y.z” (ex : “jooq/ 3.7.1 (managed from 3.6.0)“), the conflicting dependency is defined by an ancestor of the current maven project (could be its parent, great-parent, great-great-parent, etc.).

For example, let’s say maven signals a dependency conflict for a spring-boot 1.3 application. Version 3.7.1 of the JOOQ library is used while you specified version 3.6.0 (which is a pain because JAVA 7 is targeted, while JOOQ 3.7.1 only supports JAVA 8).

The error returned by the SpringBoot application is :
[code]
java.lang.UnsupportedClassVersionError: org/jooq/SQLDialect :
Unsupported major.minor version 52.0
[/code]

JOOQ is used by a dependency of the spring-boot application. The main application itself has no reference to JOOQ.

Indeed :

  1. project A declares a maven dependency on JOOQ 3.6.0 :
    [code lang=xml]

    org.jooq
    jooq
    3.6.0

    [/code]
    datawarehouse-jooq-dependency
  2. project B declares a maven dependency on project A, and defines spring-boot-starter-parent as a parent
    In project B dependencies, Eclipse/M2E flags JOOQ as “version 3.7.1 (managed from 3.6.0)” while version 3.6.0 is expected.
    feedbackrestservices-jooq-dependecy
  3. spring-boot-starter-parent has spring-boot-dependencies as a parent, which itself manages dependencies for JOOQ
    spring-boot-dependencies-managed-dependencies-jooq
    [code lang=xml]

    org.jooq
    jooq
    ${jooq.version}

    [/code]

To fix it, you could add a jooq 3.6.0 dependency to project B, so that the maven dependency conflict solving strategy uses this version since it is the nearest dependency. But that would be ugly. A cleaner solution consists in overriding the jooq.version property defined in spring-boot-starter-parent, as documented here :
[code lang=xml] 3.6.0 [/code]