We are migrating CXF version 2.7.7 to 3.1.8 and facing the belows issue.
And also updated javax.rs.ws 2.0-m10 to 2.0.1
Exception in thread "main" java.lang.NoClassDefFoundError: javax/ws/rs/client/ClientException
If we are using the same javax.rs.ws 2.0-m10, facing the below issue
Exception in thread "main" java.lang.NoClassDefFoundError: javax/ws/rs/core/NoContentException
Anyone have the solution, what could be the right version of Javax-rs-ws version which contains both the classes?
From the CXF 3.1.x migration guide
Support for using JAX-WS 2.1 based API jars has been removed. Java 7
(now required) includes JAX-WS 2.2 so this should not be an issue.
Related
While deploying my Mule project with Mule runtime 4.3.0 to cloudhub through maven, i am getting below exception:
Execution default-deploy of goal org.mule.tools.maven:mule-maven-plugin:3.3.5:deploy failed: MessageBodyReader not found for media type=application/json;charset=utf-8, type=class org.mule.tools.client.arm.model.AuthorizationResponse, genericType=class org.mule.tools.client.arm.model.AuthorizationResponse.
Any help will be appreciated.
Thanks
Vikas
The fact that it works with Java 8 indicates it is some Java compatibility issue.
Mule Maven Plugin supports only until Java 11. See the release notes for your version to see software compatibility: https://docs.mulesoft.com/release-notes/mule-maven-plugin/mule-maven-plugin-release-notes
I have a Web application using Apache CXF version 3.2.1 which deploys and works successfully on Weblogic version 12.2.1.3.0.
Because of security vulnerabilities I need to bump the version of CXF library from 3.2.1 to latest (3.2.13 in that moment).
I got the following error when trying to deploy the application with version above 3.2.1(3.2.2, 3.2.3, 3.2.11, 3.2.13 etc..)
<Apr 7, 2020 6:19:54,850 PM EEST> <Error> <HTTP> <BEA-101216> <Servlet: "JAX-RS/Jersey#1" failed to preload on startup in Web application: "webservices.war".
A MultiException has 3 exceptions. They are:
1. java.lang.InstantiationException
2. java.lang.IllegalStateException: Unable to perform operation: create on org.apache.cxf.jaxrs.provider.AbstractResponseViewProvider
3. java.lang.IllegalStateException: Unable to perform operation: create on org.glassfish.jersey.message.internal.MessageBodyFactory
I tried the following approaches:
Adding a shared library as described here:
https://docs.oracle.com/middleware/1213/wls/RESTF/use-jersey20-ri.htm#RESTF296
Modifying the schema location
https://www.oracle.com/webfolder/technetwork/weblogic/weblogic-web-app/index.html
Setting prefer-web-inf-classes to true so all
libraries are taken from the deployed application(not from the
server)
Adding local copy of Jax-RS in my lib folder and trying to use it with prefer-application-packages
Do you have any idea what could cause the problem?
What might be the difference between Apache CXF 3.2.1 and 3.2.2 ?
Why is a minor version change breaking an application?
I have recently upgraded our unboundid ldap jar version from 1.1.3 to 3.1.1. After the upgrade when I am deploying the app in weblogic, I am getting a ClassNotFoundException in the log. So far I have faced no issues in terms of functionality, but I am concerned is there any connection leakage is happeining underneath or not.
Caused by: java.lang.ClassNotFoundException: com.unboundid.ldap.sdk.DisconnectType
at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:297)
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:270)
at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:64)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:179)
at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:43)
... 1 more
App package : WAR
Server : Weblogic 10.3.6
I experienced a similar issue, using unboundid ldap 2.2.0 and Tomcat 7, with reference to ProtocolMessages instead of DisconnectType:
java.lang.NoClassDefFoundError: com/unboundid/ldap/protocol/ProtocolMessages
The class was definitely present in the jar files. In my case, this error was a smokescreen. On initialization, the application experienced an error and failed to load; however, some ldap connection threads had already connected and did not get shut down properly. The orphaned threads continued to throw NoClassDefFoundError until I restarted the application server.
I have changed the mule runtime from EE 3.7.0 to CE 3.5.0 but getting error
Exception in thread "main" java.lang.IllegalArgumentException:
Application name not specified.
If you still are facing this problem, consider trying these possible solutions:
Clean your project
Update the version of the embedded server
Try creating the application again
Restlet 2.1.RC1 works fine but upgrading to 2.1.2 gives :
WARN - Unable to unmarshal the XML representation
javax.xml.bind.JAXBException: Unable to create customized SAX source
- with linked exception:
[javax.xml.parsers.ParserConfigurationException: FEATURE_SECURE_PROCESSING: Cannot set the feature to false when security manager is present.]
at org.restlet.ext.jaxb.internal.Unmarshaller.unmarshal(Unmarshaller.java:201)
at org.restlet.ext.jaxb.JaxbRepresentation.getObject(JaxbRepresentation.java:417)
at org.restlet.ext.jaxb.JaxbConverter.toObject(JaxbConverter.java:172)
at org.restlet.service.ConverterService.toObject(ConverterService.java:170)
at org.restlet.resource.Resource.toObject(Resource.java:828)
at org.restlet.engine.resource.ClientInvocationHandler.invoke(ClientInvocationHandler.java:240)
at com.sun.proxy.$Proxy57.getServerInformation(Unknown Source)
I confess a while ago I posted a very similar question - but in that one I focused on the issue that
Restlet 2.1.2 + Java 1.6 as a Netbeans 7.x app works.
But changing java to Java 1.7 gives above error so I think this question is not a duplicate as here I am focusing on Restlet 2.1.RC1 ==> 2.1.2.
As mention in other question I suspect this change is related.
The eventual workaround was the code hack described in
https://stackoverflow.com/a/19230016/449347
See the bug raised at https://github.com/restlet/restlet-framework-java/issues/785