I am using weblogic 10.3.6.0 application server for deploying application . after
deploying one of the application which uses JDK8. at run time I got the following error.
java.lang.NoSuchMethodError: javax.servlet.http.Cookie.setHttpOnly(Z)V
contents of dependencies.gradle file are as follows
providedCompile 'javax.servlet:javax.servlet-api:3.0.1'
What would be the reason behind this error?
Cookie.setHttpOnly() is available since Servlet 3.0. You are deploying to WebLogic 10 which provides only Servlet 2.5.
Note that your project is compiling against an API dependency and not the actual runtime implementation. This is correct project setup, don't change it. However you must ensure that the APIs that you selected for compilation are provided in the runtime by deploying to the correct server.
As others have said, you are compiling against the wrong servlet jar for your version of weblogic. If you want to keep using weblogic 10 then you should change to
providedCompile 'javax.servlet:javax.servlet-api:2.5'
Once you do this I'm guessing you'll get a compilation error for Cookie.setHttpOnly().
Out of interest, why are you using weblogic? There's many free / open source servlet containers that are far better than weblogic. Weblogic doesn't conform to the same standards as the rest of the servlet containers.
Related
I am trying to migrate my application server (JBOSS EAP) from 6.4 to 7.4.3. But, after migration I am getting the below error during my spring boot microservice deployment time.
Caused By: java.lang.NoClassDefFoundError: org/apache/tomcat/util/res/StringManager
Thus, after doing some research I have removed couple of essential tomcat dependencies(tomcat-embed-el-9.0.58 and tomcat-embed-websocket-9.0.58 from my maven pom and the deployment time issue has resolved. Now, I can deploy my application in my new local JBOSS EAP 7.4.3 server. But, the above mentioned two dependencies are essential and we can't exclude that as per our upper environment configuration.
Could you please give me some solutions except the above one(means without removing the tomcat dependencies) if you have faced this issue before. Thank you all!
Regards,
Ritesh
EAP 7.4 is using Undertow and not Tomcat so Tomcat classes aren't available.
also it is really a bad practice to depend on spec implementations internal in your code. The fix would be to remove all usage of that Tomcat class or make it part of your application.
I am using fabric-sdk-java client to interact with my Hyperledger Fabric V1.0 network setup locally. Everything is working fine when running the client as standalone java application. But when I am using the same within the application.ear which is deployed in Weblogic 12c server, I am getting the following exception
Caused by: java.lang.NoSuchMethodError: com.google.common.util.concurrent.MoreExecutors.platformThreadFactory()Ljava/util/concurrent/ThreadFactory;
at io.grpc.internal.GrpcUtil.getThreadFactory(GrpcUtil.java:482)
at io.grpc.internal.GrpcUtil$1.create(GrpcUtil.java:421)
at io.grpc.internal.GrpcUtil$1.create(GrpcUtil.java:417)
at io.grpc.internal.SharedResourceHolder.getInternal(SharedResourceHolder.java:104)
at io.grpc.internal.SharedResourceHolder.get(SharedResourceHolder.java:74)
at io.grpc.internal.SharedResourcePool.getObject(SharedResourcePool.java:35)
at io.grpc.internal.ManagedChannelImpl.<init>(ManagedChannelImpl.java:383)
at io.grpc.internal.AbstractManagedChannelImplBuilder.build(AbstractManagedChannelImplBuilder.java:331)
at org.hyperledger.fabric.sdk.OrdererClient.sendDeliver(OrdererClient.java:220)
at org.hyperledger.fabric.sdk.Orderer.sendDeliver(Orderer.java:172)
at org.hyperledger.fabric.sdk.Channel.seekBlock(Channel.java:1198)
at org.hyperledger.fabric.sdk.Channel.getLatestBlock(Channel.java:1274)
at org.hyperledger.fabric.sdk.Channel.getLastConfigIndex(Channel.java:1097)
at org.hyperledger.fabric.sdk.Channel.getConfigurationBlock(Channel.java:1028)
at org.hyperledger.fabric.sdk.Channel.parseConfigBlock(Channel.java:949)
at org.hyperledger.fabric.sdk.Channel.initialize(Channel.java:676)
......
Since all of these dependencies are inside fabric-sdk-java I am not sure where to do its fix. I had seen some post telling it is the issue with guava version. fabric-sdk-java having the dependency with guava version 19.
I don't understand why it is working while running as standalone java application, but this issues coming after deploying in Weblogic 12c server.
Do I need to add anything more to work this in Weblogic 12c server?
99% of such exceptions are caused by mismatched versions. For example, the method was not present in previous version, but was added in the latter, and you are using the previous version. So the class is there (it's not a ClassNotFoundException), but it does not have a method with this specific signature the calling code expects.
You should carefully examine your classpath. Locate the jar which contains the com.google.common.util.concurrent.MoreExecutors class. Check that you don't have two by some mistake. And try to find an official combination of jars that are known to work together.
And of course, welcome to classpath hell!
I just want to know the inputs for below questions.
what version of AXIS2 will come with Websphere 8.5.5.2?
Where can i see the version details of AXIS2 jars shipped with WAS 8.5.5.2?
My code actually compiled with AXIS2 1.6.1 and deployed the same in WAS 8.5.5.2. I am getting below classcast exceptions. What could your suggestions to resolve this issue. I thought there is problem with different versions of axis2 while compiling and deploying. I am not able to know what version of axis2 shipped with websphere 8.5.5.2.
Approaches I have used.
1) Part of code which uses Axis was compiled against AXIS2 1.6.1 version and generated war was deployed in WAS 8.5.5.2 with no libraires in WAR. Got classNotFoundException for org.apache.axiom.util.stax.XMLStreamWriterUtils. Added org.apache.axis2.jar located in plugins in shared libraries and attached to my server war module level. Then class cast exception came.
2) Part of code which uses Axis was compiled against AXIS2 1.6.1 and generated war was deployed in WAS 8.5.5.2 with org.apache.axis2.jar under WEB-INF/libraires in WAR. Then class cast exception came.
Calling getRendererRef(): renderer Type=[OutInRenderer]
WSRenderer I Start:
WSRenderer E Unable to perform rendering due to exception (java.lang.ClassCastException: org.apache.axiom.util.stax.xop.XOPEncodingStreamWriter incompatible with org.apache.axiom.ext.stax.datahandler.DataHandlerWriter)
WSRenderer E stacktrace=org.apache.axiom.util.stax.XMLStreamWriterUtils.internalGetDataHandlerWriter(XMLStreamWriterUtils.java:71)
org.apache.axiom.util.stax.XMLStreamWriterUtils.writeDataHandler(XMLStreamWriterUtils.java:134)
3) Kept Parent_LAST option in WAS 8.5.5.2 for server war which results plenty of errors related to parsers and other. Application stopped working because of many classcast and incompatible issues.
Any inputs are appreciable...
The code in the WebSphere runtime is not based on an official release of Apache Axis2, but on a fork created from a development version. Your only option to use Axis2 on WebSphere is to configure your application with parent last class loading. To make this work you need to remove from your application all the JARs containing APIs that must be loaded from the server runtime, such as the servlet API and various XML APIs.
I am migrating an application that used Jetty 7.4.5.v20110725 to Jetty 9.3.0.M2, using Maven. I already had upgraded the javax.servlet-api to 3.1.0.
But I am using the FakeHttpServer version 0.3.0 for tests, and at this time there is no newer version. It uses the org.eclipse.jetty.server.nio.SelectChannelConnector class that used to exist up to Jetty 8.x, but does not exists anymore in Jetty 9.
Currently my projects breaks at runtime with a NoClassDefFoundError due to the removed class in Jetty that FakeHttpServer tries to use, holding me back from upgrading Jetty. What can I do to fix that?
Note, this was also cross-posted in the Portuguese StackOverflow version: https://pt.stackoverflow.com/q/64548/132
Upgrade the code that uses Jetty on FakeHttpServer for Jetty 9.
That is your only choice if you want to use Jetty 9 with FakeHttpServer.
Looking at the project page for FakeHttpServer, it seems that there have been no updates (commits) to the project tree since Dec 2012.
You'll either have to convince the project leads to update it, or do it yourself.
Note that Jetty contains several ways of testing webapps. Look at the unit tests in the jetty source code and I'm sure you will find the equivalent of FakeHttpServer.
ServletTester comes to mind as one example. Or just create a Server using the LocalConnector is another way.
I'm trying to deploy an Axis2 web service to an OC4J 10.1.3 app server.
I was using axis 1.4 before and had just created my own shared library with all of the files. There was an issue with 1.4 that was patched with 1.5 so now I'm using that but it does not include all of the libraries. This time I deployed the axis2.war to the OC4J server and I'm using the axis2 admin page to attempt to deploy my web service.
If I deploy a web service through axis2 then I'll get a java.lang.NoSuchMethodError: javax.jws.WebMethod.exclude()Z but I cannot find the conflicting library. Axis2 has the new jax-ws libraries in it but I think it's an issue on the OC4J app server. I excluded xml.jar (since it has old JAXB 1.0 libs) and this resolves the issue on my local machine but not on the linux box.
I tried editing the deployment plan to search local folders first and this allows me to deploy the service, but when I try to access it, or the WSDL, then I get an error regarding a class cast exception and JXDocumentBuilderFactory (I don't have the exact error at this moment).
I compared the shared libraries on the linux box with the ones on my local machine and I used the same ones on each (I didn't verify the versions of each jar, though). If axis2 is deployed to OC4J and I deploy my service to axis2 then wouldn't I inherit the axis2 libraries (jax-ws, etc)?
Try removing the inherited library in conflict by adding this to your orion-application.xml:
<orion-application>
<imported-shared-libraries>
<remove-inherited name="PUT_HERE_THE_NAME_OF_THE_LIBRARY"/>
</imported-shared-libraries>
</orion-application>
More here: Removing and/or Replacing an Oracle Shared Library Imported by Default
Edit:
I searched the shared libraries and found that is not there, jws-api.jar is loaded at boot time and can't be removed easily:
Replace the OC4J JAX-WS Libraries
OC4J has preliminary support for JAX-WS, unfortunately this means that during OC4J boot it loads outdated JAX-WS APIs and implementation by Oracle. This occurs even before shared libraries comes into action, at a very early stage of OC4J boot.
Boot-time OC4J libraries are configured in boot.xml file in $ORACLE_HOME/j2ee/home/oc4j.jar bootstrap jar. To get rid of this:
1-Copy the jar file to ${oracle.home}/webservices/lib/jaxws
2-Unpack the OC4J.jar file
3-Locate META-INF/boot.xml
4-Replace path in this line with your jar:
<code-source
path="${oracle.home}/webservices/lib/jws-api.jar"
if="java.specification.version == /1\.[5-6]/"
/>
5-Repackage oc4j.jar (don't forget about MANIFEST.MF - use jar -m META-INF/MANIFEST.MF)
Original article: OC4J Configuration for Web Services