Yeah, it appears to be a bug. I checked in a potential fix on trunk. Give it a shot and see if it's still an issue.
--Rafael On Wed, Jan 23, 2013 at 9:19 AM, Phil Harvey <p...@philharveyonline.com>wrote: > I'm working on the proton-c JNI binding and am having trouble with the > Message.getMessageId() JNI implementation. > > I am currently calling pn_message_get_id but this is causing a segfault > (details below). I suspect that I might be using the proton-c message API > incorrectly and would appreciate advice from someone more familiar with the > proton-c implementation. > > Our call stack is: > AccessorsTest.testId > ... > Message._get_id > JNIMessage.getMessageId() > ... > pn_message_get_id > pn_data_get_atom > <segfaults because node is null> > > This suggests that our problem is that we haven't previously called > pn_message_set_id. > > message.h contains the following: > > pn_data_t * pn_message_id (pn_message_t *msg); > pn_atom_t pn_message_get_id (pn_message_t *msg); > int pn_message_set_id (pn_message_t *msg, > pn_atom_t id); > > The JNI implementation of Message.getMessageId() calls pn_message_get_id. > However, in revision 1400309 (committed by Rafi) the proton-c Python > binding was modified to implement this using the pn_data returned from > pn_message_id instead. > > Are the pn_message_get_id and pn_message_set_id functions deprecated? If > so, the Java Message interface should possibly have its getMessageId and > setMessageId methods removed, and replaced with calls to a new interface > (called MessageId?). > > If not, can anyone explain the intended interplay between the three message > id functions? > > Finally, it seems wrong to me that pn_message_get_id should ever cause a > seg fault. Is this a bug? > > Phil >
