We Keep Coding

ERROR JacksonVersion - Version '2.9.4' of package 'jackson-databind' is not supported

i am using azure sdk(azure-storage-file-datalake, azure-core, azure-identity) for writing the avro data to azure datalake gen 2 from kafka(using connectors), but i am getting very weird errors as below
2022-05-12 10:46:10 ERROR JacksonVersion:506 - Version '2.9.4' of package 'jackson-annotations' is not supported (older than earliest supported version - 2.10.0), please upgrade.
2022-05-12 10:46:10 ERROR JacksonVersion:506 - Version '2.9.4' of package 'jackson-core' is not supported (older than earliest supported version - 2.10.0), please upgrade.
2022-05-12 10:46:10 ERROR JacksonVersion:506 - Version '2.9.4' of package 'jackson-databind' is not supported (older than earliest supported version - 2.10.0), please upgrade.
java.lang.LinkageError: Package versions: jackson-annotations=2.9.4, jackson-core=2.9.4, jackson-databind=2.9.4, jackson-dataformat-xml=unknown, jackson-datatype-jsr310=unknown, azure-core=1.28.0, Troubleshooting version conflicts: https://aka.ms/azsdk/java/dependency/troubleshoot\n\tat com.azure.core.implementation
I have tried excluding the jackson dependencies and tried adding explicitly, still i am getting the errors.
please some one help on this
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<version>2.13.2</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>2.13.2</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.13.2</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
<version>2.13.2</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-jsr310</artifactId>
<version>2.13.2</version>
<scope>runtime</scope>
</dependency>
<dependencies>
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>connect-api</artifactId>
<version>2.0.1</version>
<scope>provided</scope>
</dependency>
<!--<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>1.1.0</version>
<scope>provided</scope>
</dependency>-->
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
<!-- Apache avro dependency -->
<dependency>
<groupId>org.apache.avro</groupId>
<artifactId>avro</artifactId>
<version>1.8.2</version>
</dependency>
<!-- Newer versions of the storage account jar is not working. -->
<dependency>
<groupId>com.azure</groupId>
<artifactId>azure-storage-file-datalake</artifactId>
<version>12.9.0</version>
<exclusions>
<exclusion>
<groupId>com.azure</groupId>
<artifactId>azure-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- https://mvnrepository.com/artifact/com.azure/azure-core -->
<dependency>
<groupId>com.azure</groupId>
<artifactId>azure-core</artifactId>
<version>1.28.0</version>
<exclusions>
<!-- Collision with Kafka Jackson dependencies -->
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-jsr310</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.azure</groupId>
<artifactId>azure-identity</artifactId>
<version>1.5.1</version>
<exclusions>
<exclusion>
<groupId>com.azure</groupId>
<artifactId>azure-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.microsoft.azure</groupId>
<artifactId>msal4j</artifactId>
</exclusion>
<exclusion>
<groupId>org.linguafranca.pwdb</groupId>
<artifactId>KeePassJava2</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>msal4j</artifactId>
<version>1.9.1</version> <!-- {x-version-update;com.microsoft.azure:msal4j;external_dependency} -->
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- Schema registry dependency -->
<dependency>
<groupId>io.confluent</groupId>
<artifactId>kafka-connect-avro-converter</artifactId>
<version>3.3.0</version>
<exclusions>
<exclusion>
<groupId>io.confluent</groupId>
<artifactId>kafka-schema-registry-client</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>io.confluent</groupId>
<artifactId>kafka-schema-registry-client</artifactId>
<version>3.3.0</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.21.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>
</dependencies>

Dependencies with scope "runtime" are not used for compilation, but only for execution. A dependency with this scope is not put on the compile classpath, so you could remove the runtime scope.
However a better way to overwrite transitive dependency versions that you don't use yourself is to use depependency management like this:
<project>
[...]
<dependencyManagement>
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
</dependency>
[...]
</dependencies>
</dependencyManagement>
</project>

This is a challenge with Azure-SDK (here is a similar issue). Azure-SDK has a dependency on Jackson. The specific version of Jackson depends on the azure-sdk version you are using.
The latest release supports Jackson 2.10-2.13. What it means is you may have other dependencies on Jackson, and the SDK will still work. Provided Jackson version fetched is from 2.10-2.13. Azure-SDK is compatible with all these versions.
If you wish to use Jackson 2.9 (or if that's coming as a dependency from other dependency), then there is no way around it. You would necessarily need to upgrade your dependencies so that it fetches jackson 2.10 and above.
In your case, there would be some dependency that is fetching 2.9.x series.
This is what I would do:
Based on all non-azure-sdk dependencies. Decide which jackson version to hold on to. Explicitly add this jackson dependency in the pom.xml
Use azure-sdk BOM
You dont have to specify exclusion. Specifying a version in pom overrides other dependency versions

Hosting environment had those 2.9.4 versioned jackson jars which were loading at run time and causing the issues, i replaced those with newer version jars , its working all fine now.
(we had installed kafka client on the host, which internally had those jars inside kafka/libs)
got the ans from - https://github.com/Azure/azure-sdk-for-java/issues/28902

How can I remove the old vulnerable Apache commons collection version dependency from my project's maven dependency tree?

My Java app project is being managed by Maven.
My project has a few library dependencies depending again on Apache commons collection 3.2.1 which is vulnerable - e.g. Apache commons configuration, velocity, etc.
(I can see it is being used by running mvn dependency:tree command.)
I did neither write any line of codes using Apache commons collection directly nor defined the dependency of it, but it's being used.
What could I do to remove its dependency and to force to use safe version - 3.2.2, 4.1.
For your information:
JIRA Bug - Arbitrary remote code execution with InvokerTransformer
Here is the part of my pom.xml, and I guess there's nothing remarkable.
...
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.velocity</groupId>
<artifactId>velocity</artifactId>
<version>1.7</version>
</dependency>
...

Unless I am missing something obvious, just specifying dependency in your POM ought to be sufficient:
<dependencies>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.2</version>
<dependency>
...
</dependencies>
If you specify it a the top of your <dependencies> section, it will override any other transitive inclusion of commons-collections.
Of course, you may wind up with incompatibilities where other dependencies depend on the other version, but that's what unit tests are for, right? ;-)

What you need to do is exclude commons-collections from the affected dependencies and include the desired version in your dependencies directly.
Example pom.xml excerpt assuming commons-configuration uses the vulnerable commons-collections
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.10</version>
<exclusions>
<exclusion>
<artifactId>commons-collections</artifactId>
<groupId>commons-collections</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.2</version>
<scope>runtime</scope>
</dependency>
For simplicity I didn't show configuring this in a root pom.xml in the dependency-management section.
The <scope> should be set to runtime since you mentioned not using the library directly.

I've added these lines in my pom.xml, but still commons-collections3.2 is getting downloaded..
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.1</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>${apachecommonslang.version}</version>
<exclusions>
<exclusion>
<artifactId>commons-collections</artifactId>
<groupId>commons-collections</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>${dbcp.version}</version>
<exclusions>
<exclusion>
<artifactId>commons-collections</artifactId>
<groupId>commons-collections</groupId>
</exclusion>
</exclusions>
</dependency>

AbstractMethodError in Spring

I'm trying to store data with H2 and hibernate in my Spring project,
and i cant get rid of this:
SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener
java.lang.AbstractMethodError: ch.qos.logback.classic.Logger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
at org.apache.commons.logging.impl.SLF4JLocationAwareLog.info(SLF4JLocationAwareLog.java:159)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:187)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
my pom file:
http://pastebin.com/hxXyZi9b
Whats wrong?

There must be version mismatch between your mentioned slf4j dependencies and slf4j lib used spring-core in pom.xml.
If you are using eclipse, you can easily check(by searching) in Depedency Hierarchy tab in pom.xml.

From Spring references documentation:
A common choice might be to bridge Spring to SLF4J, and then provide explicit binding from SLF4J to
Log4J. You need to supply 4 dependencies (and exclude the existing commons-logging): the bridge,
the SLF4J API, the binding to Log4J, and the Log4J implementation itself. In Maven you would do that
like this
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.1.0.BUILD-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
</dependency>

How to redirect all logs from hibernate and spring to log4j2?

I build my "superWebApp" with the next technology stack:
persistence provider - Hibernate 4.x
webMvc and beans container - Spring 4.x
web containter - Tomcat 7.5.x
I have a task to write all logs to db. And it would be a pain to do it for each logging framework separately. That's why I need to redirect all logs to single framework and then using a DBAppender wouldn't be a problem.
I was thinking about log4j2, since I use it to write logs in "superWebApp". So is there any idea how to redirect all logs from hibernate and spring to log4j2? (it would be good to redirect tomcat loogs too)?
If it is not possible, maybe there is another logging framework that can be central?

This worked perfectly for me:
<properties>
<logger.version>2.0-rc1</logger.version>
</properties>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>${logger.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>${logger.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<version>${logger.version}</version>
</dependency>
<dependency>
<!--HIBERNATE-SPRING - LOGGER (log4j)-->
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.6</version>
</dependency>

From Logging Spring using Log4j2, we must use log4j-slf4j-impl.
I have tested it with Spring 4 also struts 2 and it works fine.
<log4j2.version>2.1</log4j2.version>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>${log4j2.version}</version>
</dependency>

Can I use Apache HTTPClient without Commons-logging.jar

I'm trying to user Apache HTTPClient in my project. Here does not required any logging for this application. So Can I use HTTPClient without Commons-logging.jar. Otherwise it will be a extra unnecessary burden for my distribution package.

Yes you can. As Hannes suggested - here is my own HttpClient maven setup:
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.3.1</version>
<exclusions>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
Next, since common-logging is indeed a runtime dependency, you will need to define the SLF4J bridge for commons-logging:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.5</version>
</dependency>
And finally, you will of course need to have a valid SLF4J configuration - here is mine:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.5</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.0.11</version>
</dependency>
Hope this helps.

You can use slf4j with the JCL bridge. This will forward JCL logging to slf4j. Than you add a slf4j adapter like log back or log4j and configure it properly.
When using maven, do not forget to exclude the JCL dependency.
http://www.slf4j.org/legacy.html