What is the procedure to make JavaMail Message Parcelable as by default Message can not be serialized? How to achieve the serialization?
Why not simply "serialize" the message by writing it to a stream (or string) and then parsing it back again to "deserialize" it?
Related
From the camel book, section 'Using pollEnrich to merge additional data with an existing message', it shows that you can merge the oldExchange(from the quarz) with the new one (from ftp).
The problem is that I have a file from a topic(old Exchange) and I use pollEnrich to get a new file from a ftp server and I want to merge this too. I am interested in set some headers from oldExchange to the newExchange.
The problem that I am facing is that the oldExchange is all the time null.
I have read the examples from camel book, for aggregator and there said: "The first message arrives for the first group. == null".
I don't understand, then where is my oldExchange? the one from the topic. Why only at the second iteration the exchange is not null (for the same group).
from("myTopic")
.pollEnrich()
.simple("ftp://myUrl&fileName=${in.headers.test}")
.aggregate((Exchange oldExchange, Exchange newExchange) -> {
final String oldHeader = oldExchange.getIn().getHeader("test", String.class);
newExchange.getIn().setHeader("test", oldHeader);
return newExchange;
})
I have read this: http://camel.465427.n5.nabble.com/Split-and-Aggregate-Old-Exchange-is-null-everytime-in-AggregationStrategy-td5746365.html#a5746405 and still I don't understand how can both messages belong to the same group.
The first message arrives for the first group. == null. I don't understand ...
This is true for a standard aggregation where you aggregate for example multiple incoming messages to one. In this case, on the first incoming message the aggregator is still empty and therefore the oldExchange (aggregator content) is null. You have to wait for another (second) message to be able to aggregate something.
However, in your case (enrich) the oldExchange should not be null because the first message, i.e. the message from your topic, is already there.
Have you tried to inspect the message from the topic in the debugger or log it out before it reaches the enricher? Just to make sure it is not empty.
Added after a test
This is fascinating, I tried this with a unit test and when I define the pollEnrich as you do, I get the inverse result: My consumed message routed by .from(...) is the oldExchange and my newExchange is always null.
However, if I define the pollEnrich "inline", it works fine
.pollEnrich("URI", Timeout, (AggregationStrategy))
I suspect that this is explainable if you analyze what the DSL does with these two definitions, but from my quick test perspective it looks a bit strange.
#burki true, is it working as you said with the aggregationStrategy inside the pollEnrich() but I need the simple because I am calling an endpoint dynamically and I cannot do this in the pollEnrich (or at least I don't know how).
I was able to solve like this:
from("myTopic")
.pollEnrich()
.simple("ftp://myUrl&fileName=${in.headers.test}")
.aggregationStrategy((Exchange oldExchange, Exchange newExchange) -> {
final String oldHeader = oldExchange.getIn().getHeader("test", String.class);
newExchange.getIn().setHeader("test", oldHeader);
return newExchange;
})
So instead of the .aggregate call, I am using .aggregationStrategy , what I understood is that the .aggregate call is for the standard aggregation (as #burki mentioned) if we want to aggregate multiple messages and the .aggregationStrategy call can be used to merge 2 messages (one of them is from an external service).
I'm trying to send a large block of data between applications by sending a control message over DBus from one to the other requesting a Unix file descriptor. I have it so that the client can request this, the server creates a DBus message that includes a UnixFDList, and the client receives a reply message but it doesn't contain anything. On the server side in Vala the DBusConnection object is setup using register_object, unfortunately the Vapi hides the DBusInterfaceVTable parameter that all the C examples use that would let me specify a delegate for method calls. I've tried to use register_object_with_closures instead but I can't seem to get that to work and the Closure object in Vala is woefully undocumented.
It seems to me that I need one of these methods in order to receive the message from the DBusMethodInvocation object that you get from a call to the DBusInterfaceMethodCallFunc delegate, with that you can create a reply message. Is there a way to either specify a closure class that works with register_object_with_closures, or a way to specify a DBusInterfaceVTable object as part of the service data?
I know that one option is to just create the service in C, but I'd rather figure out and understand how this works in Vala.
Vala uses UnixFDList internally for methods that contain a parameter of type GLib.UnixInputStream, GLib.UnixOutputStream, GLib.Socket, or GLib.FileDescriptorBased.
Example:
[DBus(name="eu.tiliado.Nuvola")]
public interface MasterDbusIfce: GLib.Object {
public abstract void get_connection(
string app_id,
string dbus_id,
out GLib.Socket? socket,
out string? token) throws GLib.Error;
}
Hello I am new in MSMQ,
having some C++ components I want to connect them via Microsoft Message Queue.
Using the function from https://msdn.microsoft.com/en-us/library/ms711416(v=vs.85).aspx. I want to create a new Message Queue.
This function I call with:
SECURITY_DESCRIPTOR securityDescriptor;
CreateSecurityDescriptor(&securityDescriptor);
WCHAR wszOutFormatName[256];
DWORD dwOutFormatNameLength;
CreateMSMQQueue(L"DIRECT=OS:.\\PRIVATE$\\MyQueue", &securityDescriptor, wszOutFormatName, &dwOutFormatNameLength);
CreateSecurityDescriptor creates as the name says a Default SecurityDescriptor. I can post the code if needed.
But the creating fails with the error code MQ_ERROR_ILLEGAL_QUEUE_PATHNAME. Which means:
PROPID_Q_PATHNAME contains an illegal Message Queuing path name string.
What is wrong with L"DIRECT=OS:.\\PRIVATE$\\MyQueue" ?
I got from https://msdn.microsoft.com/en-us/library/ms700996(v=vs.85).aspx
I am grateful for any help.
You can only reference an existing queue with a format name.
You cannot create a new queue with one.
Use a path name instead.
Difference between Path name and Format name when accessing MSMQ queues
I've implemented a solution to parse Email Files (.eml) into objects using Mime4J. The process parses an email file, create an object and write a new file to disk.
I was wondering if is possible to send the MimeMessage of Mime4J through Transport.send(mimeMessage) instead to create a new file.
The simplest approach would be to use the Mime4J Message.writeTo method to write the message to a ByteArrayOutputStream, then wrap the byte array with a ByteArrayInputStream and use that to construct a JavaMail MimeMessage object.
A more complex but more efficient approach would be to create a class that subclasses MimeMessage and delegates most of the methods to the corresponding methods on the Mime4J Message object.
I’m working on Camel and focusing on Error Handling.
For irrecoverable errors (those that won’t be fixed by retries), Camel In Action says you should use exchange.getOut().setFault(true) and exchange.getOut().setBody("Error Occurred").
What is the best way to actually handle these errors? Right now I’m thinking there’s two ways:
Using handleFaults(true) on the route or context then handling like any other errors
The original message sender could handle it if Request Reply pattern is used
1 is straight forward to me (except at that point, might as well use Exceptions/Recoverable errors?). 2 is a little trickier – I’m not sure how the original sender will know that the message that they get back is an error (vs. the expected return message).
What I’m thinking could happen is this using Exception to indicate that it’s an error:
In route:
// error occurred
exchange.getOut().setFault(true);
exchange.getOut().setBody(new Exception(“error”));
In sender (jms example using QueueRequestor for Request Reply):
responseMessage = qRequestor.request(msg);
if(responseMessage instanceof ObjectMessage && ((ObjectMessage)responseMessage).getObject() instanceof Exception) {
// AN ERROR OCCURRED IN ROUTE
} else {
// NORMAL PROCESSING OF MESSAGE
}
This just seems like a lot of work on the original sender. Is there a better way of handling this?
Camel can handle the exception well out of box with the help of ErrorHandler, which means your camel route don't need to do much thing about it.
But for the fault message, it's a part of Application level message, Camel ErrorHandler don't want to touch it, so the developer should think about how to handle it.