I have a route that calls the HTTP component in Camel 3.3. This is working fine and I am trying to catch the HttpOperationFailedException which is being thrown.
I have declared the following error handler in my camel route:
<onException>
<exception>org.apache.camel.http.common.HttpOperationFailedException</exception>
</onException>
The org.apache.camel.http.common.HttpOperationFailedExceptionis showing up as being depcrecatted and when I look at the documentation for Camel 3.3 I cant even find the HttpOperationFailedException.
Accoding to the JavaDoc the last time HttpOperationFailedException was listed was in the 2.25.1 release. According to the 3.3.0 javadoc the HttpOperationFailedException has been removed yet in my project it still throws it.
I double check my effective pom and this my dependency:
<dependency>
<groupId>org.apache.camel.springboot</groupId>
<artifactId>camel-http-common-starter</artifactId>
<version>3.3.0</version>
</dependency>
I am pushing forward and using the exception but can someone please share some light on what is going on? Is this a mistake in the docs? If the HttpOperationFailedException was deprecated and/or removed what will replace it?
See the javadoc of the deprecated class what to use: https://github.com/apache/camel/blob/master/components/camel-http-common/src/main/java/org/apache/camel/http/common/HttpOperationFailedException.java#L22
Related
We are migrating from EAP 6 to EAP 7 one project that uses Apache Camel. In this project, we are using dependency injection using the CDI 2.0 specification provided by EAP 7. We are migrating from EAP 6.4 which is using CDI 1.X specification. The Apache Camel version that we are using is 2.17.6
We have updated our project with the appropiate changes in the code, but in the moment of deploying the application in the server, we are getting this error, coming from the Camel dependency:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type CdiCamelExtension with qualifiers #Default
at injection point [BackedAnnotatedParameter] Parameter 3 of [BackedAnnotatedMethod] #Produces private static org.apache.camel.cdi.CdiCamelFactory.typeConverter(InjectionPoint, #Any Instance<CamelContext>, CdiCamelExtension)
at org.apache.camel.cdi.CdiCamelFactory.typeConverter(CdiCamelFactory.java:0)
It seems that it is a problem related with Apache Camel, with the 3rd parameter of the signature, that cannot find the way to obtain an object to inject it here.
The camel library camel-cdi-2.17.6jar file that contains the class org.apache.camel.cdi.CdiCamelExtension, and the service configuration in this jar is indicating to use this CdiCamelExtension.
We can see also that within this library the beans.xml file contains:
<beans version="1.0" bean-discovery-mode="all">
<scan>
<exclude name="org.apache.camel.cdi.Main"/>
</scan>
</beans>
With all this, we cannot see why CdiCamelContext cannot be obtained.
Could this be because EAP 7 is using CDI 2.0, and Camel 2.17.6 could not be compatible with this specification? We don't have much experience with Camel, so we are not sure if we could be missing something with it.
Thanks for your help
adding <module name="org.apache.camel" annotations="true" meta-inf="true"/> to global-modules of standalone.xml worked for me.
I am seeing this warning message and wanted to know how to update so I am using v38 or higher as recommended?
WARN 2016-12-13 12:16:55,221 [[test].test-order-system-httpListenerConfig.worker.01] org.mule.modules.salesforce.config.AbstractConfig: API version 37.0 is lower than the recommended 38.0 version
Thanks
make sure you have correct dependency in pom.xml
<dependency>
<groupId>org.mule.modules</groupId>
<artifactId>mule-module-sfdc</artifactId>
<version>8.1.0</version>
</dependency>
and url has correct ver
.......salesforce.com/services/Soap/u/38.0
Running Camel 2.17.3 on Karaf 4.0.5 with camel-atmosphere-websocket feature Atmosphere (v2.4.3) raises the following exception:
Cannot load the WebSocketProtocol org.apache.camel.component.atmosphere.websocket.WebsocketHandler
java.lang.ClassNotFoundException: org.apache.camel.component.atmosphere.websocket.WebsocketHandler not found by org.atmosphere.runtime [203]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:805)[:1.8.0-internal]
at org.atmosphere.util.IOUtils.loadClass(IOUtils.java:370)[203:org.atmosphere.runtime:2.4.3]
at org.atmosphere.cpr.AtmosphereFramework.initWebSocket(AtmosphereFramework.java:1762)[203:org.atmosphere.runtime:2.4.3]
The package is exported by the bundle org.apache.camel.camel-atmosphere-websocket.
Am I missing any dependencies or is there an issue with the startup order?
Add this dependency to your pom.xml
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-atmosphere-websocket</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
As mentioned you need to use the same version for all dependecies.Reference : http://camel.apache.org/atmosphere-websocket.htmlHope this Works.
I didn't manage to use the Jersey linking support with Google App Engine, I'm getting these exceptions when trying to access the application :
Caused by: javax.el.ELException: Could not find expression factory class
...
Caused by: java.lang.ClassNotFoundException: de.odysseus.el.ExpressionFactoryImpl
As specified in the documentation, I put this in the Jersey servlet section of the web.xml :
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
<param-value>com.sun.jersey.server.linking.LinkFilter</param-value>
</init-param>
I also add the jersey-server-linking-1.13.jar to the WEB-INF/lib directory of my project.
I tried to add el-api.jar first, then juel-2.1.0.jar to the WEB-INF/lib directory but I'm still getting these errors.
I'd like to know if someone could give me some hints about the way to deal with this. When I don't use the Jersey linking jar, everything is working as expected.
I had a similar problem with my GAE app. It was working fine with el-api and el-impl but started asking for de.odysseus.el.ExpressionFactoryImpl as development progressed. I made the switch but when I added JUEL to my pom.xml, I got the same error as John Prince (java.security.AccessControlException).
The solution for GAE users is to use JUEL 2.2.7.
At the time of this writing, 2.2.7 is not available in maven central. However, you can find it on
<repository>
<id>repo-id</id>
<name>repo-name</name>
<url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</repository>
and link with whatever you need from
<dependency>
<groupId>de.odysseus.juel</groupId>
<artifactId>juel-api</artifactId>
<version>2.2.7-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>de.odysseus.juel</groupId>
<artifactId>juel-impl</artifactId>
<version>2.2.7-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>de.odysseus.juel</groupId>
<artifactId>juel-spi</artifactId>
<version>2.2.7-SNAPSHOT</version>
</dependen
Source: https://github.com/beckchr/juel/issues/73
The issue is due to de.odysseus.el.ExpressionFactoryImpl class not being found. I will assume that you have added the jars as you have mentioned to the WEB-INF\lib folder.
I would suggest that you view the JAR files via theProject Explorer , simple expand them in Eclipse and see if you can find the de.odysseus.el.ExpressionFactoryImpl class in ny of the JAR files that you have added.
I "solved" the problem by adding "juel" and "juel-impl" as dependencies of my project (we're using Maven; if you're doing it manually, you might have to figure out exactly what those projects contain).
However, as soon as I did that, I started getting a different exception:
java.security.AccessControlException: access denied (java.io.FilePermission C:\Program Files (x86)\Java\jdk1.6.0_33\jre\lib\el.properties read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:289)
...
I'm pretty sure that's because it's running afoul of GAE restrictions.
I noticed in the original ClassNotFound exception it was trying to use the URLClassLoader; I'm also wondering if that problem was ultimately a GAE issue as well.
At this point, it seems like Jersey linking support isn't compatible with GAE.
This issue is (or rather was) due to a missing implementation of the Unified Expression Language. The EL API defines a static method that looks up an implementation of the ExpressionFactory class. There are various ways to define which implementation is to be used:
Use the Services API (as detailed in the JAR specification). If a resource with the name of META-INF/services/javax.el.ExpressionFactory exists, then its first line, if present, is used as the UTF-8 encoded name of the implementation class.
Use the properties file "lib/el.properties" in the JRE directory. If this file exists and it is readable by the java.util.Properties.load(InputStream) method, and it contains an entry whose key is "javax.el.ExpressionFactory", then the value of that entry is used as the name of the implementation class.
Use the javax.el.ExpressionFactory system property. If a system property with this name is defined, then its value is used as the name of the implementation class.
Use a platform default implementation.
(Source: http://docs.oracle.com/javaee/7/api/javax/el/ExpressionFactory.html#newInstance())
App Engine appears to have defined JUEL as default implementation but does not provide the respective packages.
In order to solve this, you need to (1) provide EL API and implementation packages and (2) use one of the above ways to link it. See https://stackoverflow.com/a/19814199/2099217 for details.
I've been trying to create a single project which can run both on sql and gae (where the 'datanucleus.properties' file needs to be changed) under a single maven folder structure. I first tried to get the Greeting example on the GAE website using mysql (this now works). Then, inspiring myself from beardedgeeks tutorial, I have tried to add the required dependencies so as to run the stuff on gae. By typing in mvn gae:run, however, I get the following error, posted at http://pastebin.com/fJ7c7xfx. I have spent a large amount of time searching google etc. for answers, but haven't been able to advance my case.
I would be glad to get some pointers.
Cheers,
manojo
This question is tagged [JDO] but the following trace:
Caused by: java.lang.ClassNotFoundException: javax.persistence.InheritanceType
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at com.google.appengine.tools.development.IsolatedAppClassLoader.loadClass(IsolatedAppClassLoader.java:151)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 77 more
suggests that you're missing the JPA API jar (provided by org.apache.geronimo.specs:geronimo-jpa_1.0_spec:1.1.1).
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-jpa_3.0_spec</artifactId>
<version>1.1.1</version>
</dependency>
Since you're not using JPA, you shouldn't have to do that but it appears that the JPA API is somehow referenced by the datanucleus appengine plugin as explained by #Datanucleus.
The people at Google unwisely put a reference in to that JPA class in their plugin and so it requires that you have the jpa.jar (the Geronimo one will do) in your CLASSPATH. An issue was raised on them a long time ago to fix it, but sadly they don't actively maintain their plugin.