I got the below error when I try to install a CXF example from Talend into FuseESB.
FuseESB:karaf#root> features:install talend-cxf-example-jaxrs-intro
Error executing command: Can not resolve feature:
Unsatisfied requirement(s):
---------------------------
package:(&(package=javax.ws.rs.core)(version>=2.0.0)(!(version>=3.0.0)))
Intro JAX-RS Example Common
package:(&(package=javax.ws.rs)(version>=2.0.0)(!(version>=3.0.0)))
Intro JAX-RS Example REST Resource Bundle
package:(&(package=javax.ws.rs)(version>=2.0.0)(!(version>=3.0.0)))
Intro JAX-RS Example Common
package:(&(package=javax.ws.rs.core)(version>=2.0.0)(!(version>=3.0.0)))
Intro JAX-RS Example REST Resource Bundle
I have JSR-311 running
FuseESB:karaf#root> list|grep -i 311
[ 165] [Active ] [ ] [ ] [ 10] Apache ServiceMix :: Specs :: JSR-311 API 1.1.1 (1.9.0)
How to resolve Unsatisfied requirement(s) error?
Fuse uses older versions of CXF than Talend does for their ESB and does not currently support CXF 2.7.x which is where the 2.x version of the JAX-RS implementation was added. The 2.6.x version of CXF that they include only supported JAX-RS 1.1. You possibly could edit the Talend example to drop it to 1.1 level. Not sure how well that would work.
Related
While communicating with RabbitMQ messages are consumed successfully, however, the following warning is displayed in the logs.
**error occurred while mapping from AMQP properties to MessageHeaders**
lang.IllegalStateException: java.lang.ClassNotFoundException: Class_Name
t org.springframework.integration.mapping.support.JsonHeaders.getClassForValue(JsonHeaders.java:89) ~[spring-integration-core-5.2.4.RELEASE.jar:5.2.4.RELEASE]
at org.springframework.integration.mapping.support.JsonHeaders.buildResolvableType(JsonHeaders.java:72) ~[spring-integration-core-5.2.4.RELEASE.jar:5.2.4.RELEASE]
at org.springframework.integration.amqp.support.DefaultAmqpHeaderMapper.createJsonResolvableTypHeaderInAny(DefaultAmqpHeaderMapper.java:169) [spring-integration-amqp-5.2.4.RELEASE.jar:5.2.4.RELEASE].
I know it's just a warning, but I would like to know the way it can be avoided.
Thanks in advance
This has been fixed in Spring Integration 5.2.5: https://github.com/spring-projects/spring-integration/issues/3223. Please, consider to upgrade to the latest Spring Boot 2.2.6 and it is included over there. See Spring Boot docs how to override dependency versions: https://docs.spring.io/spring-boot/docs/2.2.6.RELEASE/reference/html/using-spring-boot.html#using-boot-maven
You can apply workarounds otherwise as mentioned in that GH issue.
I'd like to use a proprietary Apache CXF feature (Multipart handling for file upload), which is not covered in the JAX-RS 2.1 spec. Adding the following dependency to my Jakarta EE 8 project results in weird internal Apache CXF NPEs:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxrs</artifactId>
<version>3.3.4</version>
</dependency>
Errors:
[INFO] java.lang.NullPointerException
[INFO] [WARNING ] Exception in handleFault on interceptor org.apache.cxf.jaxrs.interceptor.JAXRSDefaultFaultOutInterceptor#5e2be3a2
[INFO] org.apache.cxf.interceptor.Fault
[INFO] [ERROR ] An unexpected error occurred during error handling. No further error processing will occur.
[INFO] org.apache.cxf.interceptor.Fault
[INFO] [ERROR ] SRVE0777E: Exception thrown by application class 'org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter:64'
[INFO] java.lang.NullPointerException
[INFO] at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
[INFO] at [internal classes]
[INFO]
[INFO] [ERROR ] SRVE0315E: An exception occurred: java.lang.Throwable: java.lang.NullPointerException
[INFO] at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:5075)
[INFO] at [internal classes]
[INFO] Caused by: java.lang.NullPointerException
[INFO] at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
[INFO] ... 1 more
My understandings from my research for this problem are, that the application can't access the internal CXF code, so the scope provided won't work and with my current solution (shipping the extension with the .war file) it leads to classloader problems.
I'm running on Open Liberty 19.0.0.12 and JDK 11
This is the expected behavior. Apache CXF has many features that go beyond the JAX-RS specification. In the past traditional WebSphere has suffered from problems where they used an open source product to provide some functionality, exposed all of that product's packages/classes, and then users would use them. The problem starts when users then want to pull in a different version or different module configuration of the open source product than what is available in the application server. So then users must package their own version of the product with their app or in shared library, and must resort to classloading tricks like parent-last to avoid loading IBM's version of that product - and this inevitably leads to classloading problems like ClassCastExceptions. The other disadvantage of this approach is that it painted IBM in a corner - for example, if the open source product is no longer supported (i.e. Apache Wink), IBM could not swap out open source products to provide an alternative that also implements the given specification.
Liberty takes a different approach. You can use the IBM-provided features or you can package the third party libraries in your app (or shared library). This solves both of the problems listed above - but does have implications for the scenario you've described.
There are a few different approaches to resolving your issue:
1) Open an issue (or give a +1 to an existing issue) with Open Liberty to officially support the CXF proprietary feature(s) that you are looking for. Depending on the feature requested, it might require using a different package name for the API or it might involve a configuration setting to enable, etc. You can do that here:
https://github.com/OpenLiberty/open-liberty/issues
2) Remove the jaxrs-2.1 feature from the feature manager list in your server.xml, and package the CXF libraries with your app. You would also need to package the JAX-RS API libraries.
3) You could create a user feature ( https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_feat_develop.html ) that exposes the CXF APIs. One note of caution here is that if you expose the org.apache.cxf packages, and then Liberty were to swap open source providers (i.e. switch to Jersey or RestEasy), then the org.apache.cxf packages would no longer be there. That would effectively prevent you from upgrading Liberty versions until you upgraded your user feature to package the CXF modules. Options 1 and 2 are certainly more future-proof.
Hope this helps! Andy
I'm porting a desktop JavaFx Application that requires Jackson to GluonMobile, it's my first time using this platform and I end up on the next stacktrace with a NoClassDefFoundError.
I would like to know if this requires a feature not supported by GluonMobile or if I just forgot to include something properly.
Apr 19, 2018 8:25:02 PM com.fasterxml.jackson.databind.ext.Java7Support <clinit>
WARNING: Unable to load JDK7 types (annotations, java.nio.file.Path): no Java7 support added
[WARN] java.lang.Class: Class.forName() failed to load 'javax.servlet.Servlet'. Use the -forcelinkclasses command line option or add <forceLinkClasses><pattern>javax.servlet.Servlet</pattern></forceLinkClasses> to your robovm.xml file to link it in.
ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console...
TRACE Task Catching
java.lang.NoClassDefFoundError: java.util.function.ToLongFunction
at java.lang.VMClassLoader.findClassInClasspathForLoader(Native Method)
at java.lang.PathClassLoader.findClass(PathClassLoader.java:193)
at java.lang.ClassLoader.loadClass(ClassLoader.java:515)
at java.lang.ClassLoader.loadClass(ClassLoader.java:475)
at com.fasterxml.jackson.datatype.jsr310.ser.InstantSerializer.<init>(InstantSerializer.java:38)
at com.fasterxml.jackson.datatype.jsr310.ser.InstantSerializer.<clinit>(InstantSerializer.java:35)
at com.fasterxml.jackson.datatype.jsr310.JavaTimeModule.<init>(JavaTimeModule.java:161)
at com.general.plugin.jackson.json.JacksonObjectMapper.<clinit>(JacksonObjectMapper.java:214)
at java.lang.Class.classForName(Native Method)
at java.lang.Class.forName(Class.java:218)
at java.lang.Class.forName(Class.java:176)
at com.general.core.startup.Configuration.getSharableInstance(Configuration.java:69)
at com.general.core.startup.AbstractClient.<init>(AbstractClient.java:39)
at com.objectdb.core.startup.Client.<init>(Client.java:31)
at com.objectdb.ui.service.ClientFactory.getDBClient(ClientFactory.java:39)
at com.objectdb.ui.service.ClientTask.getDBClient(ClientTask.java:13)
at com.objectdb.ui.startup.Main$2.call(Main.java:30)
at javafx.concurrent.Task$TaskCallable.call(Task.java:1423)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.lang.Thread.run(Thread.java:837)
This solution is quite a workaround that requires a bit of work.
Fixes Jackson 2.9.5 to work in gluon jfxmobile-plugin 1.3.10.
To fix jackson-databind to be able build immutable objects with a single constructor.
1.1 Drop the usage of the JDK8 module parameter-names since this requires a non implemented VM feature.
Use instead java.beans.ConstructorProperties.
1.2 Jackson uses for ConstructorProperties support some Interfaces from JDK8 that can be safety included as part of your project.
java.beans.ConstructorProperties
java.beans.Transient
1.3 Force link JDK7 support
forceLinkClasses = [
'com.fasterxml.jackson.databind.ext.Java7SupportImpl',
]
To fix jackson-datatype-jsr310.
2.1 It uses some JDK8 interfaces that can be safety included in your project.
java.util.function.ToIntFunction
java.util.function.ToLongFunction
2.2 It uses some JDK8 methods that can be safety substituted by JDK6-7 implementations, simply include in your project the java files and look up the pre-JDK8 back ports of the Time API.
JavaTimeModule.java
SerializerToPach.java
3.3 Point your own JavaTimeModule to your own serializer.
3.4 Register in your ObjectMapper your own JavaTimeModule.
Voila, now you can use the lattest Jackson to create immutable objects and use JDK8 Time classes in gluon jfxmobile-plugin 1.x
We are trying to make a webservice call using CXF framework involving CXF - ws security and the application being deployed in weblogic 10.3 , but receiving the below exception and seems like the weblogic specific jars are picked up , though the xercesimpl jar is present in the application in /WEB-INF/lib .
Options tried , but did not help:
Setting the weblogic container descriptor with
web-inf preferences
true .
Setting the JVM arguments or system property as -
-Djavax.xml.soap.MessageFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
-Djavax.xml.soap.SOAPFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPFactory1_1Impl
-Djavax.xml.soap.SOAPConnectionFactory=weblogic.wsee.saaj.SOAPConnectionFactoryImpl
Adding xercesimpl jar to maven pom.
Exception
]] Root cause of ServletException.
java.lang.AssertionError: UNIMPLEMENTED
at weblogic.xml.domimpl.NodeImpl.setTextContent(NodeImpl.java:216)
at org.apache.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeAttribute(XmlWriterToTree.java:137)
at org.apache.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeNamespace(XmlWriterToTree.java:114)
at org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.marshal(DOMXMLSignature.java:211)
at org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:329)
at org.apache.wss4j.dom.message.WSSecSignature.computeSignature(WSSecSignature.java:578)
at org.apache.wss4j.dom.action.SignatureAction.execute(SignatureAction.java:151)
at org.apache.wss4j.dom.handler.WSHandler.doSenderAction(WSHandler.java:226)
at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor.access$100(WSS4JOutInterceptor.java:54)
at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessageInternal(WSS4JOutInterceptor.java:282)
at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:154)
at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:141)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)enter code here
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:98)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
Thanks,
Soumya
I finally found the answer without modifying any weblogic startup script (tested on CXF 2.7.0 and weblogic 10.3.6
The reason for this issue is that CXF is not compatible with weblogic implementation of SAAJ. http://cxf.apache.org/docs/application-server-specific-configuration-guide.html
1.
Q: I have this error: javax.xml.ws.WebServiceException: Cannot create SAAJ factory instance.
A: Please make sure you have the saaj-impl-1.3.jar in the classpath and make sure your app picks up this one instead of weblogic one.
The same issue is also causing the UNIMPLEMENTED error in the question
So my solution is
1) put saaj-impl in classpath. If you are using maven, put the dependency on pom.xml
2) in weblogic.xml (in your resources folder) put
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>com.sun.xml.messaging.saaj.*</wls:package-name>
</wls:prefer-application-packages>
</wls:container-descriptor>
3) Restart your server through Node Manager and by right the CXF WS-Security should be working
Hope it helps!
When running Mule ESB 3.2.1 as embedded server inside Tomcat 7.0.27 (executed with webapp-runner), during execution of a flow with the Http endpoint, while sending response back to caller, an Exception is raised:
java.lang.NoSuchMethodError: org.apache.tomcat.util.http.ServerCookie.appendCookieValue(Ljava/lang/StringBuffer;ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;IZ)V
Exception Below:
org.mule.api.MuleRuntimeException: Connector that caused exception is: connector.http.mule.default
at org.mule.transport.AbstractConnector.handleWorkException(AbstractConnector.java:2034)
at org.mule.transport.AbstractConnector.workCompleted(AbstractConnector.java:1998)
at org.mule.work.WorkerContext.run(WorkerContext.java:369)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NoSuchMethodError: org.apache.tomcat.util.http.ServerCookie.appendCookieValue(Ljava/lang/StringBuffer;ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;IZ)V
at org.mule.transport.http.CookieHelper.formatCookieForASetCookieHeader(CookieHelper.java:310)
at org.mule.transport.http.transformers.MuleMessageToHttpResponse.createResponse(MuleMessageToHttpResponse.java:261)
at org.mule.transport.http.transformers.MuleMessageToHttpResponse.transformMessage(MuleMessageToHttpResponse.java:90)
at org.mule.transformer.AbstractMessageTransformer.transform(AbstractMessageTransformer.java:145)
at org.mule.transformer.AbstractMessageTransformer.transform(AbstractMessageTransformer.java:93)
at org.mule.DefaultMuleMessage.applyAllTransformers(DefaultMuleMessage.java:1387)
at org.mule.DefaultMuleMessage.applyTransformers(DefaultMuleMessage.java:1348)
at org.mule.DefaultMuleMessage.applyTransformers(DefaultMuleMessage.java:1331)
at org.mule.transport.AbstractMessageReceiver.applyResponseTransformers(AbstractMessageReceiver.java:235)
at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:214)
at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:163)
at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:150)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.doRequest(HttpMessageReceiver.java:299)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.processRequest(HttpMessageReceiver.java:258)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageReceiver.java:163)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
If you are using Mule 3.2.1, you can not use the http:response-builder. The feature is just not there. That's why you can't use it.
Check it out:
It's not in the doc: http://www.mulesoft.org/documentation-3.2/display/32X/HTTP+Transport+Reference
It's not in the source: https://github.com/mulesoft/mule/blob/mule-3.2.1/transports/http/src/main/java/org/mule/transport/http/config/HttpNamespaceHandler.java#L56
I had this problem too. Check answer here.
Mule ESB does not work with cookie
In short, make sure you have provided group: 'org.apache.tomcat', name: 'coyote', version: '6.0.44' for mule 3.7.0.
In your case, you should have another library - tomcat-util 5.5.23 because you use different version of mule 3.2.1.
compile group: 'tomcat', name: 'tomcat-util', version: '5.5.23'
When you use SpringBoot, it ovverides a version of some library (depending on version of Spring and Mule), so you will get this error. You have class ServerCookie but the method appendCookieValue will disappear!
Solution - play with libraries. Or another bad workaround, write your own version of one of these classes that fail, and make sure classloader will use your version of the classes. (Again, creating a class with the same name and package to fix a bug - is a risky and bad thing...)