Re: Comparison of Apache Camel and IBM Integration Bus v9.0
Hello, I think for the most part you did a good job but IMHO I really don't understand how you can make a comparison of both when you say : Since IB9 is a full fledged ESB, it allows developers to deploy their routing and mediation logic onto integration nodes which host integration servers across the enterprise. This is an extremely powerful offering as it makes it easy for teams to *hot deploy* their integration solutions very easily without having to worry about painful class loading issues that driven me mad in IBM WebSphere *Application Server*. You're talking about an application Server of IBM and you compare it to Camel.. This is so wrong. You should blog about ServiceMix (or Apache Camel - Apache Karaf - Apache ActiveMQ -...) and not only focus on Apache Camel to get the whole picture. Regards, Morgan On 1/05/2015 6:03, jamie3 wrote: Here is the second post in the series. http://beertechcode.blogspot.ca/2015/05/the-3-foot-view-of-apache-camel-and.html -- View this message in context: http://camel.465427.n5.nabble.com/Comparison-of-Apache-Camel-and-IBM-Integration-Bus-v9-0-tp5766171p5766563.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel connects to queue instead of topic when using AMQP 1.0
Hi Thanks for sharing your findings. I am updating the docs to include your configuration https://cwiki.apache.org/confluence/display/CAMEL/AMQP On Thu, Apr 30, 2015 at 11:48 PM, Mark Kusec mku...@mdacorporation.com wrote: Following up my own question with an answer: I found a solution by following the clues at https://issues.apache.org/jira/browse/QPID-4991. I gather that ActiveMQ doesn't internally map AMQP topics to JMS topics unless the destinationName begins with the prefix topic://. If this prefix is absent then ActiveMQ maps your AMQP topic to a JMS queue of the same name. Since the Qpid JMS connection factory doesn't add this prefix by default, Camel ends up connecting to queues when it thinks it is connecting to topics. The solution is to explicitly tell the Qpid connection factory to add the prefix that ActiveMQ wants to every topic name. The following worked for me: bean id=amqpConnection class=org.apache.camel.component.jms.JmsComponent property name=connectionFactory bean class=org.apache.qpid.amqp_1_0.jms.impl.ConnectionFactoryImpl factory-method=createFromURL constructor-arg index=0 type=java.lang.String value=amqp://localhost:5672 / property name=topicPrefix value=topic:// / !-- only necessary when connecting to ActiveMQ over AMQP 1.0 -- /bean /property /bean I hope this is of assistance to others. -Original Message- From: Mark Kusec Sent: Thursday, April 30, 2015 10:31 AM To: users@camel.apache.org Subject: Camel connects to queue instead of topic when using AMQP 1.0 Hi all, I have run into an interesting issue, and I'm not sure whether it is due to user error or a bug. I'm using Spring XML DSL to setup a subscription to a topic. But instead of getting a subscription to a topic, I'm actually getting a consumer on a queue of the same name. This only happens if I use AMQP 1.0 (camel-amqp). If I change to OpenWire, I get a subscription to a topic as I expect. The following illustrates how I tested this: In servlet.xml, I have created two connections to the same instance of ActiveMQ, one of which uses AMQP and one not: bean id=amqpConnection class=org.apache.camel.component.jms.JmsComponent property name=connectionFactory bean class=org.apache.qpid.amqp_1_0.jms.impl.ConnectionFactoryImpl factory-method=createFromURL constructor-arg index=0 type=java.lang.String value=amqp://localhost:5672 / /bean /property /bean bean id=tcpConnection class=org.apache.camel.component.jms.JmsComponent property name=connectionFactory bean class=org.apache.activemq.ActiveMQConnectionFactory property name=brokerURL value=tcp://localhost:61616 / /bean /property /bean My routes look like this. I think they should both connect to the same topic. But in the ActiveMQ hawtio, I can see that AMQP-ROUTE is a consumer of a Queue named TEST, while TCP-ROUTE is a subscriber to a Topic named TEST. route id=AMQP-ROUTE from uri=amqpConnection:topic://TEST?clientId=TestWithAMQPamp;durableSubscriptionName=TestDurSysAMQP / to uri=file:///foo/ /route route id=TCP-ROUTE from uri=tcpConnection:topic://TEST?clientId=TestWithTCPamp;durableSubscriptionName=TestDurSysTCP / to uri=file:///bar/ /route Did I do something wrong in specifying the Connection Factory or anything else? Is there a deficiency in Qpid or camel-amqp? Help! P.S. Is there any other/better way to specify an AMQP 1.0 JMS connection factory in Spring? I searched all over the web, but did not find any other examples. Thanks, Mark -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
Re: How to create case insensitive URI route with netty4-http?
On Thu, Apr 30, 2015 at 10:18 PM, hzariv hza...@ebay.com wrote:
You are right. I turn on debug logging and I see what is happening. I have
the following producer and consumer endpoints. Camel matches on the Consumer
endpoint correctly (case insensitive) but the producer URL is created like:
http://myapp.com:80/ws/svc/Shopping/shopping?callname=... (path is now
/Shopping/shopping which is invalid) when I use /shopping on the request the
producer URL is correct.
How do I fix this?
Consumer:
camelContext.getEndpoint(netty4-http:http://0.0.0.0:8080/Shopping;);
Producer:
camelContext.getEndpoint(String.format(netty4-http:http://%s:80/ws/svc/Shopping?throwExceptionOnFailure=false;,
myapp.com));
These 2 urls is not the same, one use port 8080, and the other port
80. And their context path is also different.
And its not clear what you do in your code. Do you do a consume -
produce and expect somehow Camel to match those endpoints?
Can you explain and show code better?
Hers is the DEBUG log:
11087 [Camel (camel-1) thread #0 - NettyEventExecutorGroup] INFO -
ID-D-SJC-00531208-50165-1430420447613-0-2 (route2)
from(http://0.0.0.0:8080/Shopping) -- choice Pattern:InOut,
Headers:{Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,
Accept-Encoding=gzip, deflate, Accept-Language=en-US,en;q=0.5, appid=,
breadcrumbId=ID-D-SJC-00531208-50165-1430420447613-0-1,
Cache-Control=max-age=0, callname=FindProducts, CamelHttpMethod=GET,
CamelHttpPath=/shopping,
CamelHttpQuery=callname=FindProductsresponseencoding=XMLappid=version=829QueryKeywords=MC723LLMaxEntries=2ProductSort=TitleIncludeSelector=DomainHistogramSortOrder=Ascending,
CamelHttpRawQuery=callname=FindProductsresponseencoding=XMLappid=version=829QueryKeywords=MC723LLMaxEntries=2ProductSort=TitleIncludeSelector=DomainHistogramSortOrder=Ascending,
CamelHttpUri=/shopping, CamelHttpUrl=http://0.0.0.0:8080/shopping,
CamelNettyChannelHandlerContext=io.netty.channel.DefaultChannelHandlerContext@3042dc22,
CamelNettyLocalAddress=/127.0.0.1:8080,
CamelNettyRemoteAddress=/127.0.0.1:50489, Connection=keep-alive,
Content-Length=0, Host=localhost:8080, If-Modified-Since=Thu, 30 Apr 2015
18:59:27 GMT, IncludeSelector=DomainHistogram, MaxEntries=2,
ProductSort=Title, QueryKeywords=MC723LL, responseencoding=XML,
SortOrder=Ascending, User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0)
Gecko/20100101 Firefox/37.0, version=829},
BodyType:org.apache.camel.component.netty4.http.NettyChannelBufferStreamCache,
Body:[Body is instance of org.apache.camel.StreamCache]
11128 [Camel (camel-1) thread #0 - NettyEventExecutorGroup] INFO -
ID-D-SJC-00531208-50165-1430420447613-0-2 (route2) choice --
http://myapp.com:80/ws/svc/Shopping Pattern:InOut,
Headers:{Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,
Accept-Encoding=gzip, deflate, Accept-Language=en-US,en;q=0.5, appid=,
breadcrumbId=ID-D-SJC-00531208-50165-1430420447613-0-1,
Cache-Control=max-age=0, callname=FindProducts, CamelHttpMethod=GET,
CamelHttpPath=/shopping,
CamelHttpQuery=callname=FindProductsresponseencoding=XMLappid=version=829QueryKeywords=MC723LLMaxEntries=2ProductSort=TitleIncludeSelector=DomainHistogramSortOrder=Ascending,
CamelHttpRawQuery=callname=FindProductsresponseencoding=XMLappid=version=829QueryKeywords=MC723LLMaxEntries=2ProductSort=TitleIncludeSelector=DomainHistogramSortOrder=Ascending,
CamelHttpUri=/shopping, CamelHttpUrl=http://0.0.0.0:8080/shopping,
CamelNettyChannelHandlerContext=io.netty.channel.DefaultChannelHandlerContext@3042dc22,
CamelNettyLocalAddress=/127.0.0.1:8080,
CamelNettyRemoteAddress=/127.0.0.1:50489, Connection=keep-alive,
Content-Length=0, Host=localhost:8080, If-Modified-Since=Thu, 30 Apr 2015
18:59:27 GMT, IncludeSelector=DomainHistogram, MaxEntries=2,
ProductSort=Title, QueryKeywords=MC723LL, responseencoding=XML,
SortOrder=Ascending, User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0)
Gecko/20100101 Firefox/37.0, version=829},
BodyType:org.apache.camel.component.netty4.http.NettyChannelBufferStreamCache,
Body:[Body is instance of org.apache.camel.StreamCache]
11129 [Camel (camel-1) thread #0 - NettyEventExecutorGroup] DEBUG -
Endpoint[http://myapp.com:80/ws/svc/Shopping] Exchange[Message: [Body is
instance of org.apache.camel.StreamCache]]
11138 [Camel (camel-1) thread #0 - NettyEventExecutorGroup] DEBUG - Created
new TCP client bootstrap connecting to myapp.com:80 with options:
Bootstrap(group: NioEventLoopGroup, channelFactory: NioSocketChannel.class,
options: {SO_KEEPALIVE=true, TCP_NODELAY=true, SO_REUSEADDR=true,
CONNECT_TIMEOUT_MILLIS=1}, handler:
org.apache.camel.component.netty4.http.HttpClientInitializerFactory@765b53f)
11167 [Camel (camel-1) thread #0 - NettyEventExecutorGroup] DEBUG - Creating
connector to address: myapp.com:80
11169 [Camel (camel-1) thread #0 - NettyEventExecutorGroup] DEBUG - Channel:
[id: 0xae58aab0,
metadata for components, processors etc
Is there any mechanism for specifying metadata that describes what inputs and outputs components, processors ... can consume/produce. I'm thinking of this from the perspective of a GUI builder tool that allows a route to be assembled so for this it's necessary to know which nodes are compatible with others. For instance if one produces bananas then it can't be directly piped into one that consumes oranges (of course TypeConverters need to be considered here). For instance, is there an existing mechanism for providing @Consumes and @Produces annotations on components, processors etc. Same question for routes, but I suspect that's much the same question. Tim
Webservice proxy - ActiveMq Deadletter Queue
Team, My requirement is as follows, 1) Webservice proxy just want to listen the request and put the message into one(request) queue. 2) From the request queue message has to deliver(auto) to end point. 3) If any case failover(end point unavailable,ect,..) message has to retain into dead letter queue. 4) Once end point is up message has to move(manual) from dead letter queue to request queue. Please guide me on this requirement or if you share me any clue also greatful.. Regards Jayendran -- View this message in context: http://camel.465427.n5.nabble.com/Webservice-proxy-ActiveMq-Deadletter-Queue-tp5766571.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: metadata for components, processors etc
Hi No the components / endpoints dont provide meta-data what java types and data formats they support. However we may get there in the longer run. There is a JIRA ticket about this idea. And with the recent component doc enhancements we have an instrument to provide the details. So end users can annotate the endpoints with the details, and then you can get that information at both design time for tooling, and at runtime etc. On Fri, May 1, 2015 at 9:35 AM, Tim Dudgeon tdudgeon...@gmail.com wrote: Is there any mechanism for specifying metadata that describes what inputs and outputs components, processors ... can consume/produce. I'm thinking of this from the perspective of a GUI builder tool that allows a route to be assembled so for this it's necessary to know which nodes are compatible with others. For instance if one produces bananas then it can't be directly piped into one that consumes oranges (of course TypeConverters need to be considered here). For instance, is there an existing mechanism for providing @Consumes and @Produces annotations on components, processors etc. Same question for routes, but I suspect that's much the same question. Tim -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
Re: Comparison of Apache Camel and IBM Integration Bus v9.0
I absolutely agree. I do mention this in my blog post. And if you read my second post I mentioned I will be discussing things such as Camel + Apache Service Mix and other technologies. Also the point of the blog is really to offer people a comparison between both offerings, even though camel is not an ESB it shares many similar things to IB9, e.g. Patterins/Components/etc... so I want to dive deep into this. Not everyone needs an ESB and Camel is a great alternative IMO. I will make sure I update that statement to include Karaf/ServiceMix and ActiveMQ as well, just to make sure people aren't confused. Cheers -- View this message in context: http://camel.465427.n5.nabble.com/Comparison-of-Apache-Camel-and-IBM-Integration-Bus-v9-0-tp5766171p5766578.html Sent from the Camel - Users mailing list archive at Nabble.com.
