I was trying to intercept from/to specific rabbitmq route something like the following,
interceptFrom(rabbitmq:localhost/someExchangeName?queue="somerRabbitMqQueueName").to("log:hello");
and i'm not getting anything there.
I've tested
intercept().to("log:hello") and i can confirm it's working, can anyone let me know if there's something else that i need to configure to make the intercept from/to works?
We're using Java DSL and Google Guice for dependency injection.
Some of the project setup as follows,
camel version: 2.18.3 (tried also 2.19.1)
camel-guice: 2.18.3
guice-multibindings: 4.1.0
camel-rabbitmq: 2.18.3
maven-compiler-plugin: 1.7
This was also asked on the Camel mailing list.
Make sure it can match the actual url, so make sure they are exact the
same if you are not using wildcard (*), you can just do
interceptFrom("rabbitmq:localhost/xxx*")
Or try with
interceptFrom("rabbitmq:localhost/xxx?queue=foo*")
See also the Camel documentation, and about the wildcard pattern (in the bottom of the page): http://camel.apache.org/intercept
Related
I am trying to bridge Camel REST endpoints to a backend server. Corresponding REST DSL is as follows:
from("rest:get:tt:/{id}")
.toF("%s/%s?bridgeEndpoint=true","http://192.168.1.1:80","jjjj/llll/pppp/{id}");
My expectation is that the request should be forwarded to http://192.168.1.1:80/jjjj/llll/pppp/id But what actually happens is that the request gets forwarded to http://192.168.1.1:80/jjjj/llll/pppp/%7Bid%7D/tt/id
Can any one suggest, what am I doing wrong and how I can achieve the desired behaviour? I am using Spring Boot Camel 2.3.4 which uses Camel 3.5.0 internally.
Mean while, I have found a work around that to use .to() instead of .toF(). With .to(), I achieved desired behavior. Camel route DSL is Something like
from("rest:get:tt:/{id}").to("rest:get:jjjj/llll/pppp/{id}?host=http://192.168.1.1:80")
But question still remains open that why it is not working with .toF().
Seems like you're using {id} syntax for http component uri, but I think it's only recognized by the rest component, so instead of having:
from("rest:get:tt:/{id}")
.toF("%s/%s?bridgeEndpoint=true", "http://192.168.1.1:80", "jjjj/llll/pppp/{id}");
you could try using dynamic endpoint .toD() with simple expression ${header.id}:
from("rest:get:tt:/{id}")
.toD("http://192.168.1.1:80/jjjj/llll/pppp/${header.id}?bridgeEndpoint=true");
Not exactly sure if that's what you're aiming for though
We already have project which received request on REST EndPoint and by
using FINITE STATE Machine evaluate next action with Transition and
call action class accordingly.
I am assigned to evaluate possibility to migrate this part to apache camel.
But i am not seeing any value addition as in camel we already defined
routes and we can also use dynamic routing for evaluating next
endpoint.
I googled but couldnt find any Apache Camel example using FSM.
I need comments any use case where we can use FSM in Apache Camel or
we dont require due to nature of Camel.
if anyone found any links for google please share it to.
https://dzone.com/articles/why-developers-never-use-state
Regards,
When I got an error inside an Endpoint URI the camel context wont start.
It seems like Camel validates in a first step every Endpoint URI before starting the context.
Can someone pleas tell me, how this works?
Am I right?
I cant figure it out.
Yes Camel validates that it has been configured correctly when it startup. This happens as part of starting the Camel routes.
Its like misconfiguring any other software which will report an error for you to fix.
There is some tooling which you can use to validate your source code to find endpoints that has been misconfigured. I wrote a blog entry about this: http://www.davsclaus.com/2016/01/cheers-fabric8-camel-maven-plugin-to.html
We are tying to use a WebService OutFaultInterceptor as per this blog post and it doesn't seem to work in JBoss 7.x.
The problem is simple in that it just ignores the #OutFaultInterceptor annotation. I tested this by putting in a erroneous interceptor name and it didn't error out. Logging within the interceptor is simply not called (when the interceptor name is correct).
I have also tried using the WEB-INF/jboss-webservices.xml to define out interceptors but that also seems to get ignored.
Removing the #Stateless annotation also does not seem to help.
This was working fine on JBoss 5.1 but simply seems to not work on JBoss 7.x. What am I missing here?
Is there an alternative way to "translate" exceptions into soap faults?
In order for using Apache CXF APIs and implementation classes you need to add a dependency to the org.apache.cxf (API) module and / or org.apache.cxf.impl (implementation) module.
Dependencies: org.apache.cxf services
According documentation:
When using annotations on your endpoints / handlers such as the Apache
CXF ones (#InInterceptor, #GZIP, ...) remember to add the proper
module dependency in your manifest. Otherwise your annotations are not
picked up and added to the annotation index by JBoss Application
Server 7, resulting in them being completely and silently ignored
See also: JBoss Modules
I hope this help.
Given the "cxf-osgi" example from fuse source's apache-servicemix-4.4.1-fuse-00-08, built with maven 3.0.3, when deploying it to apache karaf 2.2.4 and CXF 2.4.3 the web service is never published and never visible to the CXF servlet (http://localhost:8181/cxf/). There are no errors in the karaf log. How would one go about debugging such behavior?
It's worth turning up the log level(s) - you can do this permanently in the etc/org.ops4j.pax.logging.cfg or in the console with log:set TRACE org.apache.cxf - IIRC this will show some useful information.
Also check that it's actually published on localhost/127.0.0.1 - it may well be being published on another interface, the IP of the local network but not localhost. Try using 0.0.0.0 as the the address, that way it will bind to all available interfaces.
As you're using maven, you can download the CXF source (easily in Eclipse) and connect a remote debugger to the Karaf instance, with some strategically placed breakpoints you should be able to get a handle on what's going on.
Try changing to Equinox instead of the default of Felix. There is a bug in 2.4.3 in that it doesn't work well with Felix. Alternatively, CXF 2.4.4 is now available that should also fix it.
Take a look at this issue I filed this week: https://issues.apache.org/jira/browse/CXF-4058
What I found is that if my beans.xml is loaded before the cxf bundle jar, then the endpoints are registered with CXF but not with the OSGi http service. So everything looks good from the logs but the endpoints are never accessible. This is a race condition.
I did two workarounds: 1) in the short term, just move my own jars later in the boot order (I use Karaf features) so Spring and CXF are fully loaded before my beans.xml is read and 2) abandon Spring and roll my own binding code based loosely on this approach: http://eclipsesource.com/blogs/2012/01/23/an-osgi-jax-rs-connector-part-1-publishing-rest-services/
I just implemented solution #2 yesterday and I'm already extremely happy with it. It's solved all of my classloader issues (before I had to manually add a lot of Import-Package lines because BND doesn't see beans.xml references) and fixed my boot race condition.