When using org.jboss.resteasy:resteasy-client:4.5.9.Final, I'm getting this exception: Caused by: java.lang.IncompatibleClassChangeError: Expected static method 'java.lang.Object org.jboss.resteasy.spi.ResteasyProviderFactory.getContextData(java.lang.Class)'
However, when I use an earlier version, it seems to work fine. (Or at least it works well enough to fool me.)
Here's my simplified pom:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.example</groupId>
<artifactId>example-project</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<maven.compiler.source>15</maven.compiler.source>
<maven.compiler.target>15</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<keycloak.version>12.0.4</keycloak.version>
<!-- Seems to work with this version, but not 4.5.9.Final -->
<resteasy.version>3.6.2.Final</resteasy.version>
</properties>
<dependencies>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-admin-client</artifactId>
<version>${keycloak.version}</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-client</artifactId>
<version>${resteasy.version}</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jackson2-provider</artifactId>
<version>${resteasy.version}</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-multipart-provider</artifactId>
<version>${resteasy.version}</version>
</dependency>
</dependencies>
</project>
And here's my code:
package org.example.keycloak;
import org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder;
import org.keycloak.OAuth2Constants;
import org.keycloak.admin.client.Keycloak;
import org.keycloak.admin.client.KeycloakBuilder;
public class KeycloakClientAuthExample {
public static void main(String[] args) {
Keycloak keycloak = KeycloakBuilder.builder()
.serverUrl("http://localhost:8080/auth")
.grantType(OAuth2Constants.PASSWORD)
.realm("DungeoneersDemo")
.clientId("dungeoneers-data")
.clientSecret("11111111-2222-3333-4444-555555555555")
.username("user")
.password("pass")
.resteasyClient(
// new ResteasyClientBuilderImpl() // <-- For 4.5.9.Final
new ResteasyClientBuilder()
.connectionPoolSize(10).build()
).build();
keycloak.tokenManager().getAccessToken();
AccessTokenResponse atr =
keycloak.tokenManager().getAccessToken();
System.out.println(atr.getToken());
}
}
Seems to work and I get what looks enough to me like a bearer token: eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI2bWhhWUQ..etc...
However, when I update my resteasy.version to the a later version✳ (4.5.9.Final), I get an error:
Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: RESTEASY003940: Unable to instantiate MessageBodyReader
at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(RegisterBuiltin.java:78)
at org.jboss.resteasy.plugins.providers.RegisterBuiltin.getClientInitializedResteasyProviderFactory(RegisterBuiltin.java:54)
at org.jboss.resteasy.client.jaxrs.internal.ResteasyClientBuilderImpl.getProviderFactory(ResteasyClientBuilderImpl.java:372)
at org.jboss.resteasy.client.jaxrs.internal.ResteasyClientBuilderImpl.build(ResteasyClientBuilderImpl.java:390)
at org.sandbox.security.openidc.keycloak.KeycloakClientAuthExample.main(KeycloakClientAuthExample.java:22)
Caused by: java.lang.RuntimeException: RESTEASY003940: Unable to instantiate MessageBodyReader
at org.jboss.resteasy.core.providerfactory.CommonProviders.processProviderContracts(CommonProviders.java:93)
at org.jboss.resteasy.core.providerfactory.ClientHelper.processProviderContracts(ClientHelper.java:104)
at org.jboss.resteasy.core.providerfactory.ResteasyProviderFactoryImpl.processProviderContracts(ResteasyProviderFactoryImpl.java:841)
at org.jboss.resteasy.core.providerfactory.ResteasyProviderFactoryImpl.registerProvider(ResteasyProviderFactoryImpl.java:829)
at org.jboss.resteasy.core.providerfactory.ResteasyProviderFactoryImpl.registerProvider(ResteasyProviderFactoryImpl.java:816)
at org.jboss.resteasy.plugins.providers.RegisterBuiltin.registerProviders(RegisterBuiltin.java:109)
at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(RegisterBuiltin.java:74)
... 4 more
Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.jboss.resteasy.plugins.providers.jaxb.JAXBElementProvider()
at org.jboss.resteasy.core.ConstructorInjectorImpl.constructOutsideRequest(ConstructorInjectorImpl.java:250)
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:209)
at org.jboss.resteasy.core.providerfactory.Utils.createProviderInstance(Utils.java:102)
at org.jboss.resteasy.core.providerfactory.CommonProviders.processProviderContracts(CommonProviders.java:87)
... 10 more
Caused by: java.lang.IncompatibleClassChangeError: Expected static method 'java.lang.Object org.jboss.resteasy.spi.ResteasyProviderFactory.getContextData(java.lang.Class)'
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider.<init>(AbstractJAXBProvider.java:52)
at org.jboss.resteasy.plugins.providers.jaxb.JAXBElementProvider.<init>(JAXBElementProvider.java:46)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
at org.jboss.resteasy.core.ConstructorInjectorImpl.constructOutsideRequest(ConstructorInjectorImpl.java:225)
... 13 more
Process finished with exit code 1
✳ Note: When upgrading to the later version, ResteasyClientBuilder was abstracted and the constructor call needed to be replaced with new ResteasyClientBuilderImpl().
I was typing out my question and, while looking into it one last time before submitting, I found the issue and figured I'd throw it out there just in case someone else has this issue.
It turns out that there is another resteasy dependency that needed to be pulled in because, otherwise, an old version is pulled in. When using the newer version of resteasy-client, the other dependency being pulled in was org.jboss.resteasy:resteasy-jaxb-provider:3.9.1.Final. I added the newer version to my pom (org.jboss.resteasy:resteasy-jaxb-provider:4.5.9.Final) and everything seems to now work.
Not sure why this is the case. I would think if the dependency was being pulled in anyway by resteasy-client, it should've been pulling in the same version.
We were facing the same issue and your reply really helped to find out the mistake. To let other users check the error in detail, further details are:
KC 15.* and KC16.1 uses, in their main pom.xml, resteasy version 3.*
<resteasy.version>3.15.1.Final</resteasy.version>
<resteasy.undertow.version>${resteasy.version}</resteasy.undertow.version>
When you check the version for the container in the server, you can see that, from KC16, the new Widlfly server uses resteasy v4.*
This concept causes a difference in the jars, while it has the behavior to have scope provided (but is not). As you mentioned, the solution to that is the following.
<properties>
<resteasy.version>4.5.9.Final</resteasy.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-client</artifactId>
<version>${resteasy.version}</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jackson2-provider</artifactId>
<version>${resteasy.version}</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-multipart-provider</artifactId>
<version>${resteasy.version}</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxb-provider</artifactId>
<version>${resteasy.version}</version>
</dependency>
</dependencies></dependencyManagement>
This will force 3 main API changes to consider:
final ResteasyClient client = new ResteasyClientBuilder()
.disableTrustManager()
.socketTimeout(60, TimeUnit.SECONDS)
.establishConnectionTimeout(10, TimeUnit.SECONDS)
/// will need to change to the new methods:
final ResteasyClient client = new ResteasyClientBuilderImpl()
.disableTrustManager()
.readTimeout(60, TimeUnit.SECONDS)
.connectTimeout(10, TimeUnit.SECONDS)
And also this change:
HttpServletResponse contextData = ResteasyProviderFactory.getContextData(HttpServletResponse.class);
//Change to
ResteasyProviderFactory resteasyProviderFactory = ResteasyProviderFactoryImpl.getInstance();
HttpServletResponse contextData = resteasyProviderFactory.getContextData(HttpServletResponse.class);
You r previous reply help us to understand under the hood the problem, but, anyway, users shall have more info. See the image bellow as a running KC16 container showing all related libs
Related
I use an embedded Jetty (11.0.13) server with Jersey (3.1.0) that provides a simple REST interface which returns JSON objects. The JSON objects are serialized using Jackson.
The setup works fine as long as I don´t use Java´s module system.
But when I add the module-info.java file (see below), I get the following error as soon as I call the service.
WARNING: The following warnings have been detected: WARNING: Unknown HK2 failure detected:
MultiException stack 1 of 2
java.lang.NoClassDefFoundError: jakarta/xml/bind/annotation/XmlElement
at com.fasterxml.jackson.module.jakarta.xmlbind.JakartaXmlBindAnnotationIntrospector.<init>(JakartaXmlBindAnnotationIntrospector.java:137)
...
Caused by: java.lang.ClassNotFoundException: jakarta.xml.bind.annotation.XmlElement
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 83 more
MultiException stack 2 of 2
java.lang.IllegalStateException: Unable to perform operation: post construct on org.glassfish.jersey.jackson.internal.DefaultJacksonJaxbJsonProvider
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:429)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:466)
...
To make it work, I have to add the JAX-B-API to the pom.xml and to the module-info.java.
The error only occurs when using Java modules. When I simply delete the module-info.java file, everythink works fine even without the JAX-B dependency.
This is the point where I am really confused. Why do I need the JAX-B dependency when I use the module system, but not when I don´t use it? And why does the ClassNotFoundException even occur? Shouldn´t warn the module system about missing dependencies on startup?
I hope someone can explain that. It took me days to make it work.
This is the setup that produces the issue:
pom.xml
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>demo</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.source>17</maven.compiler.source>
</properties>
<dependencies>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
<version>11.0.13</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlet</artifactId>
<version>11.0.13</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>3.1.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.inject</groupId>
<artifactId>jersey-hk2</artifactId>
<version>3.1.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>3.1.0</version>
</dependency>
</dependencies>
</project>
Main.java
public class Main {
public static void main(String[] args) throws Exception {
Server server = new Server(8080);
server.setStopAtShutdown(true);
ServletContextHandler context = new ServletContextHandler(server, "/");
ServletHolder servletHolder = context.addServlet(ServletContainer.class, "/*");
servletHolder.setInitParameter("jersey.config.server.provider.packages", "com.example.demo");
servletHolder.setInitParameter("jersey.config.server.wadl.disableWadl", "true");
server.start();
}
}
DemoResource.java
#Path("/hello")
public class DemoResource {
#GET
#Produces("application/json")
public HelloDto hello() {
return new HelloDto("Hello, World!");
}
public record HelloDto(String value) {
#JsonGetter("value")
public String value() {
return this.value;
}
}
}
module-info.java
module demo {
requires org.eclipse.jetty.server;
requires org.eclipse.jetty.servlet;
requires jersey.container.servlet.core;
requires jakarta.ws.rs;
requires com.fasterxml.jackson.annotation;
}
This is the standard JVM behavior of classpath (old school Java) and modulepath (new school Java Platform Module System, aka JPMS).
Once you have a module-info.class you have a modulepath active, and all of the access rules it has.
Your runtime can have both at the same time, and this is quite normal.
Don't rely on old school classpath to get around bad code and bad behavior, use JPMS and module-info.class and you'll know what the developers of those projects jars intend for you to use (you won't be allowed to use internal classes for example, as those are highly volatile and can change at a moments notice).
jakarta.xml.bind is required by HK2 to operate, so you have to declare it in your build dependencies to just compile, and then your module-info.java to be able to access it.
Check the other answers here on Stackoverflow for advice on how to use module-info.java properly (there's far more to it than just requires <module>).
I'm upgrading from elasticsearch 7 client to 8 and trying to stop using the deprecated RestHighLevelClient. The issue is that in one of the modules i am having BulkProcessor, and i can't figure out how I can use it with the new clients library, since none of them is compatible.
public static Builder builder(Client client, Listener listener, Scheduler flushScheduler, Scheduler retryScheduler, Runnable onClose) {
Objects.requireNonNull(client, "client");
Objects.requireNonNull(listener, "listener");
return new Builder(client::bulk, listener, flushScheduler, retryScheduler, onClose);
}
The builder above expects package org.elasticsearch.client.internal.Client and i don't find any implementation i can use in any of the dependencies below:
<dependency>
<groupId>co.elastic.clients</groupId>
<artifactId>elasticsearch-java</artifactId>
<version>8.3.2</version>
</dependency>
<dependency>
<groupId>org.elasticsearch.client</groupId>
<artifactId>elasticsearch-rest-client</artifactId>
<version>8.3.2</version>
</dependency>
<dependency>
<groupId>org.elasticsearch</groupId>
<artifactId>elasticsearch</artifactId>
<version>8.3.2</version>
</dependency>
Am i missing something?
Thank you!
We are using a library called logback-ext-cloudwatch-appender to send our logback-based logs to AWS Cloudwatch. This is what the dependency looks like in our pom.xml file.
<dependency>
<groupId>org.eluder.logback</groupId>
<artifactId>logback-ext-cloudwatch-appender</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
A few days ago these errors started appearing in our logs.
java.lang.NoSuchMethodError: com.amazonaws.transform.JsonErrorUnmarshaller: method <init>(Ljava/lang/Class;)V not found
at com.amazonaws.services.logs.model.transform.InvalidParameterExceptionUnmarshaller.<init>(InvalidParameterExceptionUnmarshaller.java:26)
at com.amazonaws.services.logs.AWSLogsClient.init(AWSLogsClient.java:280)
at com.amazonaws.services.logs.AWSLogsClient.<init>(AWSLogsClient.java:275)
at com.amazonaws.services.logs.AWSLogsClient.<init>(AWSLogsClient.java:248)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.doStart(AbstractCloudWatchAppender.java:100)
at org.eluder.logback.ext.aws.core.AbstractAwsEncodingStringAppender.start(AbstractAwsEncodingStringAppender.java:123)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.start(AbstractCloudWatchAppender.java:95)
at ch.qos.logback.ext.spring.DelegatingLogbackAppender.getDelegate(Unknown Source)
at ch.qos.logback.ext.spring.DelegatingLogbackAppender.append(Unknown Source)
at ch.qos.logback.ext.spring.DelegatingLogbackAppender.append(Unknown Source)
at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84)
at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48)
at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383)
at ch.qos.logback.classic.Logger.info(Logger.java:579)
(truncated)
I found out that we had upgraded to AWS 1.11.5, but I couldn't find any evidence of such a bug in that release.
It turns out that the current version of logback-ext-cloudwatch-appender has a transitive dependency on a specific version of aws-java-sdk-logs 1.10.2, which is not compatible with other aws-java-sdk libraries 1.11.0 and above. We do use a number of other aws-java-sdk libraries. We excluded the dependency like this.
<dependency>
<groupId>org.eluder.logback</groupId>
<artifactId>logback-ext-cloudwatch-appender</artifactId>
<version>1.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-logs</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-core</artifactId>
<version>1.11.5</version>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-logs</artifactId>
<version>1.11.5</version>
</dependency>
At that point we started getting another error.
Exception in thread "org.myorg.task.MyTask working" java.lang.NoSuchMethodError: com.amazonaws.services.logs.AWSLogsClient.createLogGroup(Lcom/amazonaws/services/logs/model/CreateLogGroupRequest;)V
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.createLogGroup(AbstractCloudWatchAppender.java:171)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.doStart(AbstractCloudWatchAppender.java:107)
at org.eluder.logback.ext.aws.core.AbstractAwsEncodingStringAppender.start(AbstractAwsEncodingStringAppender.java:123)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.start(AbstractCloudWatchAppender.java:95)
at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:90)
at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179)
at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:155)
at ch.qos.logback.core.sift.SiftingJoranConfiguratorBase.doConfigure(SiftingJoranConfiguratorBase.java:82)
at ch.qos.logback.core.sift.AbstractAppenderFactoryUsingJoran.buildAppender(AbstractAppenderFactoryUsingJoran.java:51)
at ch.qos.logback.core.sift.AppenderTracker.buildComponent(AppenderTracker.java:56)
at ch.qos.logback.core.sift.AppenderTracker.buildComponent(AppenderTracker.java:32)
at ch.qos.logback.core.spi.AbstractComponentTracker.getOrCreate(AbstractComponentTracker.java:124)
at ch.qos.logback.core.sift.SiftingAppenderBase.append(SiftingAppenderBase.java:104)
at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:82)
at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48)
at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383)
at ch.qos.logback.classic.Logger.info(Logger.java:579)
Merely excluding the dependencies did not work. I had to fork and rebuild the logback-ext-cloudwatch-appender jar with a dependency on the current 1.11.5 aws-java-sdk libraries. Trying to use the new AWS dependencies with the logback-ext-cloudwatch-appender jar which had been built against the old libraries caused a mismatch in the method signature (return type) of createLogGroup which caused a runtime error. To get this to run, I only had to change the pom.xml files, not the source code, in my forked version.
I have done previous searches trying to find an answer to this however my attempts failed so far. I think the error is quite simple its just not loading the classes.
I am running MacOSX 10 with intellij. I am using it with Junit Spring and Maven & Junit.
I followed the maven dependencies found mvnrepository.com - sikuli-api 1.2.0 so I was thinking that if the dependencies are added to the pom then all files should be in my class path? So I don't understand why its not working?
This previous answer looks close to mine - but its for windows im on a mac. However by using maven I should not need to add it to the class path?? or am I missing something. This similar unanswered question also looks similar uses mac like mine
POM Dependencies added
<dependency>
<groupId>org.sikuli</groupId>
<artifactId>sikuli-api</artifactId>
<version>1.2.0</version>
</dependency>
<dependency>
<groupId>org.sikuli</groupId>
<artifactId>sikuli-core</artifactId>
<version>1.2.2</version>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>14.0.1</version>
</dependency>
<dependency>
<groupId>org.bytedeco</groupId>
<artifactId>javacpp</artifactId>
<version>0.9</version>
</dependency>
<dependency>
<groupId>org.bytedeco.javacpp-presets</groupId>
<artifactId>opencv</artifactId>
<version>2.4.9-0.9</version>
<classifier>macosx-x86_64</classifier>
</dependency>
<dependency>
<groupId>org.piccolo2d</groupId>
<artifactId>piccolo2d-core</artifactId>
<version>1.3.1</version>
</dependency>
<dependency>
<groupId>org.piccolo2d</groupId>
<artifactId>piccolo2d-extras</artifactId>
<version>1.3.1</version>
</dependency>
My test
static {
System.setProperty("platform.dependency", "macosx-x86_64");
//System.setProperty("platform.dependency", "1"); // tried this also
}
#Test
public void testOne() throws Exception {
File file = new File(getClass().getClassLoader().getResource("camera_icon.png").getFile());
browse(new URL("http://code.google.com"));
ScreenRegion s = new DesktopScreenRegion();
Target target = new ColorImageTarget(file);
// ** Fails here **
ScreenRegion r = s.find(target);
....
The Error - ClassLoader
I followed the debugger and it fails on the class loader for open_core -- see screenshot
Update
I added the POM classifier per Samuel answer below. I also tried setting the system property. still getting the same error.
Also noticed the following error - I have tried to cut it down as much as possible.
Caused by: java.lang.UnsatisfiedLinkError: /private/var/folders/qp/.../libjniopencv_core.dylib: dlopen(/private/var/....../libjniopencv_core.dylib, 1): Library not loaded: #rpath/libopencv_core.2.4.dylib
Referenced from: /private/var/.......libjniopencv_core.dylib
Reason: no suitable image found. Did find:
/private/va.....77/./libopencv_core.2.4.dylib: malformed mach-o image: load command #12 length (0) too small in /private/var/fo......./libopencv_core.2.4.dylib t java.lang.ClassLoader$NativeLibrary.load(Native Method)
The answer is basically in the README.md file, but I'll spell it out here. You will need to set either the platform.dependency system property to the desired platform, for example, macosx-x86_64, or to true the platform.dependencies one, to get dependencies for all platforms. I'm not sure how we're supposed to set that with JUnit Spring (it should be in the docs), but even that doesn't work with SBT anyway, so to work around these cases we can add the platform-specific dependencies manually. Since you're running on Mac OS X and interested in using OpenCV 2.4.9, adding this additional dependency to your pom.xml file should work:
<dependency>
<groupId>org.bytedeco.javacpp-presets</groupId>
<artifactId>opencv</artifactId>
<version>2.4.9-0.9</version>
<classifier>macosx-x86_64</classifier>
</dependency>
For my work around I install opencv via homebrew. Open terminal and type the following.
brew tap homebrew/science
brew info opencv
brew install opencv
This allowed my POM to be much smaller
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>sikuliTest</groupId>
<artifactId>sikuliTest</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.sikuli</groupId>
<artifactId>sikuli-api</artifactId>
<version>1.2.0</version>
</dependency>
</dependencies>
</project>
The test
#Test
public void testOne() throws IOException {
File file = new File(getClass().getClassLoader().getResource("image_to_click.jpeg").getFile());
browse(new URL("http://code.google.com"));
// click image that looks like image_to_click.jpeg
ScreenRegion s = new DesktopScreenRegion(1);
ScreenRegion s1 = s.find(new ImageTarget(file));
Mouse mouse = new DesktopMouse();
mouse.click(s1.getCenter());
// take a screenshot and save it
BufferedImage img = s.capture();
File outputfile = new File("screenshot_image.jpg");
ImageIO.write(img, "jpg", outputfile);
}
I am using spring-data-elasticsearch version using 1.3.0.BUILD-SNAPSHOT
The following code was working fine until a few weeks ago. Suddenly it started giving me an exception. I have tried giving basePackages instead of value..
/* We will require this at the point of deployment */
#EnableElasticsearchRepositories(basePackages = "com/rentomoney/rom/server/data/search/repository")
#Configuration
public class ROMElasticSearchConfig {
....
}
OR
#EnableElasticsearchRepositories( "com.rentomoney.rom.server.data.search.repository")
#Configuration
public class ROMElasticSearchConfig {
....
}
Here is the exception that is being generated:
nested exception is java.lang.annotation.AnnotationFormatError:
Invalid default: public abstract java.lang.Class
org.springframework.data.elasticsearch.repository.config.EnableElasticsearchRepositories.repositoryBaseClass()
at
org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:70)
at
org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
at
org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:76)
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.importBeanDefinitionResource(DefaultBeanDefinitionDocumentReader.java:261)
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseDefaultElement(DefaultBeanDefinitionDocumentReader.java:186)
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:171)
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:144)
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:100)
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:510)
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:392)
The error is a bit cryptic, but it really means that it cannot find the default DefaultRepositoryBaseClass class due to a missing dependency.
Signature for repositoryBaseClass in EnableElasticsearchRepositories annotation:
Class<?> repositoryBaseClass() default DefaultRepositoryBaseClass.class;
If you are using SNAPSHOT versions, you'll need to have the SNAPSHOT repository configured along with any required SNAPSHOT dependencies that the jar doesn't include. Make sure you have the following in your POM file:
Repositories:
<repository>
<id>spring-snapshot</id>
<name>Spring Maven SNAPSHOT Repository</name>
<url>http://repo.springsource.org/libs-snapshot</url>
</repository>
Dependencies:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-commons</artifactId>
<version>1.11.0.BUILD-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-elasticsearch</artifactId>
<version>1.3.0.BUILD-SNAPSHOT</version>
</dependency>
That solved the issue for me.
First of all its not suggested to use snapshot version unless you are using it for new feature testing. (i.e 1.3.0.BUILD-SNAPSHOT in your case)
The current stable and released version for spring data elasticsearch is
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-elasticsearch</artifactId>
<version>1.2.0.RELEASE</version>
</dependency>
Second about your question getting error for #EnableElasticsearchRepositories, it could be related to this (DATAES-136) recent commit to the project.
Share some more information / code if problem persist