Hi Glenn, I have applied the changes you recommended and created a new patch. Please see attached. diff --git a/mama/jni/src/c/mamapublisherjni.c b/mama/jni/src/c/mamapublisherjni.c index

Hi Glenn, I have applied the changes you recommended and created a new patch. Please see attached. diff --git a/mama/jni/src/c/mamapublisherjni.c b/mama/jni/src/c/mamapublisherjni.c index

Hello, The payload unit tests do not run on VS 2012, I have fixed this and produced a large patch with all "C" unit tests. I have prepared the patch against the 'master' (rev. 2.3.1 and

Hi Damian, I have a follow up on the bug as you asked. Regards, Guy Tick42 On 10/09/2014 11:55, Damian Maguire wrote:

Hi Alpert, I like #2 more, but I still want to keep the more data model/market data/custom logic away from the core messaging part of OpenMAMA. What I’m thinking of is a hook/callback to a

Hi, Yes I agree with Ben’s comments. Here are some caveats: 1. This is a feature that is requested by our market data infrastructure team to prevent app dev teams from accidentally

Hi Frank, You right, I should specify further what we have in mind: -Of course dictionary are not mandatory, and I don't think anyone wants the "dictionary check" to be default behaviour, it has to

Hey Guy, Apologies for not coming back on this, thanks for the ping. I've provided some feedback for you on the Bugzilla ticket, so we can follow up there. Cheers, D

Hi Ben, There are a few things to consider here: 1. The MAMA Dictionary is optional too. If you look at basic mamapublisherc / mamasubscriberc, you’ll see it doesn’t use the

Just to put emphasis on what Reed explain: It should be probably implemented in the C layer, making sure that it "catches" all languages "for free". The goal is to enforce it in OpenMama layer, so

Hi Damian, A week ago I published a patch that fix the mama.properties parser failure to expand a variable on the last line. Can you or anyone else review that fix?

Yes, this is C++, but we also have Java and DotNet clients (some C# and some Excel). We do publish best practices, but our app dev groups sometimes do not follow them, and we want to prevent the

Thanks Chad. For consistency though with the C++ interface, it should be (publisher, topic, source), not (publisher, source, topic). Also consider replacing/extending the existing JNI

Hi, Attached is a patch for OpenMAMA JNI that overloads the MamaPublisher create method. For consistency purposes, the new method requires two String parameters, source and symbol, as opposed to a

Hi folks, I noticed that VectorChar and VectorBool do not have a field type enumerator in Mama (i.e. mamaFieldType enum in mama/fielddesc.h). Also, the related code for VectorChar and VectorBool

Hi Glenn I’m resubmitting that patch (attached and below). This now conforms with your comments Tom diff --git a/README b/README index be1ad38..f278d0d 100644 --- a/README +++

Guessing by your capitalization, I'm guessing this is C++? If so, have you considered mandating that all function calls use MamaFieldDescriptors pulled from a standardized dictionary rather than using

There are a number of places where this *could* be done, but not all make sense to me: - In the payload library - this doesn't feel right as I feel the payload should be 'dumb' and just trust the

Hi, Yes, the addString() is from MamaMsg. The cache is our own market data infrastructure, not the MamaFieldCache. In this case it is either Solace/SolCache or TREP RTIC. We want business

Hi Guy, When you refer to 'addString' below you mention a cache, but this is not a method of the C/C++MamaFieldCacheare you refering to your own cache object or actually a MamaMsg