Im getting the following error in my quarkus app, but only in integration tests, when the tests are running as part of the maven build and not when running the tests within my IDE (or when running in dev mode).
java.util.ServiceConfigurationError:
org.eclipse.microprofile.context.spi.ThreadContextProvider:
io.quarkus.arc.runtime.context.ArcContextProvider not a subtype
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1236)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1383)
at java.base/java.lang.Iterable.forEach(Iterable.java:74)
at io.smallrye.context.SmallRyeContextManager$Builder.discoverThreadContextProviders(SmallRyeContextManager.java:293)
at io.smallrye.context.SmallRyeContextManager$Builder.build(SmallRyeContextManager.java:333)
at io.smallrye.context.SmallRyeContextManagerProvider.getContextManager(SmallRyeContextManagerProvider.java:48)
at io.smallrye.context.SmallRyeContextManagerProvider.getContextManager(SmallRyeContextManagerProvider.java:37)
at io.smallrye.context.SmallRyeContextManagerProvider.getManager(SmallRyeContextManagerProvider.java:97)
at io.smallrye.context.SmallRyeThreadContext.getCurrentThreadContextOrDefaultContexts(SmallRyeThreadContext.java:160)
at io.smallrye.mutiny.context.DefaultContextPropagationInterceptor.getThreadContext(DefaultContextPropagationInterceptor.java:12)
at io.smallrye.mutiny.context.BaseContextPropagationInterceptor.decorate(BaseContextPropagationInterceptor.java:82)
at io.smallrye.mutiny.infrastructure.Infrastructure.decorate(Infrastructure.java:226)
at io.smallrye.mutiny.groups.UniOnItem.transform(UniOnItem.java:115)
at io.smallrye.mutiny.Uni.map(Uni.java:384)
at ...
This looks like some classloading issue but having a debugger in the build shows that the loaded ThreadContextProvider is assignable from the loaded ArcContextProvider, Is there anything else I should be looking for here? A bit stumped.
Related
I have a java web application secured with OKTA. I have the below code which throws the below exception,
Client client = Clients.builder()
.setOrgUrl((String)SessionUtils.getSession().getAttribute("serverUrl"))
.setClientCredentials(new TokenClientCredentials((String)SessionUtils.getSession().getAttribute("apiKey")))
.build();
When I run it, I get the below error. I have tried adding the jar by going to the buildPath of eclipse project. I am using the below dependencies in my POM and this used to work before when my project had an ANT build. But I started getting this error when I moved to Maven.
java.lang.IllegalStateException: Unable to find a
'com.okta.sdk.impl.http.RequestExecutorFactory' implementation on the
classpath. Please ensure you have added the okta-sdk-httpclient.jar
file to your runtime classpath. at
com.okta.commons.lang.Classes.lambda$loadFromService$0(Classes.java:205)
at java.util.Optional.orElseThrow(Optional.java:290) at
com.okta.commons.lang.Classes.loadFromService(Classes.java:205) at
com.okta.sdk.impl.client.BaseClient.createRequestExecutor(BaseClient.java:103)
at com.okta.sdk.impl.client.BaseClient.(BaseClient.java:72) at
com.okta.sdk.impl.client.AbstractClient.(AbstractClient.java:60)
at
com.okta.sdk.impl.client.DefaultClient.(DefaultClient.java:117)
at
com.okta.sdk.impl.client.DefaultClientBuilder.build(DefaultClientBuilder.java:322)
I could resolve this by using the okta-sdk-httpclient :v1.5.2 to match some of the other OKTA dependencies that I had in my project.
Below are the dependencies that I had in my project prior to the fix.
-okta-authn-sdk-api :v1.0.0
-okta-authn-sdk-impl :v1.0.0
-okta-http-api :v1.2.8
-okta-commons-lang :v1.2.8
-okta-config-check :v1.2.8
-okta-http-okhttp :v1.2.8
-okta-jwt-verifier :v0.5.1
-okta-jwt-verifier-impl:v0.4.0
-okta-sdk :v0.0.4
-okta-sdk-api :v1.5.2
-okta-sdk-httpclient :v6.0.0
-okta-sdk-impl :v1.5.2
I am using Hamcrest Matchers to check if two beans have same property Values. It is working fine in Eclipse but fails when I run using cmd. Following is the stack trace for the same. Can anyone please help?
java.lang.NoSuchFieldError: NONE
at org.hamcrest.DiagnosingMatcher.matches(DiagnosingMatcher.java:12)
at org.hamcrest.beans.SamePropertyValuesAs.hasMatchingValues(SamePropertyValuesAs.java:63)
at org.hamcrest.beans.SamePropertyValuesAs.matchesSafely(SamePropertyValuesAs.java:31)
at org.hamcrest.TypeSafeDiagnosingMatcher.matches(TypeSafeDiagnosingMatcher.java:55)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:12)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
My code is as follows:
assertThat(actualBean, samePropertyValuesAs(expectedBean));
I upgraded my IntelliJ version from 2017.3 to 2018.1 and now I can't run integration tests from the IDE anymore.
The project is a Spring Boot application and build with gradle. The integration tests look basically like this:
#RunWith(SpringRunner.class)
#SpringBootTest(
classes = TestApplication.class,
webEnvironment = SpringBootTest.WebEnvironment.NONE
)
#Transactional
public class MyServiceIT {
#Autowired
private MyService service;
#Test
public void test() {
// ...
}
}
It's still possible to run the test with gradle, but I can't run the isolated test from the IDE.
I get this error, because the instances cannot be autowired anymore:
[INFO] org.springframework.test.context.support.AbstractContextLoader - Could not detect default resource locations for test class [MyServiceIT]: no resource found for suffixes {-context.xml, Context.groovy}.
[INFO] org.springframework.boot.test.context.SpringBootTestContextBootstrapper - Loaded default TestExecutionListener class names from location [META-INF/spring.factories]: [org.springframework.boot.test.autoconfigure.restdocs.RestDocsTestExecutionListener, org.springframework.boot.test.autoconfigure.web.client.MockRestServiceServerResetTestExecutionListener, org.springframework.boot.test.autoconfigure.web.servlet.MockMvcPrintOnlyOnFailureTestExecutionListener, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverTestExecutionListener, org.springframework.security.test.context.support.WithSecurityContextTestExecutionListener, org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener, org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener, org.springframework.test.context.web.ServletTestExecutionListener, org.springframework.test.context.support.DirtiesContextBeforeModesTestExecutionListener, org.springframework.test.context.support.DependencyInjectionTestExecutionListener, org.springframework.test.context.support.DirtiesContextTestExecutionListener, org.springframework.test.context.transaction.TransactionalTestExecutionListener, org.springframework.test.context.jdbc.SqlScriptsTestExecutionListener]
[INFO] org.springframework.boot.test.context.SpringBootTestContextBootstrapper - Using TestExecutionListeners: [org.springframework.test.context.web.ServletTestExecutionListener#309e345f, org.springframework.test.context.support.DirtiesContextBeforeModesTestExecutionListener#56a6d5a6, org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener#18ce0030, org.springframework.test.context.support.DirtiesContextTestExecutionListener#4445629, org.springframework.test.context.transaction.TransactionalTestExecutionListener#45b9a632, org.springframework.test.context.jdbc.SqlScriptsTestExecutionListener#25d250c6, org.springframework.security.test.context.support.WithSecurityContextTestExecutionListener#4df50bcc, org.springframework.boot.test.autoconfigure.restdocs.RestDocsTestExecutionListener#6b26e945, org.springframework.boot.test.autoconfigure.web.client.MockRestServiceServerResetTestExecutionListener#63a65a25, org.springframework.boot.test.autoconfigure.web.servlet.MockMvcPrintOnlyOnFailureTestExecutionListener#54c562f7, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverTestExecutionListener#318ba8c8, org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener#6dbb137d, org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener#3c9d0b9d]
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ...
I worked perfectly with version 2017.1. I think I have to change something in the IDEs configuration but I don't know what.
I'm using Windows 10, IntelliJ 2018.1, Java 1.8 and Spring Boot 1.5.10.RELEASE
Finally, I made it running again. In the Run/Debug Configurations the Working directory was set to $MODULE_DIR$. In my project that did not resolve correctly. After setting the Working directory explicitly to the project root, running specific integration tests worked.
In my experience, in a situation like this, where tests work with Gradle, but not in IntelliJ, it's most of the time because the classes are out of sync. This should be possible to fix by rebuilding the project:
Build -> Rebuild Project
In particularly tenacious cases it might help to additionally clear the caches:
File -> Invalidate Caches / Restart...
You may need to mark src/main/test as the "Test Sources Root".
https://www.jetbrains.com/help/idea/testing.html#add-test-root
Create a test root for your project
Follow these steps if you're building your project with the native
IntelliJ IDEA builder:
In the Project tool window (⌘ 1), right-click the directory in which you want to store your test code and select Mark Directory As |
Test Sources Root.
The tests folder should be marked with the the Tests root icon icon.
I'm working on PAX integration tests for our project and I'm facing few issues with regards to class loading.
I have deployed few bundles in PAX (used karaf container). Once the karaf is up, I could see my bundles and services are up and active. However, in my test cases, I've referred to a Class (not a service nor a component) which will used to during my test execution. The class is resided in the bundle and bundle is up and running successfully, but I'm getting ClassnotFoundError while accessing the class in test case executionas below,
**java.lang.ClassNotFoundException: com.myproject.sample.bundle.DatabaseConfig
at** org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at com.integrationtest.testcases.internal.development.LaunchContainerTest.populateDBProfiles(LaunchContainerTest.java:189)
at com.integrationtest.testcases.internal.development.LaunchContainerTest.testLaunchOSGiContainerWithDefualtSettingsAndSleep(LaunchContainerTest.java:152)
Failed tests:
LaunchContainerTest.testLaunchOSGiContainerWithDefualtSettingsAndSleep:152->populateDBProfiles:189
▒ ClassNotFound
Is it something to do with the container?
As your test itself will also run within the OSGi context you need to adapt your test. The dynamically generated test bundle needs to know that it needs to import the class in question.
For this you can add a specialized probe configuration method. Like the following below:
#ProbeBuilder
public TestProbeBuilder probeConfiguration(TestProbeBuilder probe) {
//make sure the needed imports are there.
probe.setHeader(Constants.IMPORT_PACKAGE, "*,com.myproject.sample.bundle.*");
return probe;
}
I have a RESTful service created using Spring MVC. I created an integration test to test my Rest controller, using spring-test mvcmock.
When I am running this test using run as Junit. It is running fine.
However, when the same test is getting executed during mvn install, using surefire plugin. This test is complaining throwing fatal error:
No qualifying bean of type ...
When I checked previous logs it says that it loaded 0 dependecy.
This was the log :
DEBUG XmlBeanDefinitionReader - Loaded 0 bean definitions from location pattern [classpath*:service-test-context.xml]
However, I again run this test class as Junit and I could see "loaded 23 beans at the same log line."
Question: Could you please suggest, what can be the issue?
Note:
This is multi maven module application and dependency of another module is not getting injected.
I was getting same issue, when I was running this test as Junit. Then I added dependent modules in eclipse > build > project and issue got resolved in run as JUnit. Now getting this issue while doing mvn install.
Does your surefire configuration contain an includes parameter?
"A list of elements specifying the tests (by pattern) that should be included in testing. When not specified and when the test parameter is not specified, the default includes will be
<includes>
<include>**/Test*.java</include>
<include>**/*Test.java</include>
<include>**/*TestCase.java</include>
</includes>
"
Easy fix is to rename your test runner so that it ends in Test.java. Then
mvn test
will pick it up.
Updated
An alternative is this:
"test:
Specify this parameter to run individual tests by file name, overriding the includes/excludes parameters. Each pattern you specify here will be used to create an include pattern formatted like **/${test}.java, so you can just type "-Dtest=MyTest" to run a single test called "foo/MyTest.java". The test patterns prefixed with a ! will be excluded.
This parameter overrides the includes/excludes parameters, and the TestNG suiteXmlFiles parameter. Since 2.7.3, you can execute a limited number of methods in the test by adding #myMethod or #my*ethod. For example, "-Dtest=MyTest#myMethod". This is supported for junit 4.x and testNg.
Since 2.19 a complex syntax is supported in one parameter (JUnit 4, JUnit 4.7+, TestNG):
"-Dtest=???Test, !Unstable*, pkg/**/Ci*leTest.java, Test#testOne+testTwo?????, #fast*+slowTest"
"-Dtest=Basic*, !%regex[..Unstable.], !%regex[..MyTest.class#one.|two.], %regex[#fast.|slow.*]"
The Parameterized JUnit runner describes test methods using an index in brackets, so the non-regex method pattern would become: #testMethod[]. If using #Parameters(name="{index}: fib({0})={1}") and selecting the index e.g. 5 in pattern, the non-regex method pattern would become #testMethod[5:].
Type: java.lang.String
Required: No
User Property: test
"
So if your test runner was named foo/MyVeryOwnRunner.java you could do the following
mvn clean test -Dtest=MyVeryOwnRunner