cometd vs jetty component
Hi there, I've just discovered the cometd component for Camel 2. Fantastic! However I wonder if the cometd's component interface should be regarded as a superset of the jetty component interface. I realise that the component's implementations may need to be different but I think that their interfaces are strongly related. For example the jetty component's handlers parameter perhaps should also apply to cometd. Implementing a security handler will apply equally to cometd. In addition the SSL configuration mechanisms look a little different. Thoughts? Kind regards, Christopher -- View this message in context: http://www.nabble.com/cometd-vs-jetty-component-tp24916396p24916396.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
errorHandlerRef - camel route vs camel context
Hi, I would like to know if camel behavior is different when attribute errorHandlerRef is defined at the level of camelContext instead of camelRoute ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com
Re: errorHandlerRef - camel route vs camel context
Yeah, the scope of the error handler is different in those two cases. When added to the camelContext, it applies to all routes in the context. When applied to a single route, it only applies to that route. On Tue, Aug 11, 2009 at 10:10 AM, Charles Moulliard cmoulli...@gmail.comwrote: Hi, I would like to know if camel behavior is different when attribute errorHandlerRef is defined at the level of camelContext instead of camelRoute ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com -- Cheers, Jon http://janstey.blogspot.com/
Re: errorHandlerRef - camel route vs camel context
I think I jumped the gun here... that was a bit obvious :) Charles, are you noticing other differences in behavior? On Tue, Aug 11, 2009 at 10:19 AM, Jon Anstey jans...@gmail.com wrote: Yeah, the scope of the error handler is different in those two cases. When added to the camelContext, it applies to all routes in the context. When applied to a single route, it only applies to that route. On Tue, Aug 11, 2009 at 10:10 AM, Charles Moulliard cmoulli...@gmail.comwrote: Hi, I would like to know if camel behavior is different when attribute errorHandlerRef is defined at the level of camelContext instead of camelRoute ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com -- Cheers, Jon http://janstey.blogspot.com/ -- Cheers, Jon http://janstey.blogspot.com/
multipart/x-mixed-replace and Jetty
Hi there, Has anyone tried streaming server content via the Jetty component and using multipart/x-mixed-replace content types? Indeed is this a viable mechanism to stream content via Camel? Thanks. Christopher -- View this message in context: http://www.nabble.com/multipart-x-mixed-replace-and-Jetty-tp24917059p24917059.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: errorHandlerRef - camel route vs camel context
Jon, During my holidays my colleague has made tests on transacted routes of our project. He noticed what he called some unstabilities in transaction behavior. In consequence, he changed the route definition (removing direct between routes and use queues, change propagation property for Spring Transaction from required to required_new between routes) in order to solve the problem. From my understanding of camel, what he reports to me cannot be related to the use of direct between routes but probably to potentially issues existing between Hibernate/Spring. Nevertheless, I asked this question to check if another parameters (used in transacted routes) could impact transaction handling. Question : If errorHandledRef reference used between the routes is the same, it can be defined at the level of the context instead of each route ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com On Tue, Aug 11, 2009 at 2:51 PM, Jon Anstey jans...@gmail.com wrote: I think I jumped the gun here... that was a bit obvious :) Charles, are you noticing other differences in behavior? On Tue, Aug 11, 2009 at 10:19 AM, Jon Anstey jans...@gmail.com wrote: Yeah, the scope of the error handler is different in those two cases. When added to the camelContext, it applies to all routes in the context. When applied to a single route, it only applies to that route. On Tue, Aug 11, 2009 at 10:10 AM, Charles Moulliard cmoulli...@gmail.comwrote: Hi, I would like to know if camel behavior is different when attribute errorHandlerRef is defined at the level of camelContext instead of camelRoute ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com -- Cheers, Jon http://janstey.blogspot.com/ -- Cheers, Jon http://janstey.blogspot.com/
Re: errorHandlerRef - camel route vs camel context
On Tue, Aug 11, 2009 at 10:42 AM, Charles Moulliard cmoulli...@gmail.comwrote: Jon, During my holidays my colleague has made tests on transacted routes of our project. He noticed what he called some unstabilities in transaction behavior. In consequence, he changed the route definition (removing direct between routes and use queues, change propagation property for Spring Transaction from required to required_new between routes) in order to solve the problem. From my understanding of camel, what he reports to me cannot be related to the use of direct between routes but probably to potentially issues existing between Hibernate/Spring. Nevertheless, I asked this question to check if another parameters (used in transacted routes) could impact transaction handling. Yeah, from my understanding in order to avail of transactions you need to use transaction enabled endpoints like JPA/JMS. Question : If errorHandledRef reference used between the routes is the same, it can be defined at the level of the context instead of each route ? I haven't looked at the code but I would say yes. If this is not the case, we probably need to fix it :) Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com On Tue, Aug 11, 2009 at 2:51 PM, Jon Anstey jans...@gmail.com wrote: I think I jumped the gun here... that was a bit obvious :) Charles, are you noticing other differences in behavior? On Tue, Aug 11, 2009 at 10:19 AM, Jon Anstey jans...@gmail.com wrote: Yeah, the scope of the error handler is different in those two cases. When added to the camelContext, it applies to all routes in the context. When applied to a single route, it only applies to that route. On Tue, Aug 11, 2009 at 10:10 AM, Charles Moulliard cmoulli...@gmail.comwrote: Hi, I would like to know if camel behavior is different when attribute errorHandlerRef is defined at the level of camelContext instead of camelRoute ? Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com -- Cheers, Jon http://janstey.blogspot.com/ -- Cheers, Jon http://janstey.blogspot.com/ -- Cheers, Jon http://janstey.blogspot.com/
Re: anyone have AMQ VirtualTopic's working in Camel Test?
Hi,
Looks like you used the little snippet I sent in an as-is mode. I intended
this to be an example.
In any case, you could use something like this in your broker
broker xmlns=http://activemq.apache.org/schema/core;
destinationInterceptors
virtualDestinationInterceptor
virtualDestinations
compositeTopic name=MY.TOPIC
forwardTo
topic physicalName=BAR /
/forwardTo
/compositeTopic
/virtualDestinations
/virtualDestinationInterceptor
/destinationInterceptors
/broker
Notice in this example that the real queue is a queue named FOO and a real
topic is a topic named BAR.
Your consumers should listen on the topic named BAR and your clients should
send to the topi named MY.TOPIC which is a virtual topic.
All messages sent to MY.TOPIC will be forwarded to subscribers to the topic
named BAR.
Hope this clarifies things. My previous example showed a virtual topic which
had a second level of indirection to a collection of topics which in turn
may have been connected to real topics.
Cheers,
Ashwin...
Mick Knutson-3 wrote:
I changed the Topic to *activemq:VirtualTopic.TEST* and the consumer queue
to *activemq:Consumer.A.VirtualTopic.TEST*
I see that the MDP and Topic get created:
[myproject] DEBUG [main]
DefaultInstrumentationAgent.registerMBeanWithServer(293) | Registered
MBean
with objectname:
org.apache.camel:context=mick-knutsons-macbook.local/camel-2,type=processors,nodeid=to1,name=
*To[activemq:VirtualTopic.TEST]*
[myproject] DEBUG [main] DefaultComponentResolver.resolveComponent(77) |
Found component: activemq via type:
org.apache.activemq.camel.component.ActiveMQComponent via:
META-INF/services/org/apache/camel/component/activemq
*[myproject] DEBUG [main] DefaultComponent.createEndpoint(77) | Creating
endpoint uri=[activemq://VirtualTopic.TEST]*, path=[VirtualTopic.TEST],
parameters=[{}]
*[myproject] DEBUG [main] DefaultCamelContext.getEndpoint(387) |
activemq://VirtualTopic.TEST converted to endpoint:
Endpoint[activemq://VirtualTopic.TEST] by component:
org.apache.activemq.camel.component.activemqcompon...@47b7c1b7*
[myproject] DEBUG [main]
DefaultInstrumentationAgent.registerMBeanWithServer(293) | Registered
MBean
with objectname:
org.apache.camel:context=mick-knutsons-macbook.local/camel-2,type=endpoints,name=activemq://VirtualTopic.TEST\?id=0x5cab2ebd
[myproject] DEBUG [main] DefaultComponent.createEndpoint(77) | Creating
endpoint uri=[activemq://Consumer.A.VirtualTopic.TEST],
path=[Consumer.A.VirtualTopic.TEST], parameters=[{}]
*[myproject] DEBUG [main] DefaultCamelContext.getEndpoint(387) |
activemq://Consumer.A.VirtualTopic.TEST converted to endpoint:
Endpoint[activemq://Consumer.A.VirtualTopic.TEST] by component:
org.apache.activemq.camel.component.activemqcompon...@47b7c1b7*
[myproject] DEBUG [main]
DefaultInstrumentationAgent.registerMBeanWithServer(293) | Registered
MBean
with objectname:
org.apache.camel:context=mick-knutsons-macbook.local/camel-2,type=endpoints,name=activemq://Consumer.A.VirtualTopic.TEST\?id=0x561756a4
Each was converted to a AMQ Component. Is that correct?
The MDP gets initialized as the client gets initialized. Then AFTER the
client and server are both running, then I send a message to the server,
to
have the server create a message to the VirtualTopic.TEST
---
Thank You…
Mick Knutson, President
BASE Logic, Inc.
Enterprise Architecture, Design, Mentoring Agile Consulting
p. (866) BLiNC-411: (254-6241-1)
f. (415) 685-4233
Website: http://baselogic.com
Linked IN: http://linkedin.com/in/mickknutson
Vacation Rental: http://tahoe.baselogic.com
---
On Mon, Aug 10, 2009 at 6:12 PM, Willem Jiang
willem.ji...@gmail.comwrote:
According to AMQ's document
The out-of-the-box defaults are described above. Namely that the only
virtual topics available must be within the VirtualTopic. namespace and
that the consumer queues are named Consumer.*.VirtualTopic..
The support is out of box, and there is no addition configuration file
for
the unit test.
BTW, did you start to listen the Consumer.A.VirtualTopic.TEST queue
before
you send the message to VirtualTopic.TEST ?
Willem
Mick Knutson wrote:
I thought this was already PART of ActiveMQ not a rule that needed to be
added.
But then again, I am just using an embedded broker for these tests.
---
Thank You…
Mick Knutson, President
BASE Logic, Inc.
Enterprise Architecture, Design, Mentoring Agile Consulting
p. (866) BLiNC-411: (254-6241-1)
f. (415) 685-4233
Website: http://baselogic.com
Linked IN: http://linkedin.com/in/mickknutson
Vacation Rental: http://tahoe.baselogic.com
---
On Mon, Aug 10, 2009 at 2:20 PM, Ashwin Karpe aska...@progress.com
wrote:
Hi,
Do you have the rule for the virtual topic setup on the broker. I
wonder
if
this is the issue. This suspiciously sounds like the case. The virtual
Re: anyone have AMQ VirtualTopic's working in Camel Test?
I tried what you suggested with this Broker:
broker xmlns=http://activemq.apache.org/schema/core;
transportConnectors
transportConnector name=tcp uri=tcp://localhost:61616 /
/transportConnectors
destinationInterceptors
virtualDestinationInterceptor
virtualDestinations
*compositeTopic name=VirtualTopic.TEST*
forwardTo
*topic physicalName=Consumer.A.VirtualTopic.TEST
/*
/forwardTo
/compositeTopic
/virtualDestinations
/virtualDestinationInterceptor
/destinationInterceptors
/broker
And then I was sending messages to both the Topic, and the resulting que to
determin what was getting through:
//Send message to
producer.sendBody(body+XXX+body);
producer.sendBodyAndHeader(activemq:VirtualTopic.TEST,
body+body+body, foo, bar);
*producer.sendBodyAndHeader(activemq:Consumer.A.VirtualTopic.TEST,
body++body, foo, bar);*
But only the last message arrives at my MDP which is the one directly to the
Consumer itself. The 1st 2 did not arrive as expected:
*[myproject] INFO
[org.springframework.jms.listener.DefaultMessageListenerContainer#0-1]
StatusUpdateService.onMessage(17) | //-*
*--//*
*[myproject] INFO
[org.springframework.jms.listener.DefaultMessageListenerContainer#0-1]
StatusUpdateService.onMessage(18) | //-*
*--//*
*[myproject] INFO
[org.springframework.jms.listener.DefaultMessageListenerContainer#0-1]
StatusUpdateService.onMessage(19) | //-*
*--//*
*[myproject] INFO
[org.springframework.jms.listener.DefaultMessageListenerContainer#0-1]
StatusUpdateService.onMessage(20) | //-*
*--//*
*[myproject] INFO
[org.springframework.jms.listener.DefaultMessageListenerContainer#0-1]
StatusUpdateService.onMessage(21) | //-*
*--//*
*[myproject] INFO
[org.springframework.jms.listener.DefaultMessageListenerContainer#0-1]
StatusUpdateService.onMessage(22) | //-*
*--//*
*ActiveMQTextMessage {commandId = 5, responseRequired = true, messageId =
ID:L83601HY-3296-1250007358494-2:4:1:1:1, originalDestination = null,
originalTran*
*sactionId = null, producerId = ID:L83601HY-3296-1250007358494-2:4:1:1,
destination = queue://Consumer.A.VirtualTopic.TEST, transactionId = null,
expiration*
* = 0, timestamp = 1250007383823, arrival = 0, brokerInTime = 1250007383823,
brokerOutTime = 1250007383823, correlationId = null, replyTo = null,
persistent*
* = true, type = null, priority = 4, groupID = null, groupSequence = 0,
targetConsumerId = null, compressed = false, userID = null, content = null,
marshall*
*edProperties = org.apache.activemq.util.byteseque...@16d3536, dataStructure
= null, redeliveryCounter = 0, size = 0, properties = {foo=bar},
readOnlyProper*
*ties = true, readOnlyBody = true, droppable = false, text =
3333}*
I actually zipped up the source here:
http://baselogic.com/temp/services.zip
It should run on its own if you want to see my issue. I cd into the *
table-service-su* DIR and run:
mvn camel:run -e in one cmd prompt.
Then in another one, I run mvn verify -e to run the unit tests.
---
Thank You…
Mick Knutson, President
BASE Logic, Inc.
Enterprise Architecture, Design, Mentoring Agile Consulting
p. (866) BLiNC-411: (254-6241-1)
f. (415) 685-4233
Website: http://baselogic.com
Linked IN: http://linkedin.com/in/mickknutson
Vacation Rental: http://tahoe.baselogic.com
---
On Tue, Aug 11, 2009 at 10:33 AM, Ashwin Karpe aska...@progress.com wrote:
Hi,
Looks like you used the little snippet I sent in an as-is mode. I intended
this to be an example.
In any case, you could use something like this in your broker
broker xmlns=http://activemq.apache.org/schema/core;
destinationInterceptors
virtualDestinationInterceptor
virtualDestinations
compositeTopic name=MY.TOPIC
forwardTo
topic physicalName=BAR /
/forwardTo
/compositeTopic
/virtualDestinations
/virtualDestinationInterceptor
/destinationInterceptors
/broker
Notice in this example that the real queue is a queue named FOO and a real
topic is a topic named BAR.
Your consumers should listen on the topic named BAR and your clients should
send to the topi named MY.TOPIC which is a virtual topic.
All messages sent to MY.TOPIC will be forwarded to subscribers to the topic
named BAR.
Hope this clarifies things. My previous example showed a virtual topic
which
had a second level of indirection to a collection of topics which in turn
may have been connected to real topics.
Cheers,
Ashwin...
Mick
Camel File consumer and messages with the same file name
Hi there, I've got a configuration problem with ActiveMQ and Camel routing. Here's my route: route from uri=file:///C:/Input?delete=true/ convertBodyTo type=java.lang.String/ to uri=activemq:weather-info/ /route Everything works fine until the file names are not duplicated. When the duplication starts (and it starts after an hour because the files I receive are named that way) nothing else gets processed. Unfortunately I have no control over the generation of file names because it is an external system that generates them. I'm using ActiveMQ 5.2.0 as-is from the Apache ActiveMQ download site (meaning with Camel 1.5.0). Thanks in advance, Matthias. -- View this message in context: http://www.nabble.com/Camel-File-consumer-and-messages-with-the-same-file-name-tp24924475p24924475.html Sent from the Camel - Users mailing list archive at Nabble.com.
What to do with HTTP response when route from HTTP to JMS?
Hello,
I am trying to implement a simple application using Camel, which expose as
HTTP, then send a JMS message with the HTTP request data. My route is:
from(jetty:http://localhost:9080/myapp/myservice;).process(new Processor()
{
public void process(Exchange exchange) {
HttpServletRequest req =
exchange.getIn().getBody(HttpServletRequest.class);
String payload = req.getParameter(payload);
exchange.getOut().setBody(payload);
}
}).to(jms:queue:some.test.queue);
When I run the application, my client which sends http request would fail:
org.apache.camel.ExchangeTimedOutException: The OUT message was not received
within: 2 millis on the exchange
I think it is because exchange.out is redirected to JMS. But how to send a
http response with 200 status code after successfully sending the JMS
message?
Thanks a lot.
--
View this message in context:
http://www.nabble.com/What-to-do-with-HTTP-response-when-route-from-HTTP-to-JMS--tp24924548p24924548.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How to create a Servlet component?
Hi, Can you show me the camel-config.xml? A simple demo help me debug the issue. Willem janylj wrote: willem.jiang wrote: If you create the servlet component, you need to specify the servlet which the component will attach to. bean id=servlet class=org.apache.camel.component.servlet.ServletComponent property name=camelContext ref=camel / property name=servletName value=CamelServlet / /bean doesn't work, because Tomcat starts error said, Caused by: org.springframework.beans.InvalidPropertyException: Invalid property 'servletName' of bean class [org.apache.camel.component.servlet.ServletComponent]: No property 'servletName' found willem.jiang wrote: You don't need to specify the servlet component in spring, if there is only one camel servlet created in the web context. doesn't work, because Tomcat starts error said, Caused by: java.lang.IllegalArgumentException: Can't find the deployied servlet, please set the ServletComponent with it or delopy a CamelHttpTransportServlet int the web container What I am missing? Please note that I am using Spring ContextLoaderListener. Thanks a lot. my web.xml, !-- location of spring xml files -- context-param param-namecontextConfigLocation/param-name param-valueclasspath:camel-config.xml/param-value /context-param !-- the listener that kick-starts Spring -- listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener servlet servlet-nameCamelServlet/servlet-name servlet-class org.apache.camel.component.servlet.CamelHttpTransportServlet /servlet-class init-param param-namematchOnUriPrefix/param-name param-valuetrue/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameCamelServlet/servlet-name url-pattern/services/*/url-pattern /servlet-mapping
Re: What to do with HTTP response when route from HTTP to JMS?
Hi,
Did you just want to send the InOnly exchange (which will not wait for
the response from the queue) to the JMS queue ?
If so , you can define the route rule like this
from(jetty ).process(...).inOnly().to(jms:queue)
then your client will not receive the ExchangeTimedOutException.
Willem
janylj wrote:
Hello,
I am trying to implement a simple application using Camel, which expose as
HTTP, then send a JMS message with the HTTP request data. My route is:
from(jetty:http://localhost:9080/myapp/myservice;).process(new Processor()
{
public void process(Exchange exchange) {
HttpServletRequest req =
exchange.getIn().getBody(HttpServletRequest.class);
String payload = req.getParameter(payload);
exchange.getOut().setBody(payload);
}
}).to(jms:queue:some.test.queue);
When I run the application, my client which sends http request would fail:
org.apache.camel.ExchangeTimedOutException: The OUT message was not received
within: 2 millis on the exchange
I think it is because exchange.out is redirected to JMS. But how to send a
http response with 200 status code after successfully sending the JMS
message?
Thanks a lot.
