This code
private AlternatorDBClientV2 Client;
#Before
public void setUp() throws Exception {
this.Client = new AlternatorDBClientV2();
}
gives me this exception
java.lang.IllegalStateException: Unrecognized prefix for the AWS http client class name AlternatorDBClientV2
at com.amazonaws.AmazonWebServiceClient.computeServiceName(AmazonWebServiceClient.java:546)
at com.amazonaws.AmazonWebServiceClient.getServiceNameIntern(AmazonWebServiceClient.java:509)
at com.amazonaws.AmazonWebServiceClient.configSigner(AmazonWebServiceClient.java:202)
at com.amazonaws.AmazonWebServiceClient.setEndpoint(AmazonWebServiceClient.java:135)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.setEndpoint(AlternatorDBClientV2.java:273)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.init(AlternatorDBClientV2.java:109)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.<init>(AlternatorDBClientV2.java:96)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.<init>(AlternatorDBClientV2.java:91)
at com.salesfront.test.CreateUserTest.setUp(CreateUserTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
The stack trace line numbers indicate you have configured version 1.6.8 of the AWS Java SDK on your application's pom.xml file.
I reviewed successive Git tags for the AWS Java SDK project which I cloned to my workstation from its GitHub site:
https://github.com/aws/aws-sdk-java
The Alternator project is built and regression tested using version 1.6.4 of the AWS Java SDK.
Since version 1.6.4 of the AWS Java SDK Amazon has been adding logic to auto-detect the data center region and service to connect to based on parsing the endpoint URL and the actual name of the specific sub-class of AmazonWebServiceClient.java
The Alternator emulator clients are just such sub-classes of AmazonWebServiceClient but they do not follow the expected naming conventions.
To use the current version of Alternator you should revise your pom.xml to reference version 1.6.4 of the AWS Java SDK. You can experiment with using version 1.6.5, 1.6.6, or 1.6.7, but definitely 1.6.8 is incompatible with Alternator.
There is a pending Pull Request at the Alternator GitHub repository that resolves this issue.
https://github.com/mboudreau/Alternator/pull/84
Since the original answer, newer versions of Alternator have been created that allow use of higher versions 1.6 and 1.7 of the AWS SDK for Java.
Refer to the Issues and Pull Requests sections of the Alternator GitHub repository:
https://github.com/mboudreau/Alternator
Related
Trying to upgrade the springboot application which uses spring kafka to version 2.9.3 from 2.8.4.
I have followed the instructions here to pulldown kafka-client version 3.2.3 as a separate dependency.
My dependencies looks like this
implementation("org.springframework.kafka:spring-kafka:2.9.3") {
exclude group: "org.apache.kafka", module: "kafka-streams"
exclude group: "org.apache.kafka", module: "kafka-clients"
}
implementation("org.apache.kafka:kafka-clients:3.2.3")
testImplementation("org.springframework.kafka:spring-kafka-test:2.9.3")
When I try to kick off a test which makes use of EmbeddedKafka.
I am getting this NoClassDefFound error
Caused by: java.lang.NoClassDefFoundError: org/apache/kafka/common/requests/AlterIsrRequest$Builder
at kafka.server.KafkaServer.startup(KafkaServer.scala:313)
at kafka.utils.TestUtils$.createServer(TestUtils.scala:177)
at kafka.utils.TestUtils$.createServer(TestUtils.scala:172)
at kafka.utils.TestUtils.createServer(TestUtils.scala)
at org.springframework.kafka.test.EmbeddedKafkaBroker.afterPropertiesSet(EmbeddedKafkaBroker.java:350)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1863)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1800)
... 87 more
Caused by: java.lang.ClassNotFoundException: org.apache.kafka.common.requests.AlterIsrRequest$Builder
at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 94 more
I think I am missing a dependency?
You have a version mis-match between the kafka-clients and other kafka jars. All kafka jars must be the same version since the server uses classes from the clients jar.
I don't see AlterIsrRequest in jars since 3.1.2 - so it looks like, somehow, you have older kafka server jars on the class path.
spring-kafka-test:2.9.3 should pull in 3.2.3 transitively.
Since you are using Spring Boot, it will pull in 3.1.2 instead.
See the documentation (https://docs.spring.io/spring-kafka/docs/2.9.3/reference/html/#update-deps) for how to override the dependencies when using Spring Boot.
I'm using implementation 'com.google.firebase:firebase-perf:19.0.5'
I applied the plugin: apply plugin: 'com.google.firebase.firebase-perf'
and in my project level gradle: classpath 'com.google.firebase:perf-plugin:1.3.1'
I'm running into a few issues.
1) during my build, I see a lot of Can't instrument exceptions like this:
Can't instrument: kotlin/reflect/jvm/internal/impl/load/java/lazy/descriptors/LazyJavaClassMemberScope$nestedClasses$1$enumMemberNames$1.class
java.lang.IllegalArgumentException
at org.objectweb.asm.ClassVisitor.<init>(ClassVisitor.java:79)
at com.google.firebase.perf.plugin.instrumentation.InstrumentationVisitor.<init>(InstrumentationVisitor.java:55)
at com.google.firebase.perf.plugin.instrumentation.Instrument.instrument(Instrument.java:170)
at com.google.firebase.perf.plugin.instrumentation.Instrument.instrumentClassesInJar(Instrument.java:117)
at com.google.firebase.perf.plugin.FirebasePerfTransform.performTransformationFor(FirebasePerfTransform.java:563)
at com.google.firebase.perf.plugin.FirebasePerfTransform.transformJarInputs(FirebasePerfTransform.java:445)
at com.google.firebase.perf.plugin.FirebasePerfTransform.transform(FirebasePerfTransform.java:416)
at com.android.build.gradle.internal.pipeline.TransformTask$2.call(TransformTask.java:239)
at com.android.build.gradle.internal.pipeline.TransformTask$2.call(TransformTask.java:235)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:102)
at com.android.build.gradle.internal.pipeline.TransformTask.transform(TransformTask.java:230)
at sun.reflect.GeneratedMethodAccessor190.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:103)
at
2) I only see logging TraceMetric and no NetworkRequestMetric. the API calls are using Retrofit2, which uses OkHttp3
I had the same issue, and the fix was to move the classpath of the firebase performance before the other plugin that has the dependency to the "org.ow2.asm:asm"(in the project level gradle file).
dependencies {
classpath 'com.google.firebase:perf-plugin:1.3.1'
classpath "org.jacoco:org.jacoco.core:$jacoco_version"
...
}
Firebase plugin uses version 7.0 of the org.ow2.asm:asm
Jacoco plugin uses 5.+ of the org.ow2.asm:asm
To check the versions you can try to use ./gradlew buildEnvironment
https://www.gitmemory.com/issue/gradle/gradle/9650/499815877
Maybe you have the same issue as me.
I have installed cave-repository to Fuse and afterwards I created a new repository. When I try to reach repository via http, I receive the following error from undertow.
NOTE: I did no change to undertow settings. It is a default fuse package.
java.lang.IllegalStateException: UT010026: Async is not supported for
this request, as not all filters or Servlets were marked as supporting
async at
io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:1023)
at
org.apache.karaf.cave.repository.service.maven.MavenServlet.doGet(MavenServlet.java:285)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:645) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:750) at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.ops4j.pax.web.service.undertow.internal.Context$1.lambda$wrap$0(Context.java:615)
at
io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:119)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
I tried the same steps (installing and creating cave repository) in karaf with jetty, and everything works fine there.
During the search in google, I have found the following page in redhat but due to subscription I am not able to see the content.
https://access.redhat.com/solutions/4222431
The problem is that (as I commented under https://ops4j1.jira.com/browse/PAXWEB-1254) Cave's MavenServlet is registered using plain HttpService.registerServlet() without specifying async supported flag. It works with Jetty only by coincidence (doesn't work - as expected - with pax-web-tomcat and pax-web-undertow).
Karaf Cave should either use Pax Web specific WebContainer extension to org.osgi.service.http.HttpService or register the servlet using annotations.
We'll continue the discussion in Karaf/Cave project.
java.lang.IllegalStateException: STREAM
at org.mortbay.jetty.Response.getWriter(Response.java:616)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:187)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:180)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:237)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:173)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:124)
at org.apache.jsp.admin.index_jsp._jspService(org.apache.jsp.admin.index_jsp:415)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:327)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126)
at org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:503)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:306)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
2013-04-03 09:45:39.844:WARN::/solr/admin/
The above is the stacktrace that i get when try to check if solr is running by going to the admin page. I have solr integration module 7.x.1.x-dev for drupal 7 and i am using its schema.xml and solrconfig.xml on Apache Solr 3.2. In the browser, when i request the page it says missing core name in path. What would be wrong ?
Usually try to change the solrconfig.xml or schema.xml in your example/solr/conf dir or it may be related to your version of Java. One of the two most likely.
I am testing JBoss AS 7 prior to deployment with a .war file of an app running in a different server.
I get this error when I try to log onto the database via the app:
SEVERE [] (http--0.0.0.0-8080-4) java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
java.lang.ClassNotFoundException: org.apache.commons.codec.DecoderException from [Module "deployment.app.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at org.apache.commons.httpclient.HttpMethodBase.<init>(HttpMethodBase.java:220)
In some forums, they suggest adding the commons-codec jar, but I already have it in JBoss, right? (in here: jboss-as-7.1.1.Final/modules/org/apache/commons/codec/main/commons-codec-1.4.jar)
OSGi is not activated, frankly I have no idea to what purpose it serves, but when I try to activate it it messes with my war as it fails to deploy...
I have JDK, but no JRE if that's any help.
JBoss AS 7 does not use OSGi by default for modular class loading. It uses JBoss Modules so this has nothing to do with OSGi.
What you need to do if you want to use the commons-codec provided with JBoss AS 7 is add a dependency to your deployment.
Modules are not visible by your artefact classes automatically. You have three possibilities:
Define a global module in your standalone.xml
http://javahowto.blogspot.de/2012/09/how-to-create-global-modules-in-jboss.html
This module will be used by all artefacts you are deploying on Jboss.
Put it into your war artefact, into the lib folder. You can do that with Maven.
Define an explicit dependency within your Manifest. https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7
Section Dependencies: Manifest Entries