[
https://issues.apache.org/jira/browse/PROTON-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594695#comment-13594695
]
Rob Godfrey commented on PROTON-262:
------------------------------------
2) Whilst I see that
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-error
defines condition info as a map, the fact that the implementation will
silently skip a JNIData returning a non-map type, or ignore additional values
gives concern. I'd prefer to see an IllegalStateException in these unexpected
scenarios to guarantee we are alerted to a misbehaving implementation.
I think this is a more general question about how non-compliant frames should
be handled. In general I believe that this should be handled by the library -
which in this case is proton-c (the JNI is wrapper is essentially acting as an
application layer here). In general proton-j provides scope for much more type
checking in the library than proton-c as it enforces types much more
thoroughly. That's not to say that the error reporting of such type errors is
actually implemented :)
4) What is the correct way for an application to determine if an ErrorCondition
is populated? Would it not be more explicit if ErrorCondition had a method such
as isSet() rather than forcing the caller to use #getCondition() != null?
I think this is really an issue with the API of the endpoints. I'm not really
very happy with the notion that there is a Condition object that is tied 1:1
with the endpoint. I've implemented the API to mirror the C API, but I feel
that the right answer would be that getCondition() on the Endpoint should
return null until a condition is set.
6) ErrorCondition#_info becomes a reference to an application owned map via
#setInfo, then lets this mutable state escape by #getInfo. I think the
implementation would be more robust if ErrorCondition copied the incoming map
on setInfo, and returned a immutable wrapper on calls #getInfo. Also to
simplify client coding, if ErrorCondition#getInfo returned an emptyMap() rather
than null.
I agree this would be more robust, but this is the way much of the code works -
you pass in mutable maps and it is not guaranteed at which point this
information is serialized to go onto the wire (look at the Message class for
instance). I wish there was a way of sealing such mutable objects that did not
require copying.
7) EndpointError has been renamed ErrorCondition. What is the Proton's policy
on deprecation?
EndpointCondition existed previously - it represents the on-the-wire Error
object. EndpointError has been removed as it duplicated (in a not terribly
useful way) the EndpointCondition class. In terms of policy I think until we
get to 1.0 we should not guarantee API compatibility from one release to the
next. 1.0 and beyond then API compatibility should be guaranteed within a
major release I believe.
> Fully implement (error) condtion API in Proton-J
> ------------------------------------------------
>
> Key: PROTON-262
> URL: https://issues.apache.org/jira/browse/PROTON-262
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Fix For: 0.5
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
