I am testing this Camel route:
from("direct:start")
.setHeader(Exchange.HTTP_METHOD, constant("GET"))
.to("http://127.0.0.1:8088/")
.to("mock:result");
...using this mock server:
mockServer = MockRestServiceServer.createServer(new RestTemplate());
mockServer.expect(
requestTo("http://127.0.0.1:8088/"))
.andExpect(method(HttpMethod.GET))
.andRespond(withStatus(HttpStatus.OK)
.contentType(MediaType.APPLICATION_JSON)
.body("")
);
...but receive:
I/O exception (java.net.ConnectException) caught when processing request: Connection refused: connect
Are there anything obvious I am missing? How can I proceed to find the cause?
You cannot use MockRestServiceServer. This does not start real server and therefore can be used only for mocking responses to Spring RestTemplate. Apache Camel does not utilize RestTemplate for sending requests, it uses Apache HttpClient.
You can either:
Advice your http endpoint with mock endpoint - preferred way. Example using isMockEndpointsAndSkip eg here: camel mock - MockEndpoint.whenAnyExchangeReceived process method not execute
Or start any full Http server in your unit test - For this you can extend HttpServerTestSupport containing some prepared methods - example HttpBodyTest
Related
I'm trying to run a simple test with Apache Camel:
from("http://localhost:61554/api/v1/MyController/my-endpoint")
.to("direct:a")
.log("$({body}");
I'm getting the following error: "No endpoint could be found for: http://localhost:61554/api/v1/MyController/my-endpoint, please check your classpath contains the needed Camel component jar"
I'm very new to Camel and Java. Can someone please tell me why this error is coming up? Should I be using from("direct:x")... ? If, so where do I map my "direct" endpoints to concrete ones?
Thanks
You cannot use the http component as consumer (eg in from) - its a http client for calling HTTP servers (so its a producer, eg to).
Instead to have HTTP as consumer you can use camel-servlet, camel-jetty, camel-undertow, etc.
We are using netty4-http as a client and have a problem when the server side answers with a http 100-Continue.
I expected the client to handle that internally and continue the call but it's actually returning http 100.
The test org.apache.camel.component.netty4.http.NettyHttpClientExpectContinueTest in the Camel code seems to test exactly that situation but it's ignored with the comment "TODO Fix it, need to send the response back". So I guess it has been a plan to implement it.
I'm new too Netty I wondering if it's possible to handle that in the Netty pipeline by overriding the ClientInitializerFactory (I found out it's the HttpObjectAggregator that returns 100)?
So any help how do achieve that in the Netty pipeline or any tips how to achieve that in some other way is welcome.
Is it possible to call an external api (RESTful) inside apache flink code. If it is possible then how we can do that.
I am calling an api from simple java code, it is working fine but when i use the same code in apache flink, it throws an exception :
java.io.IOException: Server returned HTTP response code: 500 for URL: http://example.com/someapi
Is it possible to call an external api (RESTful) inside apache flink code. If it is possible then how we can do that.
You can use the Async I/O feature provided in Flink Streaming API. Flink’s Async I/O API allows users to use asynchronous request clients with data streams. More details and examples here.
java.io.IOException: Server returned HTTP response code: 500 for URL: http://example.com/someapi
This seems to non-flink error since the response is 500. Check the request headers/parameters that is being sent and verify if the http request is being properly created. Try some utilities like PostMan to test the API first.
I am using Camel as an Orchestration Engine.
clients sends HTTP request <-> CAMEL code <---- HTTP Req----- > external
server(s)
I am using HTTP4 Component (with default settings) for making HTTP Requests
to external server. I have quite a few http backends.
Right now the way we are making http calls to our backend is as follow:-
// The producer is created during app initialisation. This is actually done
via blueprint.xml
ProducerTemplate producer = camelContext.createProducerTemplate();
// Whenever I need to make a http call I am executing the below code with
URL set as something like:- "http4://order-api:8099/orders/v1/ordersearch/"
Exchange exchange = producer.request(URL, new Processor() {
#Override
public void process(Exchange exchange) throws Exception {
log.info("Executing the HTTP request : URL - " + URL + " Headers -
" + headers + " Body : " + body);
exchange.getIn().setHeaders(headers);
exchange.getIn().setBody(body);
}
});
The query I am having is:-
Does HTTP4 in the default setting camel uses some http connection
pooling while making a call to the external servers?
If yes Is there a way I can configure the connection pooling from
blueprint.xml?
I am using Camel 2.16.1 and the application is deployed in Karaf 3.0.5.
The http4 component use Apache HttpClient, which support pooling with the use of a HttpClientConnectionManager.
By default, camel uses a PoolingHttpClientConnectionManager which is configured with the properties connectionsPerRoute and maxTotalConnections.
If you want to have more control over this clientConnectionManager, you can provide your own implementation of org.apache.http.conn.HttpClientConnectionManager
See HttpClient connection manager
We're invoking a secured SOAP WebService using Camel CXF deployed in Fuse. In the client, we have configured TrustStore and Keystore as per the standard config. We're able to hit the server via Netscaler. The server is generating the response and sending it back to Netscaler.
When the response is received from Netscaler, it is encrypted and should be decrypted by Camel CXF. The decryption is not happening and on the client we get a parsing error since the response is all encrypted.
Any clues of what could be the problem ?
The only stackTrace that I see is that the message failed to parse because of the presence of Ctrl characters since the message is encrypted.
<http:conduit name="https.*">
<http:tlsClientParameters secureSocketProtocol="TLS">
<sec:keyManagers ref="keyManagersBean"/>
<sec:trustManagers ref="trustManagersBean"/>
</http:tlsClientParameters>
</http:conduit>
The keyManager and trustManager beans are created using a custom factory.
Also, could this issue be because apart from transport level encryption, we also need message level encryption ?
This problem was resolved. The issue was the the content was gzipped before being sent from NetScaler. Hence, after transport level decryption we could still see the headers but not the content. Adding a GZip in & fault interceptor on the CXF endpoint fixed the issue.