com.datastax.oss.driver.internal.core.util.Reflection still references slf4j

Description

The mapper processor fails due to missing dependency to slf4j, which was removed in JAVA-2800. Output of "mvn clean compile -X":

Our temporary fix was to add the slf4j dependency to the <annotationProcessorPaths>:

Not sure whteher this problem also has to do with the fact that we have @Mapper and @Dao in the same class? For example:

Thank you for your help.
Kind regards
Mirko

Environment

None

Pull Requests

None

Activity

Show:
Olivier Michallat
August 17, 2020, 1:57 PM

Sorry about that.

The error happens because the DAO is a nested class, the fact that the outer class is also annotated does not play a role. Your temporary fix is right, you can also add slf4j-nop if you want to avoid the warning message about missing bindings.

I will revisit this for the next release. It's OK if the processor code accidentally issues a few logs that will be ignored, but they shouldn't make the compilation fail.

Olivier Michallat
August 18, 2020, 11:00 PM

The error happens because the DAO is a nested class

Just for posterity: I was completely wrong there. The error happens whether the DAO interface is nested or not. It comes from the check introduced in JAVA-2298, which is done for @Query or any annotation that has custom clauses.

Olivier Michallat
August 19, 2020, 12:04 AM
Edited

This is a real conundrum. The hard part is that the annotation processor can be used in two different ways:

  1. via -processorpath

  2. as a regular dependency, and the compiler will look for processors in the normal classpath.


We need a solution that works in both cases.

If the processor brings its own SLF4J binding, that will prevent the "Defaulting to no-operation (NOP)" warning in situation 1. But it will collide with the user's own binding in situation 2, which leads to a different warning: "Class path contains multiple SLF4J bindings".

I think the most pragmatic approach would be to simply revert JAVA-2800, and let the "Defaulting to no-operation (NOP)" warning surface. It's not a big deal, and it's an accurate description of the situation after all: we do want to default to NOP.

If users really want to get rid of the warning, they can add slf4j-nop manually to their processor path. We can explain that in the manual.

Fixed

Assignee

Olivier Michallat

Reporter

Mirko Zanotti

Labels

None

PM Priority

None

Reproduced in

4.8.0

Affects versions

Fix versions

Pull Request

None

Doc Impact

None

Size

None

External issue ID

None

External issue ID

None

Components

Priority

Major
Configure