Re: how to test the restlet service without startup web containner manually
Hi,
How about use HttpUnit[1] to start a web container and using Spring to load the
camel context?
[1]http://httpunit.sourceforge.net/
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, October 29, 2013 at 1:09 PM, CamelTyro wrote:
Hello
I met a problem when testing the restlet service, I config my restlet
service by adding the following snippet in web.xml (http://web.xml):
servlet
servlet-nameRestletServlet/servlet-name
servlet-classorg.restlet.ext.spring.SpringServerServlet/servlet-class
init-param
param-nameorg.restlet.component/param-name
param-valueRestletComponent/param-value
/init-param
/servlet
servlet-mapping
servlet-nameRestletServlet/servlet-name
url-pattern/rs/*/url-pattern
/servlet-mapping
Then I config the router by using camel:restlet component by
restlet:/cis/querypatientInfo/{code}?restletMethods=post,get
I can access the service throught the url e.g.
http://localhost:58080/myproject/rs/cis/querypatientInfo/634062 via browser
The question is how can I test it by junit , without manually startup the
web containner, does everybody met this problem? please provide me how to
resolve it.
Thanks sincerely.
--
View this message in context:
http://camel.465427.n5.nabble.com/how-to-test-the-restlet-service-without-startup-web-containner-manually-tp5742339.html
Sent from the Camel - Users mailing list archive at Nabble.com
(http://Nabble.com).
RE: Cannot stop inputstream during ftp transfer
I do not understand what the problem is. Within a few years used to. For 20 seconds, the system waits for the successful outcome of the process. After 20 seconds, the process has not stopped. Aborting closing Endpoint. Component throws an exception I/O or NPE. Rollback transaction and original file. At this point the process of safely (emergency) stops. I have a process reads from the ftp site a lot of large files. I use RoutePolicy. Put time routeStopGracePeriod = 10 seconds. The operation stops for 17 seconds. 15:50:00,001 | DefaultShutdownStrategy | Starting to graceful shutdown 1 routes (timeout 1 milliseconds) 15:50:10,002 | DefaultShutdownStrategy | Timeout occurred. Now forcing the routes to be shutdown now. 15:50:10,002 | DefaultShutdownStrategy | Interrupted while waiting during graceful shutdown, will force shutdown now. 15:50:10,003 | DefaultShutdownStrategy | Route: exchangeDocReadRoute shutdown complete, was consuming from: Endpoint[ftp:...] 15:50:17,614 | DefaultShutdownStrategy | Graceful shutdown of 1 routes completed in 17 seconds 15:50:17,614 | BlueprintCamelContext | Route: exchangeDocReadRoute is stopped, was consuming from: Endpoint[ftp:...] 15:50:18,587 | FtpConsumer | Error processing file RemoteFile[...] -- View this message in context: http://camel.465427.n5.nabble.com/Cannot-stop-inputstream-during-ftp-transfer-tp5719356p5742342.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: how to test the restlet service without startup web containner manually
Must I startup a web container -- View this message in context: http://camel.465427.n5.nabble.com/how-to-test-the-restlet-service-without-startup-web-containner-manually-tp5742339p5742343.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: HTTP Basic Authentication
I did a quick test with the camel trunk ( I think it’s same with last camel
release 2.12.1), the HTTP Basic Authentication setting is work out of box.
from(direct:endpoint).to(http://localhost:8081?authMethod=BasicauthUsername=user1authPassword=pwd”);
I think you need to double check if the authPassword setting, It should be a
plaint text.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, October 29, 2013 at 1:03 AM, martin11 wrote:
Hi Christian,
I tried to use HTTP auth options:
.to(http://{{server}}:{{port}}/{{address}}?authMethod=BasicauthUsername={{user}}authPassword={{password}};)
But it fails again:
INFO - Basic authentication scheme selected
DEBUG - Took 1889 millis to send to:
Endpoint[http://172.24.40.110:5985/wsman?authMethod=BasicauthPassword=**authUsername=Administrator]
INFO - basic authentication scheme selected
INFO - No credentials available for BASIC 'WSMAN'@172.24.40.110:5985
DEBUG - Took 45 millis to send to: Endpoint[http://172.24.40.110:5985/wsman]
ERROR - Failed delivery for (MessageId: ID-asgard-47899-1382979475336-0-11
on ExchangeId: ID-asgard-47899-1382979475336-0-9). Exhausted after delivery
attempt: 1 caught:
org.apache.camel.component.http.HttpOperationFailedException: HTTP operation
failed invoking http://172.24.40.110:5985/wsman with statusCode: 401
--
View this message in context:
http://camel.465427.n5.nabble.com/HTTP-Basic-Authentication-tp5742229p5742320.html
Sent from the Camel - Users mailing list archive at Nabble.com
(http://Nabble.com).
Re: HL7 v3
Maybe IPF which is based on camel can answer your question. http://repo.openehealth.org/sites/ipf/manuals/ipf-2.5-rc2/IPF%20reference%20-%20multi.html -- View this message in context: http://camel.465427.n5.nabble.com/HL7-v3-tp5732915p5742346.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: HTTP Basic Authentication
I just captured the http request and response and found some thing interesting.
When camel-http send the request to back end server which is protected with
HTTP Basic Authentication,
HttpClient sends a request without Authentication inform first, then it sends
the request with the Authentication header when it get the 401 response.
If you just want to camel-http send the request with the Authentication header,
you can set url like this.
from(direct:endpoint).to(http://localhost:8081?authMethod=BasicauthUsername=user1authPassword=pwdhttpClient.authenticationPreemptive=true;);
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, October 29, 2013 at 5:13 PM, Willem jiang wrote:
I did a quick test with the camel trunk ( I think it’s same with last camel
release 2.12.1), the HTTP Basic Authentication setting is work out of box.
from(direct:endpoint).to(http://localhost:8081?authMethod=BasicauthUsername=user1authPassword=pwd”);
I think you need to double check if the authPassword setting, It should be a
plaint text.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, October 29, 2013 at 1:03 AM, martin11 wrote:
Hi Christian,
I tried to use HTTP auth options:
.to(http://{{server}}:{{port}}/{{address}}?authMethod=BasicauthUsername={{user}}authPassword={{password}};)
But it fails again:
INFO - Basic authentication scheme selected
DEBUG - Took 1889 millis to send to:
Endpoint[http://172.24.40.110:5985/wsman?authMethod=BasicauthPassword=**authUsername=Administrator]
INFO - basic authentication scheme selected
INFO - No credentials available for BASIC 'WSMAN'@172.24.40.110:5985
DEBUG - Took 45 millis to send to: Endpoint[http://172.24.40.110:5985/wsman]
ERROR - Failed delivery for (MessageId: ID-asgard-47899-1382979475336-0-11
on ExchangeId: ID-asgard-47899-1382979475336-0-9). Exhausted after delivery
attempt: 1 caught:
org.apache.camel.component.http.HttpOperationFailedException: HTTP operation
failed invoking http://172.24.40.110:5985/wsman with statusCode: 401
--
View this message in context:
http://camel.465427.n5.nabble.com/HTTP-Basic-Authentication-tp5742229p5742320.html
Sent from the Camel - Users mailing list archive at Nabble.com
(http://Nabble.com).
Re: HTTP Basic Authentication
You'll be surprised. CXF uses the same library Apache HttpComponents. CXF client initially twice sends an HTTP request. The first request without authorization. Second with authorization. For a GET request such behavior is acceptable. For a POST request is very bad. Aleksey -- View this message in context: http://camel.465427.n5.nabble.com/HTTP-Basic-Authentication-tp5742229p5742348.html Sent from the Camel - Users mailing list archive at Nabble.com.
RE: HTTP Basic Authentication
Hi, it happens by design: Generally, preemptive authentication can be considered less * secure than a response to an authentication challenge * and therefore discouraged. (see https://hc.apache.org/httpcomponents-client-4.3.x/httpclient/examples/org/apache/http/examples/client/ClientPreemptiveBasicAuthentication.java) Regards, Tom -Original Message- From: alexey-s [mailto:alex...@mail.ru] Sent: Dienstag, 29. Oktober 2013 11:47 To: users@camel.apache.org Subject: Re: HTTP Basic Authentication You'll be surprised. CXF uses the same library Apache HttpComponents. CXF client initially twice sends an HTTP request. The first request without authorization. Second with authorization. For a GET request such behavior is acceptable. For a POST request is very bad. Aleksey -- View this message in context: http://camel.465427.n5.nabble.com/HTTP-Basic-Authentication-tp5742229p5742348.html Sent from the Camel - Users mailing list archive at Nabble.com.
Is it better to use PooledConnectionFactory in Parallel Processing
Hi, Previously we are using ActiveMQConnectionFactory alone, and we observed that while starting the JBoss Server ActiveMQ is creating multiple threads and closing (ActiveMQ Task 1, ActiveMQ Task 2, ...), we thought it creating multiple connections/session are creating and closing. As a resolution, we want to use PooledConnectionFactory 1) We are using Camel Routes to prepare and send messages to destination, we invoke 7 routes and each route configured with parallel processing (Min value is 5 and max value is 25 threads), daily we process around 3 Lakh Messages (= 300.000) and All Routes are TRANSACTED. In Parallel Processing Is it better to use PooledConnectionFactory? For Each Message PooledConnectionFactory create one session (or) Session object will be shared by Multiple messages? -- View this message in context: http://camel.465427.n5.nabble.com/Is-it-better-to-use-PooledConnectionFactory-in-Parallel-Processing-tp5742350.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-cxf and activemq example
NObody is responding in that thread. https://community.jboss.org/thread/233981 Any other place where my qs can be answered? -- View this message in context: http://camel.465427.n5.nabble.com/camel-cxf-and-activemq-example-tp5742069p5742351.html Sent from the Camel - Users mailing list archive at Nabble.com.
HTTP: how to handle status code 500?
hello, we are using http4 with camel 2.12.1, posting soap to an external party. However, the external party seems to exaggerate(?) the usage of REST and return a status code 500 when our request is not supported. When using e.g. postman in chrome, I can see that a response is given with the 500 which in detail describes the error cause. This response seems to be discarded by the http4-component, though. Any chance of handling that 500 status code without throwing the exception as shown below? response given with 500 (but not seen in Camel stacktrace): ?xml version=1.0 ? S:Envelope xmlns:S=http://www.w3.org/2003/05/soap-envelope; S:Body S:Fault xmlns:ns4=http://schemas.xmlsoap.org/soap/envelope/; S:Code S:ValueS:Receiver/S:Value /S:Code S:Reason S:Text xml:lang=enFailed to process the request./S:Text /S:Reason S:Detail. /S:Detail /S:Fault /S:Body /S:Envelope stacktrace: org.apache.camel.component.http4.HttpOperationFailedException: HTTP operation failed invoking http://acme.com:80/xmlapi/shop/air/v2 with statusCode: 500 at org.apache.camel.component.http4.HttpProducer.populateHttpOperationFailedException(HttpProducer.java:237) ~[camel-http4-2.12.1.jar:2.12.1] at org.apache.camel.component.http4.HttpProducer.process(HttpProducer.java:165) ~[camel-http4-2.12.1.jar:2.12.1] at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:110) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.Pipeline.process(Pipeline.java:118) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.Pipeline.process(Pipeline.java:80) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:105) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.component.jms.EndpointMessageListener.onMessage(EndpointMessageListener.java:103) ~[camel-jms-2.12.1.jar:2.12.1] at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:562) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:500) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:468) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1103) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1095) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:992) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25] -- View this message in context: http://camel.465427.n5.nabble.com/HTTP-how-to-handle-status-code-500-tp5742353.html Sent from the Camel - Users mailing list archive at Nabble.com.
RE: HTTP Basic Authentication
Rules of the game sets the other side - http server. Two requests are always bad, whether it's on an external authentication server, or proxy server. It is necessary to send a file size of 1 MByte. Length of HTTP request is about 1.3 MByte. Two queries will give 2.6 MByte. Aleksey -- View this message in context: http://camel.465427.n5.nabble.com/HTTP-Basic-Authentication-tp5742229p5742354.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel Splitter slowness problem
alexey-s wrote Use cache JAXBContext or Marshaller/Unmarshaller in local beans. Sample: private SoftReference Unmarshaller refUnmarshaller; Or sample (use Google Guava): Started off on your lines but, found out that by changing the input file format from abc.out file to abc.txt greatly improved the speed of processing(earlier it took 5 hrs, writing only some KB/sec, but now the same file is processed in 800 sec). Unsure of why such a thing could happen. Next, will be implementing soft reference to further improve the performance. -- View this message in context: http://camel.465427.n5.nabble.com/Camel-Splitter-slowness-problem-tp5742307p5742355.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Request-Reply a second route
Any particular reason why you're using message ID as correlationID == true? Also, the exchange pattern would be InOut, so you don't need to explicitly send the message to tpms_from_iccs I have written a unit test that passes; you should take a look at it here: https://github.com/christian-posta/camel-sandbox/blob/master/camel-2.12.1-issues/src/test/java/posta/NestedJmsReqReplyTest.java On Fri, Oct 25, 2013 at 7:06 AM, Gabriel gabriel.wetz...@unitybox.de wrote: Hello, I have a route which proxies another route with a web-service like this (1. Route:): from(cxf:bean:TpmsWSEndpoint) .inOut(activemq:queue:tpms_sendTo_iccs?replyTo=tpms_from_iccsjmsMessageType=Text); The activemq:queue:tpms_sendTo_iccs queue is the beginning of an other route witch also have a request-reply request like so (2. Route:) from(activemq:queue:tpms_sendTo_iccs?useMessageIDAsCorrelationID=true). inOut(activemq:queue:iccs.request?jmsMessageType=Text). to(activemq:queue:tpms_from_iccs); I'm loosing all header at the inout call. The Message is processed succsessfully and resists in activemq:queue:tpms_from_iccs. The 1. Route gets an timeout exception. How can I fix that, any ideas? -- View this message in context: http://camel.465427.n5.nabble.com/Request-Reply-a-second-route-tp5742211.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Christian Posta http://www.christianposta.com/blog twitter: @christianposta
Re: HTTP: how to handle status code 500?
You can turn off the throw exception on failure with throwExceptionOnFailure=false but that will apply to all error codes. Otherwise you can use camel error handler to handle the http exception when its status code 500. Camel in Action chapter 5, section 5.5 covers that On Tue, Oct 29, 2013 at 2:04 PM, PJ Walstroem walst...@hotmail.com wrote: hello, we are using http4 with camel 2.12.1, posting soap to an external party. However, the external party seems to exaggerate(?) the usage of REST and return a status code 500 when our request is not supported. When using e.g. postman in chrome, I can see that a response is given with the 500 which in detail describes the error cause. This response seems to be discarded by the http4-component, though. Any chance of handling that 500 status code without throwing the exception as shown below? response given with 500 (but not seen in Camel stacktrace): ?xml version=1.0 ? S:Envelope xmlns:S=http://www.w3.org/2003/05/soap-envelope; S:Body S:Fault xmlns:ns4=http://schemas.xmlsoap.org/soap/envelope/; S:Code S:ValueS:Receiver/S:Value /S:Code S:Reason S:Text xml:lang=enFailed to process the request./S:Text /S:Reason S:Detail. /S:Detail /S:Fault /S:Body /S:Envelope stacktrace: org.apache.camel.component.http4.HttpOperationFailedException: HTTP operation failed invoking http://acme.com:80/xmlapi/shop/air/v2 with statusCode: 500 at org.apache.camel.component.http4.HttpProducer.populateHttpOperationFailedException(HttpProducer.java:237) ~[camel-http4-2.12.1.jar:2.12.1] at org.apache.camel.component.http4.HttpProducer.process(HttpProducer.java:165) ~[camel-http4-2.12.1.jar:2.12.1] at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:110) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.Pipeline.process(Pipeline.java:118) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.Pipeline.process(Pipeline.java:80) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:105) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.component.jms.EndpointMessageListener.onMessage(EndpointMessageListener.java:103) ~[camel-jms-2.12.1.jar:2.12.1] at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:562) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:500) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:468) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1103) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1095) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:992) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25] -- View this message in context:
RE: HTTP: how to handle status code 500?
Hi, add something like this to your route: onException(HttpOperationFailedException.class) .bean(routeErrorHandler) .end(); You can use .handled(true|false) or .continued() to further tune the exception handling. In our case, the routeErrorHandler is a spring bean, that uses XPath to process the error-response. Regards, Tom -Original Message- From: PJ Walstroem [mailto:walst...@hotmail.com] Sent: Dienstag, 29. Oktober 2013 14:05 To: users@camel.apache.org Subject: HTTP: how to handle status code 500? hello, we are using http4 with camel 2.12.1, posting soap to an external party. However, the external party seems to exaggerate(?) the usage of REST and return a status code 500 when our request is not supported. When using e.g. postman in chrome, I can see that a response is given with the 500 which in detail describes the error cause. This response seems to be discarded by the http4-component, though. Any chance of handling that 500 status code without throwing the exception as shown below? response given with 500 (but not seen in Camel stacktrace): ?xml version=1.0 ? S:Envelope xmlns:S=http://www.w3.org/2003/05/soap-envelope; S:Body S:Fault xmlns:ns4=http://schemas.xmlsoap.org/soap/envelope/; S:Code S:ValueS:Receiver/S:Value /S:Code S:Reason S:Text xml:lang=enFailed to process the request./S:Text /S:Reason S:Detail. /S:Detail /S:Fault /S:Body /S:Envelope stacktrace: org.apache.camel.component.http4.HttpOperationFailedException: HTTP operation failed invoking http://acme.com:80/xmlapi/shop/air/v2 with statusCode: 500 at org.apache.camel.component.http4.HttpProducer.populateHttpOperationFailedException(HttpProducer.java:237) ~[camel-http4-2.12.1.jar:2.12.1] at org.apache.camel.component.http4.HttpProducer.process(HttpProducer.java:165) ~[camel-http4-2.12.1.jar:2.12.1] at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:110) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.Pipeline.process(Pipeline.java:118) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.Pipeline.process(Pipeline.java:80) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:105) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87) ~[camel-core-2.12.1.jar:2.12.1] at org.apache.camel.component.jms.EndpointMessageListener.onMessage(EndpointMessageListener.java:103) ~[camel-jms-2.12.1.jar:2.12.1] at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:562) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:500) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:468) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1103) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1095) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:992) ~[spring-jms-3.2.4.RELEASE.jar:3.2.4.RELEASE] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25] at
Re: error handler for a seda producer doesn't work?
Great test case, thanks. This is a bug. Can you open a JIRA?
On Mon, Oct 28, 2013 at 10:31 AM, Keith Freeman 8fo...@gmail.com wrote:
I'm building my route like this:
//context.setTracing(true);
errorHandler(loggingErrorHandler(whatever).level(LoggingLevel.ERROR));
from(direct:start).log(start:
${body}).to(seda:seda1?size=2blockWhenFull=false).log(after: ${body});
When I run it and send it 3 messages the first 2 log ok (both start and
after), but the 3rd message (which fills the seda queue and throws a
Queue full exception) only shows up in a start log message, no
exception is shown or delivered to my test code, and the route just shuts
down with no ERROR log.
However if I uncomment context.setTracing(true), then the 3rd message
triggers my error handler and its whatever log message, along with a
stack trace, etc.
My understanding is that the errorHandler(...) call sets the error
handler for the entire context. So why doesn't it get triggered unless I
turn on tracing?
I've attached the entire junit-4 test.
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
Re: CFX-Bean:headers access Issue
On 22/10/13 15:06, Amit wrote: Would you please fixed this issue in 2.11.3 release. I've attached a patch on your behalf, https://issues.apache.org/jira/secure/attachment/12610872/camel6878.txt and hope the team will have no problems with applying it. thanks for spotting this minor issue; Cheers, Sergey -- View this message in context: http://camel.465427.n5.nabble.com/CFX-Bean-headers-access-Issue-tp5741312p5742030.html Sent from the Camel - Users mailing list archive at Nabble.com.
Message headers and HTTP
In my routes, I use custom message headers to keep track some data. But when one of the steps in the route is a HTTP call (for example calling a web services), all my headers are sent as HTTP headers to the remote HTTP server. This causes the remote HTTP server (which is not under my control) to return a HTTP 404. (One thing I noticed is that the remote HTTP server is perfectly OK with JMS headers, e.g. JMSXGroupID. It just does not like any custom message header that I define.) I know Camel lets me remove all the headers before going to the http endpoint. But I still need these header data once the http request completes. Any suggestion on how I can use http headers effectively in such situation? Is there an easy way I can stash away these headers and restore them after the http call? I tried to use Exchange properties to keep track of the data. But the data do not survive across routes. Thank you for your help! -- View this message in context: http://camel.465427.n5.nabble.com/Message-headers-and-HTTP-tp5742364.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: HTTP Basic Authentication
One thing should be point out, CXF uses Http URL Connector which is from JDK by default. If you are using CXF 2.7.x and enable the async http client setting, it will use the Apache Http Client 4.x to send the request. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Tuesday, October 29, 2013 at 6:46 PM, alexey-s wrote: You'll be surprised. CXF uses the same library Apache HttpComponents. CXF client initially twice sends an HTTP request. The first request without authorization. Second with authorization. For a GET request such behavior is acceptable. For a POST request is very bad. Aleksey -- View this message in context: http://camel.465427.n5.nabble.com/HTTP-Basic-Authentication-tp5742229p5742348.html Sent from the Camel - Users mailing list archive at Nabble.com (http://Nabble.com).
Re: Request-Reply a second route
I think it is depends how your route consume the message from the iccs.request queue. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Friday, October 25, 2013 at 10:06 PM, Gabriel wrote: Hello, I have a route which proxies another route with a web-service like this (1. Route:): from(cxf:bean:TpmsWSEndpoint) .inOut(activemq:queue:tpms_sendTo_iccs?replyTo=tpms_from_iccsjmsMessageType=Text); The activemq:queue:tpms_sendTo_iccs queue is the beginning of an other route witch also have a request-reply request like so (2. Route:) from(activemq:queue:tpms_sendTo_iccs?useMessageIDAsCorrelationID=true). inOut(activemq:queue:iccs.request?jmsMessageType=Text). to(activemq:queue:tpms_from_iccs); I'm loosing all header at the inout call. The Message is processed succsessfully and resists in activemq:queue:tpms_from_iccs. The 1. Route gets an timeout exception. How can I fix that, any ideas? -- View this message in context: http://camel.465427.n5.nabble.com/Request-Reply-a-second-route-tp5742211.html Sent from the Camel - Users mailing list archive at Nabble.com (http://Nabble.com).
Camel transacted route
Hello,
We have set up a Camel route using transacted(). The route comprises
multiple JDBC transactions and we required some kind of transaction
management to be implemented, we decided to use transacted().
The route looks like this :
from(direct:updatebookauthor).tracing()
.transacted(PROPAGATION_REQUIRED)
.convertBodyTo(BookShelf.class)
.enrich(direct:getbookauthor, new
BookShelfEnrichAggregationStrategy(Action.UPDATE))
.process(new DroolsCommandTransformerWork(work,
Work.class)).to(drools:node/ksession)
.transform().simple(${body.getValue('work').newContainer})
.bean(bookShelfRepo, update)
.choice()
.when(body().isNotNull())
.process(new BookCatgProcessor())
.choice()
.when(body().isNotNull())
.bean(bookShelfRepo,
updateBookDept)
.bean(bookShelfRepo,
updateBookCategory)
.end()
.choice()
.when(body().isNull())
.process(new
BookShelfProcessor())
.end()
.end()
.onException(Exception.class).markRollbackOnly();
Spring Transaction Policy Bean is created as follows:
private void setupTransactionPolicy() {
try{
Context initialContext = new InitialContext();
Context envContext = (Context)
initialContext.lookup(java:comp/env);
DataSource ds = (DataSource)
envContext.lookup(jdbc/us/wm/TraitsDs);
DataSourceTransactionManager dsm = new
org.springframework.jdbc.datasource.DataSourceTransactionManager(ds);
SpringTransactionPolicy stp = new
org.apache.camel.spring.spi.SpringTransactionPolicy(dsm);
stp.setPropagationBehaviorName(PROPAGATION_REQUIRED);
TraitHierarchyRoutes.PROPAGATION_REQUIRED_BEAN =
stp;
}catch(Exception e){
throw new RuntimeException(Exception while setting
up spring transaction policy + e);
}
}
Bean is bound to Camel Registry for referencing in the route.
JndiRegistry registry =
(JndiRegistry)((PropertyPlaceholderDelegateRegistry)this.getContext().getRegistry()).getRegistry();
registry.bind(PROPAGATION_REQUIRED,
PROPAGATION_REQUIRED_BEAN);
And the issue is that the Transaction Handling not happening and is rolling
back the transactions on exceptions.. We have tried with and with out
setting the auto commit property to true. Also, we have tried using the
transacted() alone with out onExceptionmarkRollBack. No luck. Please advice
!
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-transacted-route-tp5742362.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Message headers and HTTP
Use HeaderFilterStrategy to specify which headers should be sent with the http request. It will preserve the headers in the exchange Cheers, On 30 October 2013 01:27, bocamel johnz...@gmail.com wrote: In my routes, I use custom message headers to keep track some data. But when one of the steps in the route is a HTTP call (for example calling a web services), all my headers are sent as HTTP headers to the remote HTTP server. This causes the remote HTTP server (which is not under my control) to return a HTTP 404. (One thing I noticed is that the remote HTTP server is perfectly OK with JMS headers, e.g. JMSXGroupID. It just does not like any custom message header that I define.) I know Camel lets me remove all the headers before going to the http endpoint. But I still need these header data once the http request completes. Any suggestion on how I can use http headers effectively in such situation? Is there an easy way I can stash away these headers and restore them after the http call? I tried to use Exchange properties to keep track of the data. But the data do not survive across routes. Thank you for your help! -- View this message in context: http://camel.465427.n5.nabble.com/Message-headers-and-HTTP-tp5742364.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Bilgin Ibryam Apache Camel Apache OFBiz committer Blog: ofbizian.com Twitter: @bibryam https://twitter.com/bibryam Author of Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475
Re: Message headers and HTTP
You may wish to also check out the Enrich EIP. You can call into a route or external system, then aggregate the response however you'd like (keeping or discarding headers as you wish) http://camel.apache.org/content-enricher.html On Tue, Oct 29, 2013 at 7:17 PM, Bilgin Ibryam bibr...@gmail.com wrote: Use HeaderFilterStrategy to specify which headers should be sent with the http request. It will preserve the headers in the exchange Cheers, On 30 October 2013 01:27, bocamel johnz...@gmail.com wrote: In my routes, I use custom message headers to keep track some data. But when one of the steps in the route is a HTTP call (for example calling a web services), all my headers are sent as HTTP headers to the remote HTTP server. This causes the remote HTTP server (which is not under my control) to return a HTTP 404. (One thing I noticed is that the remote HTTP server is perfectly OK with JMS headers, e.g. JMSXGroupID. It just does not like any custom message header that I define.) I know Camel lets me remove all the headers before going to the http endpoint. But I still need these header data once the http request completes. Any suggestion on how I can use http headers effectively in such situation? Is there an easy way I can stash away these headers and restore them after the http call? I tried to use Exchange properties to keep track of the data. But the data do not survive across routes. Thank you for your help! -- View this message in context: http://camel.465427.n5.nabble.com/Message-headers-and-HTTP-tp5742364.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Bilgin Ibryam Apache Camel Apache OFBiz committer Blog: ofbizian.com Twitter: @bibryam https://twitter.com/bibryam Author of Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475 -- Christian Posta http://www.christianposta.com/blog twitter: @christianposta
Re: CamelBlueprintTestSupport Issues
Willem, When I stepped through debugger and set includeTestBundle to false I've got the following error: java.lang.RuntimeException: Gave up waiting for service ((objectClass=org.osgi.service.blueprint.container.BlueprintContainer)(osgi.blueprint.container.symbolicname=*MyTestBundle*)) at org.apache.camel.test.blueprint.CamelBlueprintHelper.getOsgiService(CamelBlueprintHelper.java:203) at org.apache.camel.test.blueprint.CamelBlueprintHelper.getOsgiService(CamelBlueprintHelper.java:169) at org.apache.camel.test.blueprint.CamelBlueprintTestSupport.getOsgiService(CamelBlueprintTestSupport.java:237) at org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:126) at com.obsglobal.partners.portland.routes.BaseRouteTester.setUp(BaseRouteTester.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Having said that I'm wondering if this would fix problem. Having two bundles with the same context is causing seemingly undeterministic behavior where mock endpoint assertions fail. This happens when mock:myUri handles received exchange in one context but assertions are run against injected mock:myUri endpoint but from another context. Andre -- View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-Issues-tp5741066p5742372.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Message headers and HTTP
bibryam, HeaderFilterStrategy worked out beautifully. I simply extended the CxfHeaderFilterStrategy. Thank you! -- View this message in context: http://camel.465427.n5.nabble.com/Message-headers-and-HTTP-tp5742364p5742374.html Sent from the Camel - Users mailing list archive at Nabble.com.
