We were using axis2 1.7.9 and axiom 1.2.22 in our application along with commons-httpclient 3.1. We tried removing commons-httpclient 3.1 from our application and since commons-httpclient is required by axis2 1.7.9 we had to upgrade axis2 to its latest version 1.8.0 and in process of upgrading axis2 to 1.8.0 we also upgraded axiom to 1.3.0 but when we are running our application we get below error.
org.apache.axiom.soap.SOAPProcessingException: org.apache.axiom.om.impl.llom.OMElementImpl is not allowed as a child of org.apache.axiom.soap.impl.llom.soap11.SOAP11HeaderImpl
at org.apache.axiom.soap.impl.mixin.AxiomSOAPElementSupport.ajc$interMethod$org_apache_axiom_soap_impl_mixin_AxiomSOAPElementSupport$org_apache_axiom_soap_impl_intf_AxiomSOAPElement$checkChild(AxiomSOAPElementSupport.aj:35)
at org.apache.axiom.soap.impl.llom.SOAPElement.checkChild(SOAPElement.java:1)
at org.apache.axiom.om.impl.mixin.AxiomContainerSupport.ajc$interMethod$org_apache_axiom_om_impl_mixin_AxiomContainerSupport$org_apache_axiom_om_impl_intf_AxiomContainer$prepareNewChild(AxiomContainerSupport.aj:160)
at org.apache.axiom.om.impl.llom.OMElementImpl.prepareNewChild(OMElementImpl.java:1)
at org.apache.axiom.om.impl.mixin.AxiomContainerSupport.ajc$interMethodDispatch1$org_apache_axiom_om_impl_mixin_AxiomContainerSupport$org_apache_axiom_om_impl_intf_AxiomContainer$prepareNewChild(AxiomContainerSupport.aj)
at org.apache.axiom.om.impl.mixin.AxiomContainerSupport.ajc$interMethod$org_apache_axiom_om_impl_mixin_AxiomContainerSupport$org_apache_axiom_om_impl_intf_AxiomContainer$addChild(AxiomContainerSupport.aj:166)
at org.apache.axiom.om.impl.llom.OMElementImpl.addChild(OMElementImpl.java:1)
at org.apache.axis2.client.ServiceClient.addHeadersToEnvelope(ServiceClient.java:673)
we checked and found that SOAP11HeaderImpl is child of OMElementImpl.
I am not sure why above exception is thrown.
This should be fixed by https://github.com/apache/ws-axiom/commit/2d9b87f40d3851fbf0f78fe4949190f15a7977ec. There may be a simple workaround (namely to create a SOAPHeaderBlock instead of an OMElement), but unfortunately the stack trace you provided is too short to tell that.
Related
Hi I am having following configuration:
java version-jdk11
server-wildfly16
jars-drools 6.0 and ecj 4.6.1
in server location: C:\wildfly-16.0.0.Final\modules\org\eclipse\jdt\main
I am having jar: jasper-jdt-6.0.29
having an ear.
but after deploying my application opens though when i check rules so drls not working.
below error i am getting..
/servlet/com.fourcs.clm.iwarranty.eclaims.dataview.servlets.ClaimSearchServlet
Path Info:null
Query String:null
Stack Trace:
java.lang.NoSuchFieldError: compilation_beginningToCompile
at deployment.CLMEAR.ear//org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:428)
at deployment.CLMEAR.ear//org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:417)
at deployment.CLMEAR.ear//org.drools.compiler.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:405)
at deployment.CLMEAR.ear//org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
at deployment.CLMEAR.ear//org.drools.compiler.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:405)
at deployment.CLMEAR.ear//org.drools.compiler.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
at deployment.CLMEAR.ear//org.drools.compiler.compiler.PackageRegistry.compileAll(PackageRegistry.java:110)
at deployment.CLMEAR.ear//org.drools.compiler.compiler.PackageBuilder.compileAll(PackageBuilder.java:1334)
at deployment.CLMEAR.ear//org.drools.compiler.compiler.PackageBuilder.compileRules(PackageBuilder.java:1058)
at deployment.CLMEAR.ear//org.drools.compiler.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:972)
I tried upgrading jar version ecj 4.3.1 to 4.6.1 but that also not worked.
How to resolve this error. Any idea?
If you look on the drools usage forums, you can find that Drools does not work with JDK11.
Drools 6 works with JDK7, but that version is from 2013. Latest Drools versions (7.X) work on WildFly 10 to 14 with JDK8.
I’m using the Amazon Java SDK, version 1.11.5 (I included the aws-java-sdk-1.11.5.jar in my WEB-INF/lib directory). What version of the Apache httpclient library do I need to include that is compatible with this version of the AWS SDK? I tried httpclient-4.3.4.jar, but I get the below error
15:34:25,366 ERROR [io.undertow.request] (default task-34) UT005023: Exception handling request to /pluginwiris_engine/app/service: java.lang.NoSuchMethodError: org.apache.http.conn.ssl.SSLConnectionSocketFactory.<init>(Ljavax/net/ssl/SSLContext;Ljavax/net/ssl/HostnameVerifier;)V
at com.amazonaws.http.conn.ssl.SdkTLSSocketFactory.<init>(SdkTLSSocketFactory.java:56)
at com.amazonaws.http.apache.client.impl.ApacheConnectionManagerFactory.getPreferredSocketFactory(ApacheConnectionManagerFactory.java:87)
at com.amazonaws.http.apache.client.impl.ApacheConnectionManagerFactory.create(ApacheConnectionManagerFactory.java:65)
at com.amazonaws.http.apache.client.impl.ApacheConnectionManagerFactory.create(ApacheConnectionManagerFactory.java:58)
at com.amazonaws.http.apache.client.impl.ApacheHttpClientFactory.create(ApacheHttpClientFactory.java:46)
at com.amazonaws.http.apache.client.impl.ApacheHttpClientFactory.create(ApacheHttpClientFactory.java:37)
at com.amazonaws.http.AmazonHttpClient.<init>(AmazonHttpClient.java:213)
at com.amazonaws.AmazonWebServiceClient.<init>(AmazonWebServiceClient.java:145)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:393)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:373)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:355)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:327)
at com.amazonaws.services.s3.AmazonS3Client.<init>(AmazonS3Client.java:309)
Thanks for additional help, - Dave
Looking at the source for the Java AWS SDK, under tag 1.11.5, you can see the in the POM file they have specified the following:
<httpcomponents.httpclient.version>4.5.2</httpcomponents.httpclient.version>
So I'd say HTTP Client version 4.5.2 is compatible with the AWS SDK version 1.11.5. If you are using a dependency management tool like Maven you could always just let it pull in the version of HTTP Client specified the the AWS SDK.
Look at the compile dependencies at maven repo for aws-java-sdk-core
You can see it's dependent on org.apache.httpcomponents » httpclient -- 4.5.2. Further check if you've all the dependencies of httpclient-4.5.2. You might be missing correct version of httpcore
I have created new Play + Scala project using latest typesafe activator and when trying to import in IntelliJ IDE I was getting below error,
info] Loading project definition from E:\Personal\Scala Workspace\DeployZip\project
E:\Personal\Scala Workspace\DeployZip\build.sbt:18: error: not found: value routesGenerator
routesGenerator := InjectedRoutesGenerator
^
[error] Type error in expression
Consult IDE log for more details (Help | Show Log)
What are the possible reasons for this error?
I have installed jdk 1.8 and now I am able to create project successfully without any error.
But when I tried to run play application using
activator run
I was getting below error now,
java.lang.UnsupportedClassVersionError: org/webjars/WebJarExtractor$Cache : Unsupported major.minor version 51.0
According to this article, I think Unsupported major.minor version 51.0 means that your play application were compiled with Java 1.7 (version 51), but you have Java 1.8 (version 52) installed instead, so you got this error. I'd suggest that you refer to this article for how you could switch between different Java versions.
I was having the error that said Unsupported major.minor version 52.0, and after I installed the latest one (Java 1.8) it was solved.
Hope this helps.
Here is what I've done to solve the issue. Even if you install the java 1.8 it is not sufficient. You have to update the 'path' and 'JAVA_HOME'.
After you install, try to set the jdk1.8 path in the PATH of the environment variables. Also make sure that if you have other versions of the java in the PATH then put the jdk 1.8 path prior to the previous version of java. Or just in case put it in the very beginning of the paths.
I had this same issue. Everything worked after I upgraded Intellij to the latest version (maybe my outdated version used JDK1.7, while activator used 1.8?).
I have a grails application with 2.4.1 grails version and used 2.3 groovy compiler.
I am getting following error when I try to run
java.lang.NoSuchMethodError: org.codehaus.groovy.runtime.DefaultGroovyMethods.count(Ljava/lang/Iterable;Lgroovy/lang/Closure;)Ljava/lang/Number;
at org.codehaus.groovy.grails.compiler.web.ControllerActionTransformer.processMethods(ControllerActionTransformer.java:234)
at org.codehaus.groovy.grails.compiler.web.ControllerActionTransformer.performInjectionOnAnnotatedClass(ControllerActionTransformer.java:204)
at org.codehaus.groovy.grails.compiler.web.ControllerActionTransformer.performInjection(ControllerActionTransformer.java:196)
at org.codehaus.groovy.grails.compiler.injection.GrailsAwareInjectionOperation.call(GrailsAwareInjectionOperation.java:154)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1213)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:645)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:623)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:600)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:185)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.analyseCode(GroovyCompilationUnitDeclaration.java:2213)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:834)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:701)
Grails 2.4.1 shipped with Groovy 2.3.3 and that is the only version of Groovy supported with that version of Grails. Normally you don't do anything to associate a version of Groovy with a version of Grails. Grails uses the version that is shipped with it.
Make sure that your GRAILS_HOME points to Grails 2.4.1 and that GRAILS_HOME/bin is on your PATH. If you have a different version of Grails on your PATH than the one that GRAILS_HOME points to, that can sometimes cause peculiar behavior.
I hope that helps.
I'm using RAD 7.5.5. I installed AJDT plugin from the download site:
http://archive.eclipse.org/tools/ajdt/34/update/
I converted one of the existing Java projects to an AspectJ project, added an aspect to print log statements on method start and end of a methodA(), rebuilt the project and deployed.
I'm getting the below exception when methodA() is called:
Exception thrown : java.lang.NoSuchMethodError: org/aspectj/runtime/reflect/Factory.makeMethodSig(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Lorg/aspectj/lang/reflect/MethodSignature;
I googled and found this could be caused because of an older version of aspectjrt.jar. But RAD extends Eclipse 3.4 and hence I added the version of AJDT plugin that is compatible with Eclipse 3.4 (/RAD 7.5.5). Any pointers to what could be the problem?
Make sure that aspectjrt.jar is on your classpath. Also, make sure that it is the aspectjrt.jar that comes with AJDT.