Could you please let me know how to use spring-jdbc in Quarkus, as I am converting my application from spring to Quarkus, for now I required to use JdbcTemplate but I don't see how to use it.
I am using below dependencies:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-spring-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-spring-web</artifactId>
</dependency>
But I didn't find anything for spring-jdbc
There isn't such thing as JdbcTemplate in Quarkus, nor a support for spring-jdbc.
So the answer is that you cannot use them, you need to convert the usage to Spring Data (or HIbernate with Panache), or inject a DataSource object and directly work with it.
We found that past version works perfectly fine with native compilation. Hope that's good enough in your case.
Replacing logging is also required for native compilation, because of Class.forName usages.
<spring.jdbc.version>4.3.30.RELEASE</spring.jdbc.version>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>${spring.jdbc.version}</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>commons-logging-jboss-logging</artifactId>
</dependency>
Related
I was getting this exception
java.lang.NoSuchMethodError: org.apache.xml.security.utils.XMLUtils.decode
Then I updated my dependencies and moved on to another similar exception which I am unable to resolve for quite a while:
I am getting NoSuchMethodError when my module receives the request upon calling this method
WebServiceTemplate client = ...;
client.marshalSendAndReceive(req, new ActionCallback("http://samples/RequestOrder"));
it throws
java.lang.NoSuchMethodError: org.apache.xml.security.encryption.AbstractSerializer: method <init>()V not found
at org.apache.cxf.ws.security.wss4j.StaxSerializer.<init>(StaxSerializer.java:62)
the (at least I think) relevant part of my dependencies
<dependency>
<groupId>org.apache.ws.security</groupId>
<artifactId>wss4j</artifactId>
<version>1.6.15</version>
</dependency>
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-security</artifactId>
<version>3.0.9.RELEASE</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-security</artifactId>
<version>3.3.6</version>
</dependency>
I was looking at multiple versions of org.apache.xml.security.encryption and it doesn't look like any of those versions have such method. Any idea what would be the correct combination of versions?
as a sidenote I also found this library and thought that would be helpful , but it seems it is somewhat different than aforementioned <groupId>org.apache.ws.security</groupId>
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j</artifactId>
<version>2.3.0</version>
<type>pom</type>
</dependency>
I had similar issue and tried possible solutions online but to no avail.
Some of the documents suggested that dependency mismatch with other dependencies is key, like here.
In relation to this exact reported error, I kept on changing the version of the below dependency and finally reached this, which was the latest version as at the time this answer was posted.
<dependency>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
<version>2.1.4</version>
</dependency>
But remember to ensure that if you have the below dependency, exclude that of xmlsec :
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-security</artifactId>
<exclusions>
<exclusion>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
</exclusion>
</exclusions>
</dependency>
In my pom.xml, I have a SikuliX Jar which has a transitive dependency on jna-platform.
As seen in below image, version 4.5.2 has overrided version 5.4.0.
But i dont understand, how this version is overrided as i have not specified any dependency for jna-platform. I had also verified that no any there dependency is fetching this jar.
Please help me understand why this is happening. Any detailed document is well appreciated.
Related dependencies:-
<dependency>
<groupId>com.sikulix</groupId>
<artifactId>sikulixapi</artifactId>
<version>2.0.4</version>
<exclusions>
<exclusion>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna</artifactId>
</exclusion>
</exclusions>
</dependency>
Thanks
Since you were using spring boot, as suggested here (there's also the reason of this behaviour):
java.lang.NoClassDefFoundError: com/sun/jna/platform/win32/SspiUtil$ManagedSecBufferDesc #882
you can change your order of dependencies, or specify the exact version, like this:
<dependency>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna-platform</artifactId>
<version>5.4.0</version>
</dependency>
or add this property:
<jna.version>5.4.0</jna.version>
My logging dependencies currently look like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-bom</artifactId>
<version>2.9.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.25</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
</dependency>
I noticed that commons-logging.jar is still in my classpath, for some reason. Should I exclude that or doesn't that cause any issues?
I didn't notice any problems so far, but I'm still wondering if that jar would still cause problems somehow.
There are dependencies that use commons-logging. If it's not present, you'll get NoClassDefFoundErrors when they attempt to log. If there were a possibility to have those not even try to use the dependency, it wouldn't be a problem. However that's not very likely.
However, if they use commons-logging but you're using SLF4J, then there's a problem. They're logging in the wrong place (from your point of view). This is where logging bridges come to work. They implement the public API of different logging frameworks, but redirect the logging to what you're using.
For SLF4J there are several bridges (both ways), so instead of bringing in commons-logging, you bring in jcl-over-slf4j. Libraries will think they're using commons-logging, when they're actually using SLF4J (which then uses an actual logging implementation like Logback).
Easy, huh? ;)
Yes, exclude the commons-logging dependency and add the log4j-jcl bridge instead:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
</dependency>
SLF4J API is also redundant because it is already a transitive dependency of the log4j-slf4j-impl binding.
How can I tell Spring-Boot which logging framework to use? (I want to use log4j2).
In 1.1.9.RELEASE I just had a log4j2.xml in my classpath and the logging worked.
Now I upgraded to spring-boot-1.2.0.RELEASE, and my loggers do not work anymore! Maybe I have to configure the logging framework to be used explicit?
I'm using org.apache.logging.log4j.LogManager.getRootLogger() for logging, maybe this is wrong?
See the docs: http://docs.spring.io/spring-boot/docs/current/reference/html/howto-logging.html#howto-configure-log4j-for-logging
Just change the POM
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>
You should be using SFL4J which is a level of abstraction around the actual logging implementation used. if you configure your POM as above, and include the appropriate log4j configuration in src/main/resources, and log using a org.slf4j.Logger then you should be fine
I am using slf4j 1.6.2 api jar (tried using 1.6.1 as well) - logback version is 0.9.29 (core & classic). I am using jdk1.6 on ubuntu. The exception I received is copied below.
Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.arrayFormat(Ljava/lang/String;[Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:112)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:471)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:427)
at ch.qos.logback.classic.Logger.info(Logger.java:631)
I am also getting a message complaining about slf4j binding mismatch.
"SLF4J: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.5.11]"
It very much looks like the version of slf4j-api.jar being loaded by the JVM has version 1.5.x. You surely have slf4j-api-1.5.x.jar on your class path (in addition to slf4j-api-1.6.2.jar). Check your class path.
Adding the following dependencies might help :
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
<version>1.7.7</version>
</dependency>
slf4j-api version does not match that of the binding:
An SLF4J binding designates an artifact such as slf4j-jdk14.jar or slf4j-log4j12.jar used to bind slf4j to an underlying logging framework, say, java.util.logging and respectively log4j.
Mixing different versions of slf4j-api.jar and SLF4J binding can cause problems. For example, if you are using slf4j-api-1.7.2.jar, then you should also use slf4j-simple-1.7.2.jar, using slf4j-simple-1.5.5.jar will not work.
NOTE From the client's perspective all versions of slf4j-api are compatible. Client code compiled with slf4j-api-N.jar will run perfectly fine with slf4j-api-M.jar for any N and M. You only need to ensure that the version of your binding matches that of the slf4j-api.jar. You do not have to worry about the version of slf4j-api.jar used by a given dependency in your project. You can always use any version of slf4j-api.jar, and as long as the version of slf4j-api.jar and its binding match, you should be fine.
At initialization time, if SLF4J suspects that there may be a api vs. binding version mismatch problem, it will emit a warning about the suspected mismatch.
Got from http://www.slf4j.org, I hope it can help.
Also, you must have a many slf4j-api jars of versions mentioned in the []. Try keeping a single version of slf4j-api and the corresponding compatible slf4j-log4j jars in the classpath.
Mixing different versions of slf4j jars will always be troublesome
The NoSuchMethodError is due to the discovery of Methods-with-the-same-name more than once, probably coming from the different versions of the same jars
We have to align the versions of slf4j-api and the corresponding binding, in my case I was using slf4j-log4j12, acording with the documentation of SLF4J:
http://www.slf4j.org/codes.html#version_mismatch
I replace the versions of both libraries included as transitive dependencies, putting in my pom this:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.1</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.1</version>
</dependency>
I hope this help to somebody.
Kind regards,
Jaider
I had the exact same error message. I solved it by excluding the dependency org.apache.directory.server:apacheds-all. Somehow that jar overrides org.slf4j.spi.LocationAwareLogger
This may be more "me too", but I'll try to outline a more complete solution. I mix a lot of software from diverse sources together in my product. I encountered this problem first with NiFi JARs, then more recently with Cassandra JARs all over again. I had already insisted in pom.xml that I have the same version of slf4j everywhere:
<slf4j.version>[1.7.25]</slf4j.version>
...
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>${slf4j.version}</version>
</dependency>
... (all the slf4j JARs I needed)
Then, I told Maven I wanted Cassandra without whatever it was bringing in for slf4j:
<dependency>
<groupId>org.apache.cassandra</groupId>
<artifactId>cassandra-all</artifactId>
<version>${cassandra.version}</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
</exclusion>
</dependency>
However, like you, I was getting complaints from
Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.arrayFormat(Ljava/lang/String;[Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:112)
From mvn dependency:tree, I found out that I was getting logback 1.1.3 which wasn't matching what Cassandra was apparently using (0.9-something like you). So, I excluded getting logback too by adding these exclusions to slf4j ones already there:
<dependency>
<groupId>org.apache.cassandra</groupId>
<artifactId>cassandra-all</artifactId>
<version>${cassandra.version}</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
</exclusion>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
</exclusion>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</exclusion>
</dependency>
...whereupon, the problem I had and you are reporting here, went away. I hope this helps someone.
Download from Below link
https://jar-download.com/artifacts/ch.qos.logback/logback-classic/1.1.3/source-code
all three jars are compatible with each other