On Thu, Jan 24, 2013 at 7:38 AM, Keith W <keith.w...@gmail.com> wrote:
> On 23 January 2013 15:40, Rafael Schloming <r...@alum.mit.edu> wrote:
> > 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
>
> Thanks, that has indeed addressed the issue. The Message system tests
> which previously failed now run cleanly against the Proton-JNI (on the
> jni-branch).
>
> It does leave the question regarding the differences in usage of the
> Proton-API. The Python/C binding makes calls to pn_message,
> pn_message_id, and pn_message_correlation_id when creating its Message
> facade object. The Ruby/C and Java/C bindings call only pn_message
> during construction of their facade object.
>
> Python/C binding:
>
> def __init__(self):
> self._msg = pn_message()
> self._id = Data(pn_message_id(self._msg))
> self._correlation_id = Data(pn_message_correlation_id(self._msg))
>
> Ruby/C binding:
>
> def initialize
> @impl = Cproton.pn_message
> ObjectSpace.define_finalizer(self, self.class.finalize!(@impl))
> end
>
> Java/C binding (jni-branch only)
>
> JNIMessage()
> {
> _impl = Proton.pn_message();
> }
>
> Is there any reason why Python/C works in a different manner?
>
It's just to avoid code duplication between the id property's getter and
setter:
def _get_id(self):
return self._id.get_object()
def _set_id(self, value):
if type(value) in (int, long):
value = ulong(value)
self._id.rewind()
self._id.put_object(value)
id = property(_get_id, _set_id,
doc="""
The id of the message.
""")
I don't think this particular difference should have an impact on behaviour
one way or another. I think the reason the python binding wasn't hitting
the same bug you've observed is that it extracts the id from the data
object by calling Data.get_object, and that will first query the type of
the current node and then call a specific accessor based on that type,
whereas you appear to be calling pn_data_get_atom which will return the
type and the value in a discriminated union. It's possible we could
simplify the swig binding process by always using the former style as then
we might be able to avoid having to add typemaps for pn_atom_t.
--Rafael
