My ear application runs well on Tomcat 6 on local window PC, but it cannot run on Weblogic server 10.3.6 on the same PC.
Caused By: java.lang.VerifyError: (class: org/springframework/web/servlet/FrameworkServlet, method: processRequest signature: (Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V) Incompatible argument to function
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
at java.lang.Class.getDeclaredFields(Class.java:1743)
at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.getFields.....
Below is part of my pom.xml which might be related to the problem.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>compile</scope>
</dependency>
From your webapp's /WEB-INF/lib folder, remove all Tomcat-specific libraries like el-ri.jar, el-api.jar. It will make your webapp incompatible with containers of a different make/version resulting in this kind of errors.
For more info clear explanation see here
Possible cause 1:
java.lang.VerifyError can be the result when you have compiled against a different library than you are using at runtime.
Refer here Causes of getting a java.lang.VerifyError
Possible cause 2:
How do I import the javax.servlet API in my Eclipse project?
Specially read this paragraph
You should above all never manually copy/download/move/include the individual servletcontainer-specific libraries like servlet-api.jar, jsp-api.jar, el-api.jar, j2ee.jar, javaee.jar, etc. It would only lead to future portability, compatibility, classpath and maintainability troubles, because your webapp would not work when it's deployed to a servletcontainer of a different make/version than where those libraries are originally obtained from.
Related
I am trying to integrate Azure AD for my web-app using OpenIDConnect approach. When I try to deploy the built ear file on weblogic I get NoClassDefFound for
com.nimbusds.openid.connect.sdk.AuthenticationSuccessResponse
. I have included oauth2-oidc-sdk-5.24.1.jar in the web-inf/lib folder, also verified that it is actually present within the ear file yet the application deployment fails complaining it is not able to find this class.
I found similar issue here. So I tried deploying both oauth2-oidc-sdk-5.24.1.jar and gson jar file as a library along with my java web app, but that did not help as well.
Much appreciated if I can get any pointers or suggestions to overcome this error.
The full stacktrace during deployment:
Caused By: java.lang.NoClassDefFoundError: com/nimbusds/openid/connect/sdk/AuthenticationSuccessResponse
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
at java.lang.Class.getDeclaredMethods(Class.java:1793)
at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.getMethods(BaseJ2eeAnnotationProcessor.java:1055)
at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.getMethods(BaseJ2eeAnnotationProcessor.java:1043)
at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.processJ2eeAnnotations(BaseJ2eeAnnotationProcessor.java:99)
at weblogic.j2ee.dd.xml.J2eeAnnotationProcessor.processJ2eeAnnotations(J2eeAnnotationProcessor.java:37)
at weblogic.servlet.internal.WebAnnotationProcessorImpl.processFilters(WebAnnotationProcessorImpl.java:239)
at weblogic.servlet.internal.WebAnnotationProcessorImpl.processJ2eeAnnotations(WebAnnotationProcessorImpl.java:210)
at weblogic.servlet.internal.WebAnnotationProcessorImpl.processAnnotations(WebAnnotationProcessorImpl.java:105)
at weblogic.servlet.internal.WebAppServletContext.processAnnotations(WebAppServletContext.java:1370)
at weblogic.servlet.internal.WebAppServletContext.<init>(WebAppServletContext.java:450)
at weblogic.servlet.internal.WebAppServletContext.<init>(WebAppServletContext.java:494)
at weblogic.servlet.internal.HttpServer.loadWebApp(HttpServer.java:418)
at weblogic.servlet.internal.WebAppModule.registerWebApp(WebAppModule.java:976)
at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:384)
at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:517)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:159)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:45)
at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:648)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:59)
at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:154)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:208)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747)
at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216)
at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)
#####################################
Update 2021/06/02
To resolve the version compatibility issue, I had to opt below specific versions of dependencies to get it not throw the error for JDK1.6, and microsoft adal4j had to recompiled in JDK6 (adal4j jar is supported on jdk1.7 and above)
<groupId>com.nimbusds</groupId>
<artifactId>nimbus-jose-jwt</artifactId>
<classifier>jdk16</classifier>
<version>5.9</version>
<groupId>com.nimbusds</groupId>
<artifactId>oauth2-oidc-sdk</artifactId>
<classifier>jdk16</classifier>
<version>5.24.1</version>
</dependency>
If the JDK is 1.7, below is the specific versions that worked for me:
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>adal4j</artifactId>
<version>1.6.0</version>
</dependency>
<dependency>
<groupId>com.nimbusds</groupId>
<artifactId>oauth2-oidc-sdk</artifactId>
<version>5.24.1</version>
</dependency>
<dependency>
<groupId>com.nimbusds</groupId>
<artifactId>nimbus-jose-jwt</artifactId>
<version>7.8</version>
</dependency>
Hope this helps someone facing similar error on JDK1.6 and JDK1.7
This is usually caused by incompatible versions. You can try different versions of oauth2-oidc-sdk until you find a compatible package.
Or you can also change the version of spring to achieve the purpose of version compatibility as mentioned in the comments.
I have a maven based project. This is how the project looks like in eclipse:
So I have separate front and back end that are packed into one EAR. The application were deployed on Weblogic 12c server but now I have to move it to Glassfish. I can deploy to Glassfish and my application is running. But, i got an error message when I invoke a method which use Primefaces UploadFile class. This is the error message:
java.lang.NoClassDefFoundError: org/primefaces/model/UploadedFile
javax.ejb.EJBException: java.rmi.ServerError: Error occurred in server thread; nested exception is:
java.lang.NoClassDefFoundError: org/primefaces/model/UploadedFile
This two dependency:
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
<version>1.3.3</version>
</dependency>
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>6.0</version>
</dependency>
Are in both POM.xml (front and back end) And the maven dependency is in my classpath as you can see in this picture:
My question is, where should I put the Primefaces jar, to make visible for Glassfish in runtime?
You'll either need to add the dependencies to the /lib folder of Glassfish as this is where the container will check for them, or bundle them up with the deployable artifact - in your case the .ear file. As you are using maven there are a couple of plugins available that may help you e.g. the Maven Assembly or Maven Ear plugins.
-Answer based on my comment above.
When I run my applicaiton from Eclipse it runs without any errors for servlet api 3.1.0 and 3.0.1.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
I use tomcat 8.0.21 for eclipse. I have set up tomcat8 on ubuntu machine which runs on tomcat 8.0.14 stable version.
Unfortunately, I get the following error message if I use servlet api 3.1.0. But it works for the older version 3.0.1.
root cause
org.apache.jasper.JasperException: Unable to compile class for JSP:
An error occurred at line: [50] in the generated java file: [/var/lib/tomcat8/work/Catalina/localhost/ROOT/org/apache/jsp/WEB_002dINF/view/templates/login_002dtemplate_jsp.java]
The method getDispatcherType() is undefined for the type HttpServletRequest
Stacktrace:
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:103)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:199)
org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:450)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:361)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:336)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:323)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
Why do I get this error? How to fix this?
You're not supposed to provide Servlet API along with the web application archive if the target runtime already provides the API out the box. Tomcat as being a JSP/Servletcontainer already provides JSP, Servlet and EL APIs out the box. When you provide them along with your webapp anyway, then you may run into classloading conflicts caused by duplicate different versioned classes in the runtime classpath coming from both the webapp and the server.
Add <scope>provided</scope> to those dependencies already provided by the target runtime.
See also:
How do I import the javax.servlet API in my Eclipse project?
For Maven users there are several good answers here that you might want to check out.
I'm still in the dark ages, and am not using a dependency manager for my Tomcat project. If you're like me and have this issue, here's how I solved it: It seems tomcat provides the javax.servlet classes, so these don't need to be in your project's lib file. (I originally had the servlet-api-2.5.jar in my /WEB-INF/lib directory.) However you'll probably still need it to compile (I did), so you should move it to a location included in your java classpath. You may also need to tell your IDE where to look.
Hope that helps.
Method ServletRequest#getDispatcherType() was introduced to the Servlet Spec since version 3.0. The following error means that you are using an older version (e.g., 2.5) of javax.servlet-api in your application.
The method getDispatcherType() is undefined for the type HttpServletRequest
To solve this issue, you could follow the following two steps:
First of all, add <scope>provided</scope> to dependency javax.servlet-api
You should add <scope>provided</scope> to the dependency, because your Tomcat container will provide the dependency at runtime. And at the same time, ensure that you are using Tomcat 7 or higher, which supports Servlet Spec 3.0 or higher.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
Second of all, exclude any older version of javax.servlet-api
You need to ensure that any older version (e.g., 2.5) of javax.servlet-api is not included transitively. You can use mvn dependency:tree to find out. See below an example:
$ mvn dependency:tree
...
[INFO] +- com.google.oauth-client:google-oauth-client-servlet:jar:1.20.0:compile
[INFO] | +- com.google.oauth-client:google-oauth-client:jar:1.20.0:compile
[INFO] | +- com.google.http-client:google-http-client-jdo:jar:1.20.0:compile
[INFO] | +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] | \- javax.jdo:jdo2-api:jar:2.3-eb:compile
[INFO] | \- javax.transaction:transaction-api:jar:1.1:compile
...
In this case, javax.servlet-api version 2.5 is included transitively by a dependency called google-oauth-client-servlet. We need to exclude it in pom.xml, like below:
<dependency>
<groupId>com.google.oauth-client</groupId>
<artifactId>google-oauth-client-servlet</artifactId>
<version>1.20.0</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
That's it.
I'm trying to build a mule project in maven which uses a library that in turn uses apache-commons-codec-1.8 . Mule 3.5 currently supports only v 1.3
In order to get around this Ive implemented classloader control in mule and blocked mule from loading its version of the library by doing the following in mule-deploy.properties.
loader.override=-org.apache.commons.codec
In addition I've updated my pom.xml to include the 1.9 version of the library . Here is a snapshot of running mvn:dependency tree on the project.
However, when I run my test method I get a runtime exception
java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.encodeBase64URLSafeString([B)Ljava/lang/String;
at com.nimbusds.jose.util.Base64URL.encode(Base64URL.java:64)
at com.nimbusds.jose.util.Base64URL.encode(Base64URL.java:91)
at com.nimbusds.jose.Header.toBase64URL(Header.java:238)
at com.nimbusds.jose.JWSObject.<init>(JWSObject.java:101)
at com.package.components.lastmile.originator.TokenSignerTemplate.sign(TokenSignerTemplate.java:109)
at com.package.components.lastmile.originator.TokenSignerTemplate.signClaim(TokenSignerTemplate.java:122)
at com.package.orchestration.LMSFakeClaimsHandler.testSignParse_Positive(LMSFakeClaimsHandler.java:120)
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:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
which is clearly because it's referencing the older version of apache-commons. How do I make sure that it references only the latest version and not the older version?
mule-deploy.properties
#Fri Dec 12 09:58:12 PST 2014
loader.override=-org.apache.commons.codec
redeployment.enabled=true
encoding=UTF-8
domain=default
config.resources=..flows.
.
Relevant positions of pom.xml
<dependencies>
....
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.9</version>
</dependency>
....
<!-- Test to check commons-codec works -->
<dependency>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transport-http</artifactId>
<version>${mule.version}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
P.S: The same snippet seems to work fine on a non mule project, indicating this is a mule related issue.
If you are running the Mule app in Mule server, excluding the lib from the pom will not work, since the codec lib is present in the server itself.
Try to insert the newest codec lib version in the server lib shared folder (maintaining the property loader.override=-org.apache.commons.codec)
Add the following exclusion to your pom.
<dependency>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transport-http</artifactId>
<version>${mule.version}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
And then add the dependency of Commons Codec 1.9.
Then your override property in mule-deploy.properties will work as expected.
Update: 12/30:
The override property seems to be the problem.
loader.override=-org.apache.commons.codec is not correct.
Try the following
loader.override=org.apache.commons.codec
Hope this helps.
I have a similar issue with the jackson-xc. I don't know why Mule 3.5 comes with a mix of jackson 1 and 2 libraries
jackson-annotations-2.1.1.jar
jackson-core-2.1.1.jar
jackson-databind-2.1.1.jar
jackson-core-asl-1.9.11.jar
jackson-jaxrs-1.9.11.jar
jackson-mapper-asl-1.9.11.jar
jackson-xc-1.7.1.jar
And with jackson-xc-1.7.1 instead of jackson-xc-1.9.11 that would be aligned to the version of the other jackson 1 libraries.
In my application it is producing the "classic" library issue exception:
Caused by: java.lang.AbstractMethodError
at org.codehaus.jackson.map.AnnotationIntrospector$Pair.findDeserializer(AnnotationIntrospector.java:1335)
Since using
loader.override=...
into the mule-deploy.properties didn't work (with either override and/or blocking on the package org.codehaus.jackson.xc and on the class org.codehaus.jackson.xc.JaxbAnnotationIntrospector) the only solution I have found goes in the direction of Nuno's answer and is to put the jar we want to use in a lib folder with higher priority than lib/opt
lib/shared has been deprecated but you can use lib/user to override.
I would prefer to use the loader.override (classloader-control-in-mule 3.5) and avoid the modification of all the installation, but for now is the only solution that is working for me.
I've developed some code that executes a quartz job.At first the code was outside the tomcat and it executes very well, but when I tried to embed the same code inside a web application I get java.lang.NoClassDefFoundError: org/quartz/DisallowConcurrentExecution.
I'm using quartz 2.1.5 and it's already in the class path.
Here is the stack trace:
Exception in thread "DefaultQuartzScheduler_QuartzSchedulerThread" java.lang.NoClassDefFoundError: org/quartz/DisallowConcurrentExecution
INFO: Illegal access: this web application instance has been stopped already. Could not load org.quartz.DisallowConcurrentExecution. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
at org.quartz.impl.JobDetailImpl.isConcurrentExectionDisallowed(JobDetailImpl.java:390)
java.lang.IllegalStateException
at org.quartz.simpl.RAMJobStore.acquireNextTriggers(RAMJobStore.java:1447)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1273)
at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:264)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
Caused by: java.lang.ClassNotFoundException: org.quartz.DisallowConcurrentExecution
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
at org.quartz.impl.JobDetailImpl.isConcurrentExectionDisallowed(JobDetailImpl.java:390)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
at org.quartz.simpl.RAMJobStore.acquireNextTriggers(RAMJobStore.java:1447)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:264)
make sure you have only 1 quartz-all-.jar in your classpath (maybe you have 2 : 1 in Tomcat lib folder + 1 in your war)
NoClassDefFoundErrors point to a missing JAR or class on the classpath. In this case the problem is likely that in Tomcat you have quartz-<ver>.jar on your classpath when you actually need quartz-all-<ver>.jar.
for them who use maven can use the new version by add
<dependency>
<groupId>org.quartz-scheduler</groupId>
<artifactId>quartz</artifactId>
<version>2.1.7</version>
</dependency>
It should be keep the .jar file inside of the project location. Import .jar file from the outside from the location which the project have is the reason for getting this error. also verified that if the project is a maven project, then it should include the maven dependency in the pom.xml to add the dependency to the project
<dependency>
<groupId>org.quartz-scheduler</groupId>
<artifactId>quartz</artifactId>
<version>2.3.2</version>
</dependency>
<dependency>
<groupId>org</groupId>
<artifactId>quartz_job</artifactId>
<version>2.2.1</version>
</dependency>