The Message.getBody() method javadoc says,
Notice if the message body is stream based then....
So how do I check if the body is stream based? The check like this
Object body = exchange.getIn().getBody();
if (body instanceof InputStream) {
doesn't work for, say, files. I am writing a generic code and it should do certain things for incoming streams, and leave non-streaming objects intact, thus I am cautious to call
Object body = exchange.getIn().getBody(InputStream.class);
because I don't know what it will do with plain String or List or Integer etc.
There is no simple single check that covers 100% situations. Camel is open ended in terms of what payload format it supports and hence the message body is just a java.lang.Object. So to check if its streaming based, you need to check for streaming types such as `java.io.InputStream', but then you also have other types like files, and from 3rd party components that may have their own representation of streaming data.
Camel has built in stream caching (https://camel.apache.org/manual/latest/stream-caching.html) where it supports most streaming types and if you use that, then you can check if the body is an org.apache.camel.StreamCache instance.
Related
I have this simple route in my RouteBuilder.
from("amq:MyQueue").routeId(routeId).log(LoggingLevel.DEBUG, "Log: ${in.headers} - ${in.body}")
As stated in the doc for HTTP-component:
Camel will store the HTTP response from the external server on the OUT body. All headers from the IN message will be copied to the OUT message, ...
I would like to know if this concept also applies to amq-component, routeId, and log? Is it the default behaviour, that IN always gets copied to OUT?
Thank you,
Hadi
First of all: The concept of IN and OUT messages is deprecated in Camel 3.x.
This is mentioned in the Camel 3 migration guide and also annotated on the getOut method of the Camel Exchange.
However, it is not (yet) removed, but what you can take from it: don't care about the OUT message. Use the getMessage method and don't use getIn and getOut anymore.
To answer your question:
Yes, most components behave like this
Every step in the route takes the (IN) message and processes it
The body is typically overwritten with the new processing result
The headers typically stay, new headers can be added
So while the Camel Exchange traverses the route, typically the body is continuously updated and the header list grows.
However, some components like aggregator create new messages based on an AggregationStrategy. In such cases nothing is copied automatically and you have to implement the strategy to your needs.
I want two consumer with single activemq queue and wanted to filter while consuming. Selective is best option for me (please suggest if there is other). But sender does not sending me any header parameter or any property, selective only works with header or properties, now I wanted to filter message on message body . Is there any way to use selective with message body
My two messages body are differed by test and test2
{
"test":{
"abc":"123",
"cde":"123"
}
}
{
"test2":{
"abc":"321",
"cde":"321"
}
}
I want something like selective with message body
from("jms:selective?selector=" + java.net.URLEncoder.encode(${body.test})).
to("cxf:bean:replica01");
from("jms:selective?selector=" + java.net.URLEncoder.encode(${body.test2})).
to("cxf:bean:replica02");
Please suggest if there is any way to do so.
As the selector documentation for ActiveMQ 5.x points out, you can use XPath based selectors for messages which have XML bodies. However, the bodies of your messages aren't XML so there doesn't appear to be anyway to get the functionality you're looking for.
Keep in mind that as far as the broker is concerned the body of a message is just an array of bytes whereas message headers/properties are typed which allows for the kinds of comparison operations that make selectors viable.
My current application is a toy web service written in C designed to replicate the behaviour of http://sprunge.us/ (takes data in via http POST, stores it to disk, returns the client a url to the data - also serves data that has been previously stored upon request).
The application is structured such that a thread pool is instantiated with worker threads (just a function pointer that takes a void* parameter) and a socket is opened to listen to incoming connections. The main loop of the program comprises a sock = accept(...) call and then a pool_add_task(worker_function_parse_http, sock) to enable requests to be handled quickly.
The parse_http worker parses the incoming request and either adds another task to the work queue for storing the data (POST) or serving previously stored data (GET).
My problem with this approach stems from the use of the http-parser library which uses a callback design to return parsed data (all http parsers that I looked at used this style). The problem I encounter is as such:
My parse_http worker:
Buffers data from the accepted socket (the function's only parameter, at this stage)
Sets up a http-parser object as per its API, complete with setting callback functions for it to call when it finishes parsing the URL or BODY or whatever. (These functions are of a fixed type signature defined by the http-parser lib, with a pointer to a buffer containing the parsed data relevant to the call, so I can't pass in my own variables and solve the problem that way. These functions also return a status code to the http parser, so I can't use the return values either. The suggested way to get data out of the parser for later use is to copy it out to a global variable during the callback - fun with multiple threads.)
Execute the parser on the buffered socket data. At this stage, the parser is expected to call its set up callbacks when it parses different sections of the buffer. The callback is supplied with parsed data relevant to each callback (e.g. BODY segment supplied to body_parsed callback function).
Well, this is where the problem shows. The parser has executed, but I don't have any access to the parsed data. Here is where I would add a new task to the queue with a worker function to store the received body data or another to handle the GET request for previously stored data. These functions would need to be supplied with both the parsed information (POST data or GET url) as well as the accepted socket so that the now delegated work can respond to the request and close the connection.
Of course, the obvious solution to the problem is simply to not use this thread-pool model with asynchronous practices, but I would like to know, for now and for later, how best to tackle this problem.
How can I get the parsed data from these callbacks back to the worker thread function. I've considered simply making my on_url_parsed and on_body_parsed do the rest of the application's job (storing and retrieving data), but of course I no longer have the client's socket to respond back to in these contexts.
If needed, I can post up the source code to the project when I get the chance.
Edit: It turns out that it is possible to access a user defined void * from within the callbacks of this particular http-parser library as the callbacks are passed a reference to the caller (the parser object) which has a user-definable data field.
A well-designed callback interface would provide for you to give the parser a void * which it would pass on to each of the callback functions when it calls them. The callback functions you provide know what type of object it points to (since you provide both the data pointer and the function pointers), so they can cast and properly dereference it. Among other advantages, this way you can provide for the callbacks to access a local variable of the function that initiates the parse, instead of having to rely on global variables.
If the parser library you are using does not have such a feature (and you don't want to switch to a better-designed one), then you can probably use thread-local storage instead of global variables. How exactly you would do that depends on your thread library and compiler, or you could roll your own by using thread identifiers as keys to thread-specific slots in some global data structure (a hash table for instance).
Currently I'm receiving messages over tcp in a self written component that allows me to use Netty as a TCP server producer.
the messages i receive are formatted in XML style, for example:
<customheader>
<someattribute></someattribute>
</customheader>
<custombody>
</custombody>
The messages I receive are stored in a byte[] and to send it to another endpoint I create a new exchange via:
Exchange exchange = new DefaultExchange(endpoint);
exchange.getContext().createProducerTemplate().sendBody("someendpointuri", receivedbytes);
now my questions:
Is my approach with the new exchange correct?
If want to for example get rid of the header or use other camel components, do I need to convert the receivedbytes from byte[] to a different datatype or is byte[] okay?
If i want to remove the custom header can i use the remove header component from camel?
Thanks for your help
You're creating an new Exchange, but you're not actually using it. Instead, you only use it to access CamelContext. The method sendBody is creating a new Exchange for you and it is this Exchange that is actually being sent to endpoint specified by someendpointuri. Note that you should not create a new producer template every time you want to send a message.
When you say that you store messages as byte[], I assume you're storing it inside Message body. In this case you store both customheaders and custombody as byte[] and Camel treats them both as Message body, not headers.
If you want to use Camel header-related components or language constructs, you need to parse your customheaders and then set them on the Message as headers by using Exchange.getIn().setHeaders() (see API with a note about this). If you do that, you would probably only want to set content of custombody in the Exchange.getIn().setBody().
If you do these changes in your custom component, your component will now be handling this specific XML format only. If you want to keep your component generic, you can instead implement a custom DataFormat and call marshal() and unmarshal() in your routes. I think SOAP DataFormat does something very similar.
In apache camel, which of those is the best way to pass values from an exchange processor to another (and why) :
storing it in the exchange headers
using the setProperty method while building the route.
another way..
One distinction not mentioned by Ben and Petter is that properties are safely stored for the entire duration of the processing of the message in Camel. In contrast, headers are part of the message protocol, and may not be propagated during routing. For example, JMS has limitations what you can store as headers etc.
You may want to read the free chapter 1 of the Camel in Action book as it covers the Camel concepts with Exchange, Message, etc.
Properties and headers are pretty much the same. Headers are, however, converted to/from protocol specific headers on certain components, such as Jms. So,
Meta data inside a route: properties
Meta data to/from outside: headers
the Exchange is passed between Processors. It contains properties, IN message and optional OUT message. Each of these is capable of storing Object data, but in general:
use the Exchange Properties for general meta-data about the message (used less frequently)
use the IN message headers to configure endpoint properties or for meta-data about the message body (used often)
use the IN message body for the payload of the message (used most often)
create an OUT message only if necessary to maintain separate IN vs. OUT messages during processing (by default only IN is used)
That said, it really depends on the component called following your processor. Most have some headers and/or body values that are required to use the endpoint, etc. See the specific component page for these details.
Also, the Exchange/Message are explained in more detail on these pages:
http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Exchange.html
http://fusesource.com/docs/router/2.8/prog_guide/MsgFormats-Exchanges.html
Answer is here:
Properties: The properties is a Map and may look like message
headers. The main difference is their lifetime: the properties exist during the whole
exchange execution, whereas the headers are limited to the message duration (and a
message can change a lot during routing, so during the exchange execution). Camel
itself may add some properties for some use cases.