Re: [VOTE] merge the proton mailing list into the users/dev lists

[Rob Godfrey]

+1

Additionally it might make sense to write a paragraph somewhere on
suggestions for best practice on mailing the list (like including
components / languages in use in the title or the body of the e-mail :-) ).

-- Rob

On 30 March 2016 at 11:25, Robbie Gemmell  wrote:

> Hello folks,
>
> Many moons ago, a seperate mailing list was established for Proton,
> back when it was purely a protocol engine other components would use.
> Its scope has since expanded beyond that and the separate mailing list
> has I feel been an increasing source of confusion and hassle of late
> more than anything else. Collapsing it into the other larger existing
> lists we have (that the traffic would otherwise have been on) seems to
> me like it would be an improvement across the board, and as such I
> have called this vote.
>
> I would propose that discussion (such as this) would head to the
> users@q.a.o list to join the similar/related/duplicate traffic already
> present, with remaining things going to the dev@q.a.o list as
> consistent with that list (e.g JIRA, GitHub integration mails,
> ReviewBoard, though the latter was never actually directed to proton@
> to begin with..).
>
> Whilst redirecting JIRA etc emails should be easy enough (has been
> done before), I dont know what the precise options are regarding
> existing mail subscriptions to the list. There are significantly more
> subscribers to users@ than proton@, and many are duplicates, but some
> are not. I'd need to discuss options with infra, but first things
> first, the vote.
>
> I have gone straight to a vote on this because I feel this has already
> been discussed enough previously over time that many people will have
> already thought about it enough to quickly vote one way or the other,
> and it is past time to act on it if things head that way. Obviously
> things can be further discusssed at this point also if desired.
>
> Note that both users@ and proton@ are in the recipients. I expect the
> thread will splinter when someone forgets to reply-all, as almost all
> cross-posted thread on the lists do, but at least it can start on both
> for visibility to all.
>
> Robbie
>

[jira] [Commented] (PROTON-1135) [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214500#comment-15214500
 ] 

Rob Godfrey commented on PROTON-1135:
-

As a co-author of the AMQP specification, I don't think it can be taken as read 
that every implementation  of a "server" MUST support pipelining of the SASL 
and AMQP layers together.  The spec does lay out that the AMQP open sequence 
can be pipelined, but the SASL interaction is (in general) synchronous: the 
client must choose from the set of mechanisms offered.  In certain 
circumstances the client (application) may have knowledge that allows it to 
operate in a pipelined manner (e.g. it knows that the server will accept the 
mechanism) or may be happy to fail in a reasonably unpleasant way if its 
assumptions are incorrect.  However I think that it is unreasonable to expect 
that in general a peer will accept pipelining SASL and AMQP together, and 
empirical evidence shows that it is a poor assumption to make (as literally no 
other implementation has supported it out of the box).  To my mind, in this 
scenario it would be more appropriate to omit the SASL layer entirely.

> [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
> -
>
> Key: PROTON-1135
> URL: https://issues.apache.org/jira/browse/PROTON-1135
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN 
> frames by default when connecting out to other peers using the ANONYMOUS 
> mech, as shown in the following trace - 
> {code}
> [0x7f41f80079c0]:  -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]:  -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
> max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]:  <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]:  <- AMQP
> [0x7f41f80079c0]:0 <- @open(16) 
> [container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767, 
> idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
> properties={:product="qpid-cpp", :version="0.35", :platform="Linux", 
> :host="localhost.localdomain"}]
> {code}
> The AMQP 1.0 spec does not make it clear that this is supported (e.g. see 
> diagram below) but in any case various components have shown difficulty with 
> it (such as PROTON-1135 just raised, and QPID-6639 which has yet to be 
> included in a release but permitted the above protocol trace log).
> {code}
> TCP Client TCP Server
> =
> AMQP%d3.1.0.0 ->
>   <- AMQP%d3.1.0.0
> :
> :
> 
> :
> :
> AMQP%d0.1.0.0 ->
> (over SASL secured connection)
> <- AMQP%d0.1.0.0
> open ->
> <- open
> {code}
> Proton should by default disable sending pipelined OPEN frames for ANONYMOUS 
> logins, to aid compatibility with other components that don't expect/handle 
> such behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1136) [proton-j] handle the case when pipelined SASL and OPEN frames are sent for ANONYMOUS login

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15150836#comment-15150836
 ] 

Rob Godfrey commented on PROTON-1136:
-

Fair enough then - having default to off is definitely going to be the best for 
interoperability

> [proton-j] handle the case when pipelined SASL and OPEN frames are sent for 
> ANONYMOUS login
> ---
>
> Key: PROTON-1136
> URL: https://issues.apache.org/jira/browse/PROTON-1136
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Currently Proton-J is unable to handle pipelined SASL and OPEN frames for 
> ANONYMOUS logins, which are currently sent by proton-c, e.g see the below 
> trace log from Dispatch connecting out using ANONYMOUS:
> {code}
> [0x7f41f80079c0]:  -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]:  -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
> max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]:  <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]:  <- AMQP
> {code}
> Given that there are various clients using proton that might do this by 
> default (PROTON-1135 raised regarding that), proton-j should be updated to 
> cope with it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1136) [proton-j] handle the case when pipelined SASL and OPEN frames are sent for ANONYMOUS login

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15150817#comment-15150817
 ] 

Rob Godfrey commented on PROTON-1136:
-

Yeah - I'd agree that it'd be preferable to have "off" as the default but 
obviously that would be changing the current "functionality"... I wasn't sure 
if that sort of surprise would be welcome by existing users :-)

> [proton-j] handle the case when pipelined SASL and OPEN frames are sent for 
> ANONYMOUS login
> ---
>
> Key: PROTON-1136
> URL: https://issues.apache.org/jira/browse/PROTON-1136
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Currently Proton-J is unable to handle pipelined SASL and OPEN frames for 
> ANONYMOUS logins, which are currently sent by proton-c, e.g see the below 
> trace log from Dispatch connecting out using ANONYMOUS:
> {code}
> [0x7f41f80079c0]:  -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]:  -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
> max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]:  <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]:  <- AMQP
> {code}
> Given that there are various clients using proton that might do this by 
> default (PROTON-1135 raised regarding that), proton-j should be updated to 
> cope with it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1136) [proton-j] handle the case when pipelined SASL and OPEN frames are sent for ANONYMOUS login

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15150790#comment-15150790
 ] 

Rob Godfrey commented on PROTON-1136:
-

Presumably this issue is not restricted to ANONYMOUS, but any case where the 
"client" can pipeline the entire SASL exchange (e.g. EXTERNAL, PLAIN, etc...)

>From the point of view of the spec.. as one of the co-authors I don't think I 
>ever anticipated pipelining then entire SASL interaction and then AMQP 
>operations so it certainly wasn't the intent that every implementation MUST be 
>able to handle the receipt of such... however for certain use cases I can see 
>why you't want to be able to send the entire thing asynchronously so I think 
>we SHOULD handle them... but maybe have a way of turning off such pipelining 
>(through config / connection options / whatever) on the sending side.

> [proton-j] handle the case when pipelined SASL and OPEN frames are sent for 
> ANONYMOUS login
> ---
>
> Key: PROTON-1136
> URL: https://issues.apache.org/jira/browse/PROTON-1136
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Currently Proton-J is unable to handle pipelined SASL and OPEN frames for 
> ANONYMOUS logins, which are currently sent by proton-c, e.g see the below 
> trace log from Dispatch connecting out using ANONYMOUS:
> {code}
> [0x7f41f80079c0]:  -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]:  -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A", 
> max-frame-size=65536, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]:  <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]:  <- AMQP
> {code}
> Given that there are various clients using proton that might do this by 
> default (PROTON-1135 raised regarding that), proton-j should be updated to 
> cope with it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0

[Rob Godfrey]

To be pedantic, only PMC members votes are officially considered binding
[1], and votes from committers who are not on the PMC are not... However in
general as a community we would encourage anyone who has done any sort of
validation of the release to provide their feedback via (non-binding)
voting.

-- Rob

[1] http://www.apache.org/foundation/voting.html

On 10 February 2016 at 15:29, Justin Ross  wrote:

> Thanks, Ganesh.  BTW, you can vote.  When we tally up the results, we
> separate the binding (committer) from the non-binding votes, but we use all
> the votes in our decision nonetheless.
>
> On Wed, Feb 10, 2016 at 7:11 AM, Ganesh Murthy  wrote:
>
> > I cannot vote but I did the following on Fedora 22 -
> >
> > 1. Downloaded and compiled the proton 0.12.0 RC3 source and ran all unit
> > tests (including the ones I added) successfully
> > 2. Made dispatch router master use Qpid Proton 0.12.0 RC 3. Ran dispatch
> > unit tests successfully.
> > 3. Made sure that the unit test for DISPATCH-200 which relies on
> > PROTON-1088 worked.
> >
> > Thanks.
> >
> > - Original Message -
> > From: "Justin Ross" 
> > To: us...@qpid.apache.org, proton@qpid.apache.org
> > Sent: Wednesday, February 10, 2016 9:31:58 AM
> > Subject: Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0
> >
> > The RC 3 maven repo:
> >
> >
> https://repository.apache.org/content/repositories/orgapacheqpid-1063
> >
> > On Wed, Feb 10, 2016 at 6:04 AM, Justin Ross 
> > wrote:
> >
> > > Hi, everyone.  RC 2 had some embedded build output, which this RC
> > > removes.  Apart from that removal, it has the same content as RC 2.
> > >
> > > The proposed release artifacts:
> > >
> > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc3/
> > >
> > > Please indicate your vote below.  If you favor releasing the 0.12.0 RC
> 3
> > > bits as 0.12.0 GA, vote +1.  If you have reason to think RC 3 is not
> > > ready for release, vote -1.
> > >
> > > Thanks,
> > > Justin
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>

Re: AMQP 1.0 session outgoing-window usage / meaning

[Rob Godfrey]

As far as I can recall/reconstruct the only utility given by the
outgoing window was so that the sender (of transfer frames) can
indicate to the receiver (of transfer frames) that it will require
notification of which frames have been seen by the receiver within
window size frames, otherwise the sender will potentially block
until it has received such information.  As such the receiver should
always be able to safely set its incoming window to be = the sender's
outgoing window, since setting it to be larger is pointless.  A sender
which finds itself having previously set the outgoing window size to
zero, and finding its peer's incoming window size is also zero must, I
think, send a flow indicating that its window size is now non-zero.

Having said that I'm not sure I ever saw much utility in this value
and as such I would agree that implementations should probably just
set the default outgoing window size to a large number, and ignore
their peer's outgoing window when setting their own incoming window.
About the only thing that we probably should be doing is ensuring that
if the implied outgoing window of the peer is zero, but might open up
if a flow informing the peer of the updated state, then such a flow
should be sent.  (Not sure I would set to MAX_INT in case anyone is
trying to create an array based on the provided size upon receipt...
but that's just me).

-- Rob



On 8 July 2015 at 20:46, Xin Chen daron...@gmail.com wrote:
 I think one safe thing to do now is to ignore this field. I will update
 service bus to not setting incoming window based on the received outgoing
 window field. This is the only time we look at this value.


 On Wed, Jul 8, 2015 at 10:58 AM, Gordon Sim g...@redhat.com wrote:

 On 07/08/2015 06:23 PM, Rafael Schloming wrote:

 On Wed, Jul 8, 2015 at 8:58 AM, Gordon Sim g...@redhat.com wrote:

 Under your interpretation - i.e. where the sender can change the value of
 the outgoing window without ever having to inform the receiver - the
 outgoing window seems to have very little value except as a hint that the
 sender may be constrained by capacity limits on the number of
 deliveries/transfers it is tracking. To send an outgoing window of 0 when
 there have not yet even been any transfers seems to undermine even that
 limited value.


 I think the way to look at it under that interpretation is not that the
 sender is not notifying the peer, simply that it is notifying the peer
 asynchronously, and that the transfer is implicitly notifying the peer
 (just like it implicitly advances the next-outgoing-id).


 I'm not sure I understand. Asynchronous with respect to what? Are you
 saying that a transfer implicitly expands the remote-outgoing-window (but
 only if it was 0 before the transfer)?

 One of the few concrete rules specified concerning the outgoing window is
 that the remote-outgoing-window MUST be decremented after every incoming
 transfer frame is received, and recomputed when informed of the remote
 session endpoint state. If the last information we received was that the
 outgoing window was 0, what should we do on then receiving a transfer?

Re: improving cross language maintainability

[Rob Godfrey]

On 20 December 2013 19:49, Rafael Schloming r...@alum.mit.edu wrote:

 On Fri, Dec 20, 2013 at 11:43 AM, Fraser Adams 
 fraser.ad...@blueyonder.co.uk wrote:

  I've been following this thread with interest and I guess that Rob's
  comment
 
 
  
 
  However I think that would require us to be
  organised differently with a recognition that the Engine and Messenger
 are
  conceptually separate (with Messenger depending on the Engine API, and
  having no more authority over defining/testing the engine API than any
  other client
  
 
  Struck some resonance.
 
  I think perhaps the layering is OK if you're familiar with the code base
  and perhaps it's more about packaging than layering, but FWIW coming
 into
  proton quite cold it seems like messenger and engine are essentially
  combined. Now I know that's not the case now from the responses to my
  how does it all hang together question of a few weeks ago, but in terms
  of packaging that's still kind of the case.
 
  So what I mean by that is that qpid::messaging and proton messenger are
 as
  far as has been discussed with me peer APIs - both high level that can
  achieve similar things albeit with different semantics, whereas engine
 is a
  lower level API.
 
  Why is it in that case that the proton library is built that contains
 both
  messenger and engine? OK, so it's convenient, but as far as I'm aware
  neither qpid::messaging nor Ted's dispatch router actually use messenger
 at
  all, they both use engine? That would suggest to me that engine and
  messenger probably ought to be exposed as separate libraries? (and
  presumably there's a similar position in Java where the JMS
 implementation
  is engine not messenger based - though I've not looked at the jar
  packaging).
 
  I guess (perhaps related) it just might be better if messenger was in a
  separate source tree, which I'd agree might be a faff, but would clarify
  the hierarchical rather than peer relationship between messenger and
 engine.
 
  So I guess that my take is that Rafael is perfectly accurate when he says
  that I believe they are currently layered precisely the way you
  describe that certainly seems to be the case at the logical level, but
 at
  the physical level it's an awful lot less clear of the layering -
  certainly from the perspective of a novice trying to navigate the code
 base.
 

 There is certainly a pragmatic element in keeping messenger and engine
 bundled the way they are. From a development perspective, having messenger
 in the same code base makes testing significantly easier.


It might make it easier for you (since you have a complete view of every
piece of the code and design) - for myself I found that it made things
*much* harder, as tests were running through multiple layers rather than
being isolated to a single component.  When a test failed it was entirely
unclear which layer the failure resided in or even why the outcome should
be as the test expeted.  Personally I'd say the testing is a strong
argument for separation (although it means more work upfront it makes it
easier for everyone in the long run).


 Writing a simple
 command line program to fire off a few messages in order to reproduce some
 scenario is quite trivial with messenger, but would involve lots of boiler
 plate with just the engine directly. That's something I would like to work
 on improving about the engine API, but it is very slow and difficult to
 make changes given the current setup I described in my original post.



 Given
 that, realistically I think if we were to pull messenger into a separate
 code base, there would be multiple sources of duplicate effort, not only
 having to duplicate/produce another non trivial multi lingual build system,
 but we would also need to build up a test harness that duplicates a good
 chunk of what messenger already does.


Every other project that wants to use the Proton engine will also be
writing tests for their use of the API. And they'll have different use
cases and different pattern that may not be something supported by
Messenger.

Sure, it's great that Messenger tests will implicitly test the Engine, but
they are not a substitute for Engine tests.


 Granted a chunk of that is
 boilerplate that should be somehow refactored into the engine API proper so
 that it is easier to use in general, and if this were to happen such a
 split would probably be more feasible, but that kind of refactoring is
 really prohibitively expensive given all the different shims and bindings
 that would be impacted.


And this points to an issue, with the focus on Messenger the Engine API is
not being enhanced... and it needs people and effort focussed on it.
Messenger should be a client of the Engine API, the Engine shouldn't be a
slave to Messenger.  Other users (whether in Qpid or not) should have equal
influence of the Engine API design, and equal ability to try to shape it.
Right now I find the Engine unattaractive to try to use within the Qpid
Java 

Re: proton-j API factory simplification.

[Rob Godfrey]

Given the Proton class doesn't require the user to know which
implementation they are using (but allows them to explicitly ask for a
particular implementation type if they so desire) I'm a little confused how
adding the requirement for the user to instantiate an implementation
specific class actually helps the user.  Am I missing something?  There
really is no need for a user to know about factories, etc...

-- Rob


On 2 August 2013 15:13, Rafael Schloming r...@alum.mit.edu wrote:

 On Fri, Aug 2, 2013 at 4:44 AM, Phil Harvey p...@philharveyonline.com
 wrote:

  I agree that o.a.q.p.Proton is, overall, an improvement.  I was partly
  responsible for creating the ProtonFactoryLoader and XXXFactory classes,
  and acknowledge that they make life too hard for the user.
 
  This was a result of trying to meet the following design goals:
  1. User code should not need to have a compile-time dependency on any
  proton-c/j/jni classes.  Given our current separation of the proton-api
  from the proton-impl/proton-jni modules, it means user code should only
  depend on proton-api at compile-time.
  2. Classes from the various top level packages, such as engine,
 messenger
  etc, should be kept separate unless they really need to be together.
 
  I still believe in goal 1 (though this will be discussed at greater
 length
  on the related thread [1]), but am relaxed about item 2.
 

 Thanks for describing the goals, it's helpful to have them written down. I
 personally don't feel that the Proton class is violating (2) in an
 important way so long as engine and messenger remain otherwise unentwined.

 I generally agree with (1) also, however I think it could use some further
 refinement. At the root of (1) is the desire to make it clear and obvious
 to developers if/when they are depending on the characteristics of a given
 implementation rather than on a more abstracted interface. Probably the
 most common example of this sort of thing within Java would be typical
 collections usage of interface/impl splits, e.g.:

 List foo = new ArrayList();
 ArrayList bar = new ArrayList();
 LinkedList baz = new LinkedList();

 The suggested pattern for the Proton class would be following this pattern
 exactly:

 Proton p = new ProtonJ();
 ProtonJ pj = new ProtonJ();
 ProtonC pc = new ProtonC();

 Now this pattern of course doesn't really speak to classpaths at all. The
 classpath issue is really entirely orthogonal to the interface/impl
 distinction. Right now we have separate classpaths, but a muddled
 interface/impl distinction since the impl jar adds new interfaces into
 packages belonging to the API jar, and the API jar has stuff in it that is
 really part of a specific impl. Likewise, you can have a clear
 interface/impl distinctions within a single jar as is the case with java
 collections.

 I'd argue that the classpath thing is really a distinct goal/requirement
 and is really more about a discovery mechanism for independent or third
 party implementations. I don't personally feel that this is a necessary
 requirement for us at this point, but I'm fairly relaxed if other people
 would like to support it.

 Given the above refinement of (1) into (1a) interface/impl split and (1b)
 independently implementable API, I would find it a bit odd to put the
 ProtonJ/ProtonC classes into the API package since that would introduce a
 dependency from the API package back to those impls (even if its only a
 runtime dependency) and would effectively give those impls an elevated
 position which in some sense is fine, but also seems contrary to the
 independently implementable notion in the first place. It seems like what
 you'd want in the API package is purely a generic discovery mechanism that
 would work for any implementation.

 As I said above, I don't feel like such a discovery mechanism is really a
 requirement for us right now. I think actually having a complicated
 discovery/factory pattern is in some ways detrimental as it creates a
 barrier to entry for all users when most don't care about the flexibility
 it offers (at least right now) and if they do care about that flexibility
 it is easy enough for them to build their own. In fact modulo exception
 handling it is really just one extra line of code:

 Class impl = Class.forName(System.getProperty(blah));
 Proton p = (Proton) impl.newInstance();

 So I'd personally say go for the simple interface/impl split pattern that
 everyone knows and is used to and don't worry about a generic discovery
 mechanism until we actually have enough implementations for it to be
 warranted.

 --Rafael

[jira] [Resolved] (PROTON-358) [Proton-j] CategoryLoggerDiscoveryTest fails when run on Java 7 due to tests being run in a different order

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-358.


Resolution: Fixed

 [Proton-j] CategoryLoggerDiscoveryTest fails when run on Java 7 due to tests 
 being run in a different order
 ---

 Key: PROTON-358
 URL: https://issues.apache.org/jira/browse/PROTON-358
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Rob Godfrey
Assignee: Rob Godfrey

 Some tests in CategoryLoggerDiscoveryTest change the default logger, but do 
 not restore the default at the end of the test.  If these tests are run 
 before the test which checks the default logger is StdOut that that test 
 fails.

--
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

[jira] [Created] (PROTON-358) [Proton-j] CategoryLoggerDiscoveryTest fails when run on Java 7 due to tests being run in a different order

[Rob Godfrey (JIRA)]

Rob Godfrey created PROTON-358:
--

 Summary: [Proton-j] CategoryLoggerDiscoveryTest fails when run on 
Java 7 due to tests being run in a different order
 Key: PROTON-358
 URL: https://issues.apache.org/jira/browse/PROTON-358
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Rob Godfrey
Assignee: Rob Godfrey


Some tests in CategoryLoggerDiscoveryTest change the default logger, but do not 
restore the default at the end of the test.  If these tests are run before the 
test which checks the default logger is StdOut that that test fails.

--
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

[jira] [Created] (PROTON-359) [Proton-j] Create a simple entry point for creating all Proton entities

[Rob Godfrey (JIRA)]

Rob Godfrey created PROTON-359:
--

 Summary: [Proton-j] Create a simple entry point for creating all 
Proton entities
 Key: PROTON-359
 URL: https://issues.apache.org/jira/browse/PROTON-359
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Rob Godfrey
Assignee: Rob Godfrey


Rather than requiring users to create a ProtonFactoryLoader, get a factory and 
then create an object, instead just do Proton.connection(), Proton.message(), 
etc.

--
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

Re: Qpid-specific logging facade(s) for Proton etc

[Rob Godfrey]

So, my main comment would be that I think the Factories should not be
depending on the MessageLoggerSpi as you've defined it, but instead purely
on EngineLogger.  The MessageLogger stuff is a convenience but I don't
think it should be mandatory to use it.

My other comment would be that I don't think ProtonCategory should be
defining the qualified name I think that would the specific to the
implementation of the logging.

-- Rob


On 25 June 2013 13:28, Phil Harvey p...@philharveyonline.com wrote:

 I've created a skeleton Java implementation of the Proton logging design
 and attached it as a patch to
 https://issues.apache.org/jira/browse/PROTON-343.

 I think the next steps are:
 - Gather comments from folks about the design.
 - Sketch out the corresponding proton-c and proton-jni code.  I'd
 appreciate assistance from someone with more proton-c familiarity for this.

 Please let me know your thoughts.

 Thanks,
 Phil


 On 5 June 2013 15:27, Phil Harvey p...@philharveyonline.com wrote:

  An interesting discussion about logging has emerged from the mailing
  thread AMQP 1.0 JMS client - supplementary coding standards.  I'm
  starting a new thread for this specific topic and am including the proton
  list.
 
  To recap, Rob, Rajith, Rafi and Gordon have expressed a desire for Proton
  and the new JMS client to use a custom logging facade, rather than
 directly
  calling log4j, slf4j etc.  The Proton logging facade would work
  consistently across proton-c and proton-j.
 
  I think the case for adopting this approach is overwhelming, but am
  interested in views on the best implementation.
 
 
  *=== Proton ===*
  *
  *
  I added a diagram to the wiki illustrating how this might work for
  proton-j.  It's not finished, but I thought it useful to share it early
 to
  stimulate discussion.  Hopefully the implied proton-c equivalent is
 fairly
  obvious.
 
  https://cwiki.apache.org/confluence/display/qpid/Proton+Logging
 
  I'm not sure what would go into ProtonOperationalLogger at the moment
  (Rob/Rafi may know), but want to leave the door open to separating
  Proton-specific methods from general purpose log(Level, String) kind of
  stuff.  It does at least give us a place to define the behaviour of the
  public logging API that Rob referred to, and which would behave the
 same
  as its proton-c counterpart.
 
  To me, the Logger interface in the diagram looks very similar to the Qpid
  Java Broker's RootMessageLogger.  Proton *may* use it directly for debug
  logging.
 
 
  *=== JMS Client ===*
  *
  *
  Turning to the JMS client, my initial preference would be to create
  interfaces JmsOperationalLogger and JmsLogger corresponding to the Proton
  ones.  The JMS Client would pass to Proton a ProtonLogger implementation
  that simply wraps its JmsLogger.
 
  Alternatively we could create a Logger interface in a central sub-project
  and use it in both Proton and the JMS Client, but I suspect that will
  involve more re-jigging of our project structure than we currently have
  appetite for.
 
  Comments/criticisms etc welcomed.  I'm especially interested in whether
  there are proton-c-specific factors that would significantly affect our
  implementation.
 
 
  Phil
 

[jira] [Created] (PROTON-339) [Proton-J] Implement Data interface in pure Java

[Rob Godfrey (JIRA)]

Rob Godfrey created PROTON-339:
--

 Summary: [Proton-J] Implement Data interface in pure Java 
 Key: PROTON-339
 URL: https://issues.apache.org/jira/browse/PROTON-339
 Project: Qpid Proton
  Issue Type: Improvement
  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

Re: Data interface in Proton-J

[Rob Godfrey]

On 18 June 2013 23:45, Leon Mlakar l...@digiverse.si wrote:


 Fetched them, thank you. It does help indeed


Great


 , At the first glance it looks like more than just 30% done.


I may have done a bit more work on it over the weekend :)

I didn't really want to check in something that was really no more than a
couple of hours of half-thought messing around (so now you have *several*
hours of half thought messing around checked in for you to look at :) ).


 I even manged to integrate the stuff into my project and get the DataImpl
 instance through the factory with no problems.


Excellent.


 Will take a closer look in the next days, though. All this proton stuff is
 still pretty much new to me, so I might have some basic questions (like
 what exactly should narrow and widen do :-) later on.


An excellent question... the fact that I didn't know was possibly one
reason why I didn't implement them (I think Rafi did tell me once what they
are supposed to be for)...


 But let me first got through the sources and dig through whatever archives
 I manage to find.


Great - just ping me if you have any problems.

Cheers,
Rob



 Cheers,

 Leon



 On 6/18/13 10:30 AM, Rob Godfrey wrote:

 OK - I've just committed [1] the initial pass at the Data implementation.

 Not yet implemented are the copy, append, narrow and widen operations...
 or
 much in the way of checking errors are handled the same way as the C, etc.

 If find issues and/or want to contribute patches you can attach
 comments/patch files to the JIRA [2].

 Hope this helps,
 Rob

 [1] https://svn.apache.org/**r1494067 https://svn.apache.org/r1494067
 [2] 
 https://issues.apache.org/**jira/browse/PROTON-339https://issues.apache.org/jira/browse/PROTON-339


 On 14 June 2013 16:13, Rob Godfrey rob.j.godf...@gmail.com wrote:

  T

 [...]

Re: Data interface in Proton-J

[Rob Godfrey]

That would be great!

Let me have a dig around over the weekend and see if I can find it (I have
*lots* of machines where it might be on :-( I should probably be more
organised).


Cheers,
Rob


On 14 June 2013 16:01, Leon Mlakar l...@digiverse.si wrote:


 Hi Rob,

 thanks for reply. It got me thinking ... since Data interface is not a
 history and will be around, to do things The Right Way I'll have to
 implement parts of it myself anyway. So I might as well take a shot in
 adding missing 70%, or at least some part of them, on top of your 30% :-).
 Is there any chance for you to you dig up what you've got so far and get it
 over to me somehow?

 Best regards,

 Leon

  Hi Leon,

 As you have noticed a pure Java implementation of the Data interface is
 not
 yet available (I think I have a 30% complete implementation sitting
 somewhere on an old laptop, but I never got round to finishing it).  It
 will get implemented eventually, but it's not currently being worked on as
 far as I know.

 The Java implementation was built upon a codec which serializes objects in
 Java form into AMQP binary data. On the Java implementation of the Message
 class there is a method setBody(Section body).  So, in Java, to send an
 amqp value message containing a map, you could do something like:

 import org.apache.qpid.proton.amqp.**messaging.AmqpValue;
 import org.apache.qpid.proton.amqp.**Symbol;

 ...

 Map map = new LinkedHashMap();
 map.put(symbol, Symbol.valueOf(a symbol));
 map.put(int, 21);
 ...
 AmqpValue body = new AmqpBody(map);

 message.setBody(body);

 Hope this helps,
 Rob


 On 14 June 2013 15:22, Leon Mlakar l...@digiverse.si wrote:

  Hello everybody,

 I've been following this list for quite a while but so far had no reason
 to take part in discussions.

 However, these days I'm porting some C++ code that is using Proton-C to
 talk to peers to Java. The C++ code uses pn_data_put_* functions from
 codec module to compose the body of the message and pn_data_get_*
 counterparts to decompose it at the other end.

 In Java, the Proton-Api's Data interface (org.apache.qpid.proton.codec)
 seems to provide the same functionality. But as far as I could see no
 class is actually implementing the interface, and the
 DataFactoryImpl.createData(long) is only throwing the exception
 which

 indicates that this operation is not supported. I've seen this in both
 0.4 package and on the Git's trunk.

 Is this a part of functionality that is merely not implemented yet, or
 something that is not planned to get implemented at all? In either case,
 what would be the alternate methods to put together the message body in
 a way that could be understood by C++ code? And vice versa?

 The use of Java bindings to Proton-C is not the preferred way to go.

 Thanks and best regards,

 Leon

Re: QPID Proton SASL header mismatch: 'AMQP\x01\x01\x00\x0a'

[Rob Godfrey]

Since this looks like an issue you are having with the Qpid C++ broker
rather than Proton per se, it's probably worth cross-possting this to the
Qpid User list

-- Rob


On 27 May 2013 18:11, Pablo Rodríguez Rey m...@xkr.es wrote:

 Thanks Robbie Gemmel, that's what I suspected.

 I've found the problem thanks to a bug reported and fixed by Gordon Sim,
 AMQP 1.0 is not enabled and compiled by default:

 https://issues.apache.org/jira/browse/QPID-4545

 But I applied the patch and stills not work. Also found this thread:


 http://mail-archives.apache.org/mod_mbox/qpid-users/201301.mbox/%3c510a9a15.4000...@redhat.com%3E

 I compile it again but no amqpc.so is generated from anywhere to load as
 module.

 Also i tested using libqpid-proton.so as module, it works but nothing
 happens:

 ./qpidd --load-module libqpid-proton.so --data-dir /var/qpid

 I think Im not doing anything well to generate this module, so any help
 will be appreciated.

 Thanks again.


 On Mon, May 27, 2013 at 5:55 PM, Robbie Gemmell robbie.gemm...@gmail.com
 wrote:

  Hi Pablo,
 
  Hopefully some others with knowledge of the C++ broker and Proton-C can
  help further, but I did pick up on this in your logs:
 
  qpidd:
  2013-05-27 12:06:04 [System] debug RECV [127.0.0.1:5672-127.0.0.1:57656
 ]:
  INIT(1-0)
  2013-05-27 12:06:04 [System] debug SENT [127.0.0.1:5672-127.0.0.1:57656
 ]:
  INIT(0-10)
 
  That suggests to me that the broker is not actually configured to use
 AMQP
  1.0 and so has replied with a supported protocol version (0-10) instead
  once the client begun connecting.
 
  Robbie
 
  On 27 May 2013 11:36, Pablo Rodríguez Rey m...@xkr.es wrote:
 
   Hello to all members,
  
   My name is Pablo. I'm working in the IT area of the University of
 Murcia
  in
   Spain, and I've just seen the Proton project, and I'm testing it to use
  as
   standard message queue interprocess in our applications. This is my
 first
   approach to message queue services.
  
   I've compiled with no issues QPID 0.20 C  QPID Proton 0.4 and
 generated
   and installed the PHP module (cproton).
  
   Also, I'm using latest QPID 0.20 C server, running on Ubuntu 10.04.04
  with
   trace option (-t).
  
   Running the C examples seems to work fine:
  
   qpidc-0.20/examples/messaging$ ./client
   Twas brillig, and the slithy toves - TWAS BRILLIG, AND THE SLITHY
 TOVES
   Did gire and gymble in the wabe. - DID GIRE AND GYMBLE IN THE WABE.
   All mimsy were the borogroves, - ALL MIMSY WERE THE BOROGROVES,
   And the mome raths outgrabe. - AND THE MOME RATHS OUTGRABE.
  
   qpidc-0.20/examples/messaging$ ./server
   Processed request: Twas brillig, and the slithy toves - TWAS BRILLIG,
  AND
   THE SLITHY TOVES
   Processed request: Did gire and gymble in the wabe. - DID GIRE AND
  GYMBLE
   IN THE WABE.
   Processed request: All mimsy were the borogroves, - ALL MIMSY WERE THE
   BOROGROVES,
   Processed request: And the mome raths outgrabe. - AND THE MOME RATHS
   OUTGRABE.
  
   When I run the Proton C or PHP examples it throws the following output:
  
   $ ./send
   [0x9fe5990:0] ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
  
   $ php send.php
   [0x95ae5f0:0] ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
  
   qpidd:
   2013-05-27 12:06:04 [System] debug RECV [127.0.0.1:5672-
 127.0.0.1:57656
  ]:
   INIT(1-0)
   2013-05-27 12:06:04 [System] debug SENT [127.0.0.1:5672-
 127.0.0.1:57656
  ]:
   INIT(0-10)
  
   Sorry if the question is dumb, but I searched all along the web and
  looked
   sources but I don't know what I'm doing wrong.
  
   If I stop the QPID C Server it works:
  
   qpid-proton-0.4/examples/messenger/php$ php send.php
   sent: Hello World!
  
   qpid-proton-0.4/examples/messenger/c$ ./recv
   Address: amqp://0.0.0.0
   Subject: Hello World!
   Content: this is a test
  
   Is QPID Proton a server-alone library? Does it not support any QPID C
   server thing I'm not counting on?
  
   Thanks in advance.
  
  
   --
   Pablo Rodríguez Rey (http://mr.xkr.es)
   Area de Tecnologías de la Información y las Comunicaciones Aplicadas
   Edificio ATICA ~ Sección de Redes ~ Despacho B1.2.004 ~ Tel. 868 88
 8209
   Universidad de Murcia, 30100 Campus de Espinardo (Murcia - Spain)
   i've mapped my mind on my dick
  
 



 --
 Pablo Rodríguez Rey (http://mr.xkr.es)
 Area de Tecnologías de la Información y las Comunicaciones Aplicadas
 Edificio ATICA ~ Sección de Redes ~ Despacho B1.2.004 ~ Tel. 868 88 8209
 Universidad de Murcia, 30100 Campus de Espinardo (Murcia - Spain)
 i've mapped my mind on my dick

Re: [VOTE] Subversion to JIRA integration

[Rob Godfrey]

QPID:
Yes [ X ]
No [  ]

PROTON:
Yes [ X ]
No [  ]

-- Rob

On 24 May 2013 13:03, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 Hi all,

 As some of you will already know, a mail was sent to committers@a.oearlier
 outlining some of the newer services ASF infra offer that we may not know
 about. One in particular stuck out for me, a service to populate JIRAs with
 information about relavant commits to Subversion or Git. I have always
 missed the Subversion integration within JIRA since it had to be disabled
 (it seemingly doesn't work very well with repositories of the size found at
 the ASF), so I would love to get something back in this area. You can find
 the details here: http://www.apache.org/dev/svngit2jira.html

 I would like to request this for both the QPID and PROTON JIRA instances.
 They indicate they would like agreement before enabling it, as unlike the
 older integration it generates a bit of traffic by actually posting
 comments on the JIRAs, so please vote now:

 QPID:
 Yes [  ]
 No [  ]

 PROTON:
 Yes [  ]
 No [  ]


 Robbie

Re: Defining the behaviour of Proton Engine API under error conditions

[Rob Godfrey]

On 28 March 2013 02:45, Rafael Schloming r...@alum.mit.edu wrote:

 On Wed, Mar 27, 2013 at 6:34 PM, Rob Godfrey rob.j.godf...@gmail.com
 wrote:

  On 27 March 2013 21:16, Rafael Schloming r...@alum.mit.edu wrote:
   On Wed, Mar 27, 2013 at 11:53 AM, Keith W keith.w...@gmail.com
 wrote:
  
 
  [..snip..]
 
  
   3. How will the application using top half API know an error has
   occured? What are the application's responsibilities when it learns of
   an error?
  
  
   The transport has an error variable which can be inspected to get more
   information about what has happened. Also, if/when the transport is
  unbound
   from the connection, all of the remote endpoint states will transition
  back
   to UNINIT.
  
   I'm not sure how to answer what the applications responsibilities are.
  That
   seems to depend on the application. It could just decide to shutdown
 with
   an error message or it could decide to employ some sort of retry
  strategy,
   e.g. connect to a backup service, create a new transport, and bind it
 to
   the same top half. I'm not sure I'd say it has any hard and fast
   responsibilities per/se though.
  
  
 
  I think the point Keith was trying to make here is that in order for a
  component to be compliant with the AMQP specification, anywhere where
  the spec says The connection/session/link should be
  closed/ended/detached with the X error, is it the application that
  actually has responsibility for setting the local error state and
  calling the close() on the appropriate endpoint.  If it is we are
  placing a burden on the application authors to preserve AMQP
  compliance.
 

 Ah, that makes sense. Thanks for clarifying. I don't recall offhand all the
 places the spec says close/end/detach with an X error, but in situations
 like framing errors or missing/invalid arguments required by the transport
 to properly maintain state, say an out-of-sequence delivery-id, that is
 something the transport would handle automatically. I expect there may be
 some cases that the top half would need to initiate explicitly though, e.g.
 obviously a redirect error would need to be initiated by the top half.


So when you say the transport handles automatically, how does that work
from the app's perspective?  Is the transport updating the local state of
the endpoint, or the remote state... if the transport is actually injecting
the close performative into the outgoing stream (the detach, end, or close)
then it seems somewhat weird if the local app still sees this endpoint as
locally open.. on the other hand it is also weird if the local state is now
a shared responsibility between the app and the transport.

Also what about cases where the error is in the opening performative for
the endpoint (open,begin,attach)... if the way to communicate the error is
by responding with the paired closing performative, this may first require
the sending of an opening... For example, if there is an error in an
incoming (unsolicited) open frame - say the container id is null - then the
only way to communicate this back to the other side is to send a valid open
immediately followed bby a close frame with the appropriate error code.
Are you saying that the transport would do all this silently without this
being visible to the app?

-- Rob


 --Rafael

[jira] [Created] (PROTON-269) Connect Redirect parsing incorrectly uses position in map rather than value of key

[Rob Godfrey (JIRA)]

Rob Godfrey created PROTON-269:
--

 Summary: Connect Redirect parsing incorrectly uses position in map 
rather than value of key
 Key: PROTON-269
 URL: https://issues.apache.org/jira/browse/PROTON-269
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Rob Godfrey


The connection error redirect is defined to carry an info map of the 
following form:

 The container is no longer available on the current connection. The peer 
should attempt reconnection to the container using the details provided in the 
info map.

  hostname:  the hostname of the container. This is the value that should be 
supplied in the hostname field of the open frame, and during the SASL and TLS 
negotiation (if used).

  network-host: the DNS hostname or IP address of the machine hosting the 
container.

  port: the port number on the machine hosting the container.

However proton-c completely ignores the values of the keys in the info map and 
instead assumes that network host will be the value in the second key-value 
pair, and port will be the value in the thirs key-value pair; e.g.:

const char *pn_condition_redirect_host(pn_condition_t *condition)
{
  pn_data_t *data = pn_condition_info(condition);
  pn_data_rewind(data);
  pn_data_next(data);
  pn_data_enter(data);
  pn_data_next(data);
  pn_data_next(data);
  pn_data_next(data);
  pn_data_next(data);
  pn_bytes_t host = pn_data_get_bytes(data);
  pn_data_rewind(data);
  return host.start;
}

This is incorrect behaviour.

--
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

[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13598301#comment-13598301
 ] 

Rob Godfrey commented on PROTON-160:


I'm somewhat late to this party, but I am hitting this same issue in some work 
that I am doing.  The solution I am looking for is, I think, that given by 
Gordon above - the ability to use configuration information such that Messenger 
resolves hostname to a TCP/IP address through custom configuration.  In my 
use case I would have a single IP address that all hosts initially resolve to - 
this will be the redirector component.  The redirector will then hold 
secondary configuration as to where the actual TCP/IP address to connect to is, 
and will send the redirect accordingly.

Are we still looking to address this (excuse the pun) for 0.5?

 Allow open.hostname to be configured independently of network hostname
 --

 Key: PROTON-160
 URL: https://issues.apache.org/jira/browse/PROTON-160
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c, proton-j
Affects Versions: 0.1, 0.2
Reporter: David Ingham
Assignee: Rafael H. Schloming
  Labels: api
 Fix For: 0.5


 In a scaled-out, multi-tenant broker environment, the host on which the 
 container is running is often different from the host to which a client is 
 establishing the tcp connection. The 'hostname' field in the connection open 
 performative was added to support this scenario. Currently there's no way to 
 control this from the Messenger API.
 Options include:
 (1) (preferred) add a new 'networkhost' field to Message to allow the network 
 address to be specified. If provided, this information would be used when 
 establishing the network connection and the data in the 'address' field would 
 be used in the connection open hostname field. This is somewhat in line with 
 the way that connection redirect (amqp:connection:redirect) is specified.
 (2) extend the syntax of address with query string to supply hostname, e.g., 
 username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' 
 would become the hostname used in the connection open frame. This is the 
 approach used by the current Qpid AMQP 1.0 JMS client.

--
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

Re: put vs. send

[Rob Godfrey]

On 6 March 2013 13:26, Rafael Schloming r...@alum.mit.edu wrote:
 On Wed, Mar 6, 2013 at 1:44 AM, Rob Godfrey rob.j.godf...@gmail.com wrote:

 On 5 March 2013 21:10, Rafael Schloming r...@alum.mit.edu wrote:
  On Tue, Mar 5, 2013 at 11:24 AM, Ted Ross tr...@redhat.com wrote:

 [.. snip ..]

 
  It isn't really possible to have put cause messages to be eventually
 sent
  without a background thread, something we don't currently have.

 I think it's this that is what makes me find the API slightly odd.
 That put is an asynchronous operation is fine, but the fact that the
 only way to get work to occur is for a synchronous operation to be
 called seems a little screwy.

 If I understand correctly, right now an application programmer cannot
 actually write an asynchronous publisher, every so often they would
 have to call some form of synchronous operation.

 At the very least it would seem to suggest there might be call for a
 do some work but don't block function in the API.  This could either
 take an aggressive strategy of flushing everything that it can to the
 wire, or it could attempt to optimize into larger transmission units.


 This is exactly what happens when you set the timeout to zero and call send
 (or recv). Are you saying you want some other way of doing the same thing
 or you want a background thread?

Surely though setting timeout to 0 and calling send results in
something that looks like an error (this timed out).  On a Java
implementation I would expect this to throw an exception. That's not
really the semantic I'm expecting.  The semantic is do some work if
you can without blocking.

-- Rob

 --Rafael

Re: put vs. send

[Rob Godfrey]

 Whether that's reported as an error is really a choice of the bindings. In
 C it's all just return codes. We could add a separate non-blocking flag
 that causes the blocking operations to return distinct error codes, i.e.
 the equivalent of EWOULDBLOCK, but I don't think this makes a whole lot of
 sense in C. I can buy that in the higher level bindings the extra flag
 would tell the API whether to signal timeout by returning false vs throwing
 an exception.


With the Java implementation (not just the binding) I would expect an
(expensive) exception to be thrown here. I don't think you should be
triggering an exception for a non-exceptional condition.

 I do agree that we'll want a work interface at some point, but I've been
 thinking that would not just do the work, but also tell you what work has
 been done, so you can, e.g., go check whatever tracker statuses may have
 been updated.


Yeah - i think what you are currently suggesting is more of a you can
get round the lack of an explicit API because this sort of does the
same thing if you squint at it.  Calling a blocking method with a
zero timeout is a hack to cover the lack of a method for the desired
semantic. Moreover if this is a recommended use case for send then I
think you'd need to document it, which would really muddy the waters
as to what send is.

-- Rob

Re: can't assign Jira

[Rob Godfrey]

You should be able to assign JIRAs to yourself now

-- Rob

On 5 March 2013 16:50, Michael Goulish mgoul...@redhat.com wrote:
 I created PROTON-260, but I can't seem to assign it to myself.
 Do I need some new permissions to do this?

[jira] [Updated] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-214:
---

Attachment: JNIMessenger.patch

Attached a small patch for the JNIMessenger to throw a relevant exception when 
checking the return code from calls to native methods

 Test proton_tests.messenger.MessengerTest.testSendBogus failed
 

 Key: PROTON-214
 URL: https://issues.apache.org/jira/browse/PROTON-214
 Project: Qpid Proton
  Issue Type: Bug
Affects Versions: 0.3, 0.4
 Environment: Run mvn test from a clean checkout - this uses 
 proton-j by default.
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
 Attachments: JNIMessenger.patch


 The system test proton_tests.messenger.MessengerTest.testSendBogus is 
 failing against both the proton-jni profile and, on certain computers, when 
 run against proton-j too.  
 The proton-jni problem seems to be caused by the fact the the JNI Messenger 
 implementation ignores proton-c's error return codes.
 I think I've seen this test pass occasionally against proton-j so I suspect 
 there's something unreliable about the test.
 Here is the output.
 proton_tests.messenger.MessengerTest.testSendBogus ..Feb 
 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl 
 processActive
 SEVERE: Error processing connection
 java.io.IOException: Connection reset by peer
   at sun.nio.ch.FileDispatcher.read0(Native Method)
   at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
   at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
   at sun.nio.ch.IOUtil.read(IOUtil.java:206)
   at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236)
   at 
 org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95)
   at 
 org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80)
   at 
 org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426)
   at 
 org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525)
   at 
 org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506)
   at 
 org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186)
   at 
 org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204)
   at org.python.core.PyObject.__call__(PyObject.java:387)
   at org.python.core.PyObject.__call__(PyObject.java:391)
   at org.python.core.PyMethod.__call__(PyMethod.java:109)
   at proton$py.send$201(__pyclasspath__/proton.py:997)
   at proton$py.call_function(__pyclasspath__/proton.py)
   at org.python.core.PyTableCode.call(PyTableCode.java:165)
   at org.python.core.PyBaseCode.call(PyBaseCode.java:134)
   at org.python.core.PyFunction.__call__(PyFunction.java:317)
   at org.python.core.PyMethod.__call__(PyMethod.java:109)
   at 
 proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52)
   at 
 proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py)
   at org.python.core.PyTableCode.call(PyTableCode.java:165)
   at org.python.core.PyBaseCode.call(PyBaseCode.java:134)
   at org.python.core.PyFunction.__call__(PyFunction.java:317)
   at org.python.core.PyMethod.__call__(PyMethod.java:109)
   at 
 org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344)
   at 
 org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test)
   at org.python.core.PyTableCode.call(PyTableCode.java:165)
   at org.python.core.PyBaseCode.call(PyBaseCode.java:166)
   at org.python.core.PyFunction.__call__(PyFunction.java:338)
   at org.python.core.PyMethod.__call__(PyMethod.java:139)
   at 
 org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484)
   at 
 org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test)
   at org.python.core.PyTableCode.call

Re: jenkins interop test failing due to PROTON-215 commits?

[Rob Godfrey]

notificati...@qpid.apache.org

-- Rob

On 27 February 2013 21:51, Alan Conway acon...@redhat.com wrote:
 On Wed, 2013-02-27 at 11:19 +, Phil Harvey wrote:
 Hi,

 I notice that proton-jni on Jenkins is failing [1] , probably due to the
 recent PROTON-215 commits.

 The failing test is:
 proton_tests.interop.InteropTest.test_messagehttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/35/testReport/junit/proton_tests.interop/InteropTest/test_message/

 Is someone already looking into this?


 Thanks,
 Phil

 [1]
 https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/lastBuild/

 That would be my commit, apologies. Will investigate ASAP.

 BTW what mailing list to the Jenkins notices go to?

Re: Need help Re: jenkins interop test failing due to PROTON-215 commits?

[Rob Godfrey]

On 27 February 2013 23:28, Alan Conway acon...@redhat.com wrote:
 On Wed, 2013-02-27 at 11:19 +, Phil Harvey wrote:
 Hi,

 I notice that proton-jni on Jenkins is failing [1] , probably due to the
 recent PROTON-215 commits.

 The failing test is:
 proton_tests.interop.InteropTest.test_messagehttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/35/testReport/junit/proton_tests.interop/InteropTest/test_message/

 Is someone already looking into this?

 Regarding:
 https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/37/

 I need some help with the JNI code to figure this out.

 I can't reproduce the problem on my fedora box. Can we get information
 about the jenkins build system, e.g. version of Java and Python
 involved?

 Here's a summary of what I think  happens, this is running the
 interop.py tests in Jython:

   m = proton.Message()
   d = Proton.Data()
   m.decode(an amqp message read from a file.)
   d.decode(body)
   BANG

 We blow up with: TypeError: wrap(): 1st arg can't be coerced to byte[]

 This is in python class proton.Data

   def decode(self, encoded):
 return self._data.decode(ByteBuffer.wrap(encoded))

 So it appears that a python Message.body is somehow set to something
 that cannot be coerced to byte[]. So I look at JNIMessage.getBody() and
 I see it returns a Section. A Section is an empty interface. Huh??

 Can someone explain the relationship between a JNI python message body
 and this Section interface, and how it is supposed to be converted?

 Cheers,
 Alan.

So, the Java API more closely matches the AMQP spec than the C API
here... An AMQP Message consists of a number of sections.  The body
may be a Data section, an AmqpValue section or an AmqpSequence
section. So in the Java API getBody() returns a Section object that
may be one of these three types.

-- Rob

Re: [RESULT] [VOTE] 0.4 RC3

[Rob Godfrey]

+1 we should have a tag in the repo for each of our releases

-- Rob

On 26 February 2013 20:34, Rajith Attapattu rajit...@gmail.com wrote:
 Rafi,

 I don't want to sound pedantic, but we should tag our releases as per
 the guidelines provided by Apache.
 The previous releases don't have tags either (at least they do have a
 branch, but the current release doesn't have a branch either).

 Regards,

 Rajith

 On Mon, Feb 25, 2013 at 4:05 PM, Rafael Schloming r...@alum.mit.edu wrote:
 I've uploaded the artifacts and updated the download page[1]. It will be
 about 24 hours or so until the mirrors are fully synced.

 [1] http://qpid.apache.org/proton/download.html

 --Rafael

 On Mon, Feb 25, 2013 at 12:44 PM, Rafael Schloming r...@alum.mit.edu wrote:

 The vote carries with 5 +1's and 0 -1's. I'll upload the artifacts shortly.

 --Rafael

 On Thu, Feb 21, 2013 at 1:54 PM, Rafael Schloming r...@alum.mit.eduwrote:

 Hi everyone, I've spun an RC3 with fixes for the two immediately soluble
 issues that turned up with RC2. Please check it out and cast your vote.

 Source is here:
   - http://people.apache.org/~rhs/qpid-proton-0.4rc3/

 Java binaries are here:
  - https://repository.apache.org/content/repositories/orgapacheqpid-292/

 Changes since RC2:

 PROTON-230, PROTON-246: Copying nested data fails in some cases
 PROTON-245: make swig skip pn_dtag for compatibility with older versions
 of swig

 [ ] Yes, I believe we should make 0.4 RC3 into 0.4 final
 [ ] No, because ...

Re: Parallel Maven and CMake build systems for Proton

[Rob Godfrey]

A few of supplementary points:

1) The CMake system will not be required to generate pom files or deploy to
maven repositories.
2) The CMake system will not be required to perform dynamic dependency
resolution
3) The CMake system will not be required to integrate with other build/test
tooling (coverage reports, style checkers, etc) which may be provided
within the maven build system

I'm also not sure exactly how well the CMake build system will work with
the Java build on Windows systems (my guess would be not well)... we
should probably look to make it work if we can, but this may not be trivial.

-- Rob


On 15 February 2013 11:03, Phil Harvey p...@philharveyonline.com wrote:

 During the review [1] of PROTON-238, Alan made the following,
 not-entirely-unreasonable-sounding comment:

 Having 2 parllel build systems is a serious pain, as qpid demonstrates.
 Wouldn't it be better to leave maven for Java and cmake for everything
 else? People who want to build Java probably can get maven.
 (Alan: please forgive me if I've taken this of context)

 I don't particularly want to open this can of worms again, but I think it
 is worth addressing this question. I believe the conclusions we reached in
 PROTON-194 were:

 - Our CMake build system will be capable of building and testing everything
 (both C and Java).  It is required because some users who wish to build
 Proton don't have Maven access.
 - Our Maven build system will be retained because it is a more standard
 build tool for Java developers.

 I acknowledge that maintaining both build systems is an annoying
 duplication of effort.  However, our requirements are to provide a
 convenient build system for all our users so we have no choice.

 Please shout if you disagree.

 Phil

 [1] https://reviews.apache.org/r/9433/

Re: Parallel Maven and CMake build systems for Proton

[Rob Godfrey]

On 15 February 2013 11:27, Rob Godfrey rob.j.godf...@gmail.com wrote:


 2) The CMake system will not be required to perform dynamic dependency
 resolution



I should probably have phrased that one better... What I meant is that
(unlike maven) we're not looking for the CMake build to go and find JARs,
resolve transient dependencies, and download to the machine you are
building on.

-- Rob

Re: Testing types in a message

[Rob Godfrey]

Hi Alan,

you can use the java Encoder/Decoders directly like this:

import org.apache.qpid.proton.codec.EncoderImpl;
import org.apache.qpid.proton.codec.DeccoderImpl;

...


ByteBuffer buf = ByteBuffer.allocate(2048);

DecoderImpl decoder = new DecoderImpl();
EncoderImpl encoder = new EncoderImpl(buf, decoder);

// write an array of 12 (false) booleans
boolean[] o = new boolean[12];
encoder.writeObject(o);

// buf will now contain the encoded data, call flip() to move
position to 0,
// limit end of encoded data
buf.flip();


// now read the encoded bytes

decoder.setByteBuffer(buf);

Object read = decoder.readObject();


...


Note that you need to set up both the encoder and the decoder even if
you only wish to use one (they are sort of co-dependent in a horrible
way that should be fixed some time).

There are defined types for all of the AMQP types... Described types
are a little more involved.. you can set the codec up to automatically
convert to the right Java class for a given described type.

-- Rob


On 15 February 2013 16:42, Alan Conway acon...@redhat.com wrote:

 On Fri, 2013-02-15 at 09:12 -0500, Rafael Schloming wrote:
  On Thu, Feb 14, 2013 at 5:44 PM, Alan Conway acon...@redhat.com wrote:
 
   I'm looking (in python first) to encode messages that contain all the
   different AMQP types. So far I was using the Data class to construct
   different AMQP data fragments. However I'd like to move towards using a
   map message as it's more widely decodable. So my question: how do I
   create a map message that contains specific AMQP types?  I.e. I want to
   differentiate between shorts, ints and longs, between symbols and
   strings etc. Just setting message.body = Data(...) does not work,
   message wants to have a python dict or list as a body.
  
 
  For the python binding I've defined the following classes to cover types
  that python doesn't natively support:
 
  class UnmappedType
  class ulong(long)
  class timestamp(long)
  class symbol(unicode)
  class char(unicode)
  class Described(object)
  UNDESCRIBED = Constant(UNDESCRIBED)
  class Array(object)
 
  So you should just be able to do:
 
  message.body = {uulong: ulong(1234), uchar: char(u\u1234),
  utimestamp: timestamp(12345678), udescribed-string:
  Described(symbol(url-descriptor), uhttp://blah;), uarray:
  Array(UNDESCRIBED, Data.INT, 1, 2, 3, 4), udescribed-array:
  Array(symbol(url-descriptor), uhttp://blah1;, uhttp://blah2;)}
 
  --Rafael

 I'm all good with the python binding. Now I'm trying to figure out what
 to do with Java (JNI and native), and soon with perl, php and ruby.

 For Java JNI I can use the Data object the same way I did in python, but
 Java native is a different story. In the jython test, all the codec test
 functions just throw unsupported-operation in the proton-j profile.

 proton_tests.codec.DataTest.testBinary .. skip
   ProtonUnsupportedOperationException:
 org.apache.qpid.proton.ProtonUnsupportedOperationException

 So I'm not sure how/if I can express AMQP types in proton-j.

 Cheers,
 Alan.

Re: Testing types in a message

[Rob Godfrey]

Of course, if you are using the Message class then there's really no
reason to go to the codec directly.  you can just use Java
Maps/Lists/Arrays etc, along with the Amqp specific types such as
UnsignedLong.

So you could have

Message msg = MessageFactory.createMessage();
Map map = new LinkedHashMap();
map.put(Symbol.valueof(key), new boolean[12]);
msg.setBody(new AmqpValue(map));


Which would set the body of the message to an AmqpValue section
containing a map with a Symbolic key and a boolean array as a value.

The above should work using either the JNI or pure Java implementation.

-- Rob

On 15 February 2013 17:03, Rob Godfrey rob.j.godf...@gmail.com wrote:
 Hi Alan,

 you can use the java Encoder/Decoders directly like this:

 import org.apache.qpid.proton.codec.EncoderImpl;
 import org.apache.qpid.proton.codec.DeccoderImpl;

 ...


 ByteBuffer buf = ByteBuffer.allocate(2048);

 DecoderImpl decoder = new DecoderImpl();
 EncoderImpl encoder = new EncoderImpl(buf, decoder);

 // write an array of 12 (false) booleans
 boolean[] o = new boolean[12];
 encoder.writeObject(o);

 // buf will now contain the encoded data, call flip() to move
 position to 0,
 // limit end of encoded data
 buf.flip();


 // now read the encoded bytes

 decoder.setByteBuffer(buf);

 Object read = decoder.readObject();


 ...


 Note that you need to set up both the encoder and the decoder even if
 you only wish to use one (they are sort of co-dependent in a horrible
 way that should be fixed some time).

 There are defined types for all of the AMQP types... Described types
 are a little more involved.. you can set the codec up to automatically
 convert to the right Java class for a given described type.

 -- Rob


 On 15 February 2013 16:42, Alan Conway acon...@redhat.com wrote:

 On Fri, 2013-02-15 at 09:12 -0500, Rafael Schloming wrote:
  On Thu, Feb 14, 2013 at 5:44 PM, Alan Conway acon...@redhat.com wrote:
 
   I'm looking (in python first) to encode messages that contain all the
   different AMQP types. So far I was using the Data class to construct
   different AMQP data fragments. However I'd like to move towards using a
   map message as it's more widely decodable. So my question: how do I
   create a map message that contains specific AMQP types?  I.e. I want to
   differentiate between shorts, ints and longs, between symbols and
   strings etc. Just setting message.body = Data(...) does not work,
   message wants to have a python dict or list as a body.
  
 
  For the python binding I've defined the following classes to cover types
  that python doesn't natively support:
 
  class UnmappedType
  class ulong(long)
  class timestamp(long)
  class symbol(unicode)
  class char(unicode)
  class Described(object)
  UNDESCRIBED = Constant(UNDESCRIBED)
  class Array(object)
 
  So you should just be able to do:
 
  message.body = {uulong: ulong(1234), uchar: char(u\u1234),
  utimestamp: timestamp(12345678), udescribed-string:
  Described(symbol(url-descriptor), uhttp://blah;), uarray:
  Array(UNDESCRIBED, Data.INT, 1, 2, 3, 4), udescribed-array:
  Array(symbol(url-descriptor), uhttp://blah1;, uhttp://blah2;)}
 
  --Rafael

 I'm all good with the python binding. Now I'm trying to figure out what
 to do with Java (JNI and native), and soon with perl, php and ruby.

 For Java JNI I can use the Data object the same way I did in python, but
 Java native is a different story. In the jython test, all the codec test
 functions just throw unsupported-operation in the proton-j profile.

 proton_tests.codec.DataTest.testBinary .. 
 skip
   ProtonUnsupportedOperationException:
 org.apache.qpid.proton.ProtonUnsupportedOperationException

 So I'm not sure how/if I can express AMQP types in proton-j.

 Cheers,
 Alan.

Re: Testing types in a message

[Rob Godfrey]

On 15 February 2013 19:17, Alan Conway acon...@redhat.com wrote:
 On Fri, 2013-02-15 at 17:22 +0100, Rob Godfrey wrote:
 Of course, if you are using the Message class then there's really no
 reason to go to the codec directly.  you can just use Java
 Maps/Lists/Arrays etc, along with the Amqp specific types such as
 UnsignedLong.

 So you could have

 Message msg = MessageFactory.createMessage();
 Map map = new LinkedHashMap();
 map.put(Symbol.valueof(key), new boolean[12]);
 msg.setBody(new AmqpValue(map));


 Which would set the body of the message to an AmqpValue section
 containing a map with a Symbolic key and a boolean array as a value.


 Thanks Rob, this is great info.

 How would I do the converse using a Message? e.g. if decode a message
 with an AMQP list I see the Message.getBody() returns an AMQPValue.  How
 do I convert that to I can iterate over?

So you can call getValue() on the AmqpValue object, which will return
the Java object representation of the AMQP object sent.  In this case
you would get some implementation of java.util.List, which you could
then iterate over in the standard Java way.

Object body = msg.getBody();
if(body instanceof AmqpValue)
{
Object valueObject = ((AmqpValue)body).getValue();
if(valueObject instanceof List)
{
for(Object element : (List) valueObject)
{
...

-- Rob


 The above should work using either the JNI or pure Java implementation.

 -- Rob

 On 15 February 2013 17:03, Rob Godfrey rob.j.godf...@gmail.com wrote:
  Hi Alan,
 
  you can use the java Encoder/Decoders directly like this:
 
  import org.apache.qpid.proton.codec.EncoderImpl;
  import org.apache.qpid.proton.codec.DeccoderImpl;
 
  ...
 
 
  ByteBuffer buf = ByteBuffer.allocate(2048);
 
  DecoderImpl decoder = new DecoderImpl();
  EncoderImpl encoder = new EncoderImpl(buf, decoder);
 
  // write an array of 12 (false) booleans
  boolean[] o = new boolean[12];
  encoder.writeObject(o);
 
  // buf will now contain the encoded data, call flip() to move
  position to 0,
  // limit end of encoded data
  buf.flip();
 
 
  // now read the encoded bytes
 
  decoder.setByteBuffer(buf);
 
  Object read = decoder.readObject();
 
 
  ...
 
 
  Note that you need to set up both the encoder and the decoder even if
  you only wish to use one (they are sort of co-dependent in a horrible
  way that should be fixed some time).
 
  There are defined types for all of the AMQP types... Described types
  are a little more involved.. you can set the codec up to automatically
  convert to the right Java class for a given described type.
 
  -- Rob
 
 
  On 15 February 2013 16:42, Alan Conway acon...@redhat.com wrote:
 
  On Fri, 2013-02-15 at 09:12 -0500, Rafael Schloming wrote:
   On Thu, Feb 14, 2013 at 5:44 PM, Alan Conway acon...@redhat.com wrote:
  
I'm looking (in python first) to encode messages that contain all the
different AMQP types. So far I was using the Data class to construct
different AMQP data fragments. However I'd like to move towards using 
a
map message as it's more widely decodable. So my question: how do I
create a map message that contains specific AMQP types?  I.e. I want 
to
differentiate between shorts, ints and longs, between symbols and
strings etc. Just setting message.body = Data(...) does not work,
message wants to have a python dict or list as a body.
   
  
   For the python binding I've defined the following classes to cover types
   that python doesn't natively support:
  
   class UnmappedType
   class ulong(long)
   class timestamp(long)
   class symbol(unicode)
   class char(unicode)
   class Described(object)
   UNDESCRIBED = Constant(UNDESCRIBED)
   class Array(object)
  
   So you should just be able to do:
  
   message.body = {uulong: ulong(1234), uchar: char(u\u1234),
   utimestamp: timestamp(12345678), udescribed-string:
   Described(symbol(url-descriptor), uhttp://blah;), uarray:
   Array(UNDESCRIBED, Data.INT, 1, 2, 3, 4), udescribed-array:
   Array(symbol(url-descriptor), uhttp://blah1;, uhttp://blah2;)}
  
   --Rafael
 
  I'm all good with the python binding. Now I'm trying to figure out what
  to do with Java (JNI and native), and soon with perl, php and ruby.
 
  For Java JNI I can use the Data object the same way I did in python, but
  Java native is a different story. In the jython test, all the codec test
  functions just throw unsupported-operation in the proton-j profile.
 
  proton_tests.codec.DataTest.testBinary .. 
  skip
ProtonUnsupportedOperationException:
  org.apache.qpid.proton.ProtonUnsupportedOperationException
 
  So I'm not sure how/if I can express AMQP types in proton-j.
 
  Cheers,
  Alan.
 

[jira] [Updated] (PROTON-61) Need a means of specifying and reading connection capabilities properties

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-61:
--

Assignee: Rafael H. Schloming  (was: Rob Godfrey)

 Need a means of specifying and reading connection capabilities  properties
 ---

 Key: PROTON-61
 URL: https://issues.apache.org/jira/browse/PROTON-61
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Gordon Sim
Assignee: Rafael H. Schloming
  Labels: api
 Fix For: 0.4


 The properties are very useful for providing details about a client 
 connection for management purposes (pid, process name, client library version 
 etc).
 The capabilities are needed to turn on optional functionality (e.g. filters).

--
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

[jira] [Updated] (PROTON-60) Support configuring the max frame size.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-60:
--

Assignee: Philip Harvey

 Support configuring the max frame size.
 ---

 Key: PROTON-60
 URL: https://issues.apache.org/jira/browse/PROTON-60
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
Assignee: Philip Harvey
  Labels: api



--
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

[jira] [Updated] (PROTON-60) Support configuring the max frame size.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-60:
--

Fix Version/s: 0.4

 Support configuring the max frame size.
 ---

 Key: PROTON-60
 URL: https://issues.apache.org/jira/browse/PROTON-60
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
Assignee: Philip Harvey
  Labels: api
 Fix For: 0.4




--
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

[jira] [Updated] (PROTON-58) NullPointerException on receiver.recv(...)

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-58:
--

Assignee: Keith Wall

 NullPointerException on receiver.recv(...)
 --

 Key: PROTON-58
 URL: https://issues.apache.org/jira/browse/PROTON-58
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Keith Wall
  Labels: api

 Caused by: java.lang.NullPointerException
   at 
 org.apache.qpid.proton.engine.impl.ReceiverImpl.recv(ReceiverImpl.java:73)

--
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

[jira] [Updated] (PROTON-61) Need a means of specifying and reading connection capabilities properties

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-61:
--

Fix Version/s: 0.4

 Need a means of specifying and reading connection capabilities  properties
 ---

 Key: PROTON-61
 URL: https://issues.apache.org/jira/browse/PROTON-61
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Gordon Sim
Assignee: Rob Godfrey
  Labels: api
 Fix For: 0.4


 The properties are very useful for providing details about a client 
 connection for management purposes (pid, process name, client library version 
 etc).
 The capabilities are needed to turn on optional functionality (e.g. filters).

--
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

[jira] [Updated] (PROTON-66) Driver implementation for proton-j

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-66:
--

Fix Version/s: 0.4

 Driver implementation for proton-j
 --

 Key: PROTON-66
 URL: https://issues.apache.org/jira/browse/PROTON-66
 Project: Qpid Proton
  Issue Type: New Feature
Reporter: Rajith Attapattu
 Fix For: 0.4


 Provide an implementation for the Driver API.
 This consists of 3 interfaces. Connector, Listener and Driver.

--
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

[jira] [Updated] (PROTON-66) Driver implementation for proton-j

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-66:
--

Assignee: Gordon Sim

 Driver implementation for proton-j
 --

 Key: PROTON-66
 URL: https://issues.apache.org/jira/browse/PROTON-66
 Project: Qpid Proton
  Issue Type: New Feature
Reporter: Rajith Attapattu
Assignee: Gordon Sim
 Fix For: 0.4


 Provide an implementation for the Driver API.
 This consists of 3 interfaces. Connector, Listener and Driver.

--
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

[jira] [Updated] (PROTON-68) Porting Issue -- dll imports and exports on Visual Studio

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-68:
--

Fix Version/s: 0.4

 Porting Issue -- dll imports and exports on Visual Studio
 -

 Key: PROTON-68
 URL: https://issues.apache.org/jira/browse/PROTON-68
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
 Environment: Windows using Visual Studio 2010 
Reporter: Mary hinton
  Labels: build
 Fix For: 0.4


 Visual Studio dlls  use a macro to explicitly state which functions will be 
 exported. I don’t have a list of all the functions that will be exported, so 
 I just made the ones used by proton.c to be exportable. That left a lot that 
 would be internal to the dll only. Then when I was working with the python, I 
 realized that python was going to be importing a lot of functions from the 
 dll that should never be exported unless testing, so I defined another macro 
 for the python (ruby, etc) exported functions. Swig also had to be taken into 
 account. 
 This is what I’m using right now and it should work on the Linux/Unix 
 platform:
 #ifdef SWIGWIN
#define QPID_PROTON_API
 #else
#ifdef  _WINDOWS
   #ifdef qpid_proton_EXPORTS
  #define QPID_PROTON_API __declspec(dllexport)
  #ifdef qpid_proton_python_EXPORTS
#define QPID_PROTON_PY  __declspec(dllexport)
  #else
#define QPID_PROTON_PY 
  #endif
   #else
  #define QPID_PROTON_API __declspec(dllimport)
  #ifdef qpid_proton_python_IMPORTS
#define QPID_PROTON_PY __declspec(dllimport)
  #else
#define QPID_PROTON_PY
  #endif
   #endif
#else
   #define QPID_PROTON_API
#endif
 #endif
 That means all the headers will need to be changed to include the macros.
 e.g.
 QPID_PROTON_API  pn_data_t *pn_data(size_t capacity);
 QPID_PROTON_API  void pn_data_free(pn_data_t *data);
 QPID_PROTON_PY   int pn_data_errno(pn_data_t *data);

--
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

[jira] [Updated] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-98:
--

Fix Version/s: 0.4

 Porting Issue -- Visual Studio compiler requires explicit casts
 ---

 Key: PROTON-98
 URL: https://issues.apache.org/jira/browse/PROTON-98
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
 Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
  Labels: build
 Fix For: 0.4

 Attachments: explicitCasts2.patch, ExplicitCasts.patch


 I would like to get the code changed to add explicit casts where the Visual 
 Studio compiler requires it. 
 The GNU compiler isn’t so picky, but we need the explicit casts for Visual 
 Studio tools.
 The problem is in many of the files.
   C:\qpid\qpid\proton\proton-c\src\proton.c(278):  struct client_context *ctx 
 = (client_context *) pn_connector_context(ctor);// explicit 
 cast
   C:\qpid\qpid\proton\proton-c\src\buffer.c(41):  pn_buffer_t *buf = 
 (pn_buffer_t *) malloc(sizeof(pn_buffer_t)); // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\buffer.c(45):  buf-bytes = capacity ? 
 (char *) malloc(capacity) : NULL;   // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t) 
 PN_ARG_ERR;  // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t) 
 PN_ARG_ERR;  // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom-u.type = 
 (pn_type_t) va_arg(*ap, int);   // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311):  char **sptr 
 = (char **) ptr; // explicit 
 cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875):  pn_data_t *data = 
 (pn_data_t *) malloc(sizeof(pn_data_t));   // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878):  data-nodes = 
 capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL;   // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931):  data-nodes = 
 (pn_node_t *) realloc(data-nodes, data-capacity * sizeof(pn_node_t));   
  // explicit cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char 
 **sptr = (char**) ptr;
 // explicit cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t) 
 -1; // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t) 
 -1; // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32):  
 pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t), 
 1);  // explicit cast
   C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47):  disp-output 
 = (char *) malloc(disp-capacity);  // explicit 
 cast
   C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248):
 disp-output = (char *) realloc(disp-output, disp-capacity);// 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\driver.c(193):  pn_listener_t *l = 
 (pn_listener_t *) malloc(sizeof(pn_listener_t));// 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\driver.c(410):  pn_connector_t *c = 
 (pn_connector_t *) malloc(sizeof(pn_connector_t)); // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\driver.c(656):  pn_driver_t *d = 
 (pn_driver_t *) malloc(sizeof(pn_driver_t));  // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\driver.c(748):d-fds = (pollfd *) 
 realloc(d-fds, d-capacity*sizeof(struct pollfd));  // explicit cast
   C:\qpid\qpid\proton\proton-c\src\engine\engine.c(47):  db-deliveries = 
 (pn_delivery_state_t *) malloc(sizeof(pn_delivery_state_t) * capacity);// 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\engine\engine.c(438):  pn_connection_t 
 *conn = (pn_connection_t *)malloc(sizeof(pn_connection_t)); 
 // explicit cast
   C:\qpid\qpid\proton\proton-c\src\engine\engine.c(730):  pn_session_t *ssn = 
 (pn_session_t *) malloc(sizeof(pn_session_t));  // 
 explicit cast
   C:\qpid\qpid\proton\proton-c\src\engine\engine.c(866):  pn_transport_t 
 *transport = (pn_transport_t *) malloc(sizeof(pn_transport_t

[jira] [Updated] (PROTON-99) Porting Issue -- pn_dtag macro does not compile with Visual Studio compiler

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-99:
--

Fix Version/s: 0.4

 Porting Issue -- pn_dtag macro does not compile with Visual Studio compiler
 ---

 Key: PROTON-99
 URL: https://issues.apache.org/jira/browse/PROTON-99
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
 Environment: Windows using Visual Studio 2010 
Reporter: Mary hinton
  Labels: build
 Fix For: 0.4

 Attachments: pn_dtag.patch


 I would like to replace the pn_dtag macro with a function that will compile 
 using either GNU or  Visual Studio compilers.
 engine.h
 Replace:
 #define pn_dtag(BYTES, SIZE) ((pn_delivery_tag_t) {(SIZE), (BYTES)}
 With:
 pn_delivery_tag_t pn_dtag(const char *bytes, size_t size);
 engine.c
 Add:
 pn_delivery_tag_t pn_dtag(const char *bytes, size_t size) 
 {
   pn_delivery_tag_t delivt;
   delivt.bytes = bytes;
   delivt.size = size;
   return delivt;
 }

--
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

[jira] [Commented] (PROTON-109) Proton should handle inbound max-frame size violations.

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13575846#comment-13575846
 ] 

Rob Godfrey commented on PROTON-109:


proton-j will also need this change implemented

 Proton should handle inbound max-frame size violations.
 ---

 Key: PROTON-109
 URL: https://issues.apache.org/jira/browse/PROTON-109
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Ken Giusti

 According to the spec, if the local proton-c client has configured a maximum 
 frame size, and the remote attempts to send a frame that violates that size:
 A peer that receives an oversized frame MUST close the Connection with the 
 framing-error error-code.
 Need to verify this behavior is handled.

--
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

[jira] [Updated] (PROTON-110) java.lang.NullPointerException: the handle field is mandatory

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-110:
---

Assignee: Keith Wall

 java.lang.NullPointerException: the handle field is mandatory
 -

 Key: PROTON-110
 URL: https://issues.apache.org/jira/browse/PROTON-110
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Keith Wall

 I saw the following NPE while using proton:
 java.lang.NullPointerException: the handle field is mandatory
   at 
 org.apache.qpid.proton.type.transport.Transfer.setHandle(Transfer.java:67)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.processMessageData(TransportImpl.java:403)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.transportOutput(TransportImpl.java:212)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.access$000(TransportImpl.java:54)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl$1.output(TransportImpl.java:118)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.output(TransportImpl.java:177)

--
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

[jira] [Commented] (PROTON-147) Don't send a Sender Disposition until the all the transfers for a delivery have been sent.

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13575874#comment-13575874
 ] 

Rob Godfrey commented on PROTON-147:


IIRC after discussion I think we concluded that it was perfectly acceptable to 
send a disposition for a message which had not yet been completely sent.  It is 
an interesting test case for the receiving party to ensure that they handle 
such a sequence correctly

The only issue would be if a settlement state is sent in a disposition prior to 
all frames being transferred, when the application did not order the updates in 
this order.

Can you clarify if there is a bug here?

 Don't send a Sender Disposition until the all the transfers for a delivery 
 have been sent.
 --

 Key: PROTON-147
 URL: https://issues.apache.org/jira/browse/PROTON-147
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
 Attachments: PROTON-147.patch




--
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

[jira] [Updated] (PROTON-184) [Proton-J] Separate API from Pure Java Implementation

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-184:
---

Fix Version/s: 0.4

 [Proton-J] Separate API from Pure Java Implementation
 -

 Key: PROTON-184
 URL: https://issues.apache.org/jira/browse/PROTON-184
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-j
Reporter: Rob Godfrey
Assignee: Rob Godfrey
 Fix For: 0.4


 In preparation for providing a binding of proton-c to Java, and to reflect 
 the separation between interface and implementation already present in 
 proton-j, the API interface for proton-j should be separated from the 
 implementation

--
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

[jira] [Resolved] (PROTON-184) [Proton-J] Separate API from Pure Java Implementation

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-184.


Resolution: Fixed

 [Proton-J] Separate API from Pure Java Implementation
 -

 Key: PROTON-184
 URL: https://issues.apache.org/jira/browse/PROTON-184
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-j
Reporter: Rob Godfrey
Assignee: Rob Godfrey
 Fix For: 0.4


 In preparation for providing a binding of proton-c to Java, and to reflect 
 the separation between interface and implementation already present in 
 proton-j, the API interface for proton-j should be separated from the 
 implementation

--
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

[jira] [Resolved] (PROTON-192) Implement Proton-JNI binding for proton-c

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-192.


Resolution: Fixed

 Implement Proton-JNI binding for proton-c
 -

 Key: PROTON-192
 URL: https://issues.apache.org/jira/browse/PROTON-192
 Project: Qpid Proton
  Issue Type: New Feature
Reporter: Keith Wall
Assignee: Rob Godfrey
 Fix For: 0.4


 Expose proton-c via the Java proton API using swig/JNI.

--
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

[jira] [Reopened] (PROTON-219) Move Cmake modules to the tools directory

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reopened PROTON-219:



The cmake directory (and its sub-sirs) are still present

see: svn.apache.org/repos/asf/qpid/proton/trunk//?p=1442578



 Move Cmake modules to the tools directory
 -

 Key: PROTON-219
 URL: https://issues.apache.org/jira/browse/PROTON-219
 Project: Qpid Proton
  Issue Type: Bug
Reporter: Darryl L. Pierce
Assignee: Darryl L. Pierce
 Fix For: 0.4


 To keep things from filling up the root directory of the repository, and to 
 keep like items together, build similar tools should be kept in a 
 subdirectory named tools off of the root of the repo.

--
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

Re: Reducing the visibility of proton-j constructors

[Rob Godfrey]

What's your need for the direct constructor?


-- Rob

On 25 January 2013 15:49, Hiram Chirino hi...@hiramchirino.com wrote:
 Let me clarify, I have no problem with adding Factories and using them
 everywhere possible.  Just don't take my access away from direct
 constructors.


 On Fri, Jan 25, 2013 at 9:39 AM, Rob Godfrey rob.j.godf...@gmail.comwrote:

 In general dependency on implementation is bad, dependency on interface is
 better.  One of the problems we've had with Qpid historically is it become
 hard to test as we have dependencies on implementation everywhere.

 From an end user perspective the difference is only replacing

 X x  = new X();

 with

 X x = XFactory.newInstance();

 But it makes it a lot easier to properly describe the functionality being
 returned. For implementation reasons, the concrete class may have public
 methods that are not intended to be exposed to the application programmer
 but only to other cooperating classes.  To avoid confusion, and to make it
 clear to us the delta between the shared API and the API extensions that
 we are supporting for the pure Java implementation the interfaces seem like
 the right way to go for me.

 The idea is that those who need the extension features will still have a
 very clear way to get the implementation that provides these, without ever
 having to cast.

 -- Rob





 On 24 January 2013 20:03, Rafael Schloming r...@alum.mit.edu wrote:

  On Thu, Jan 24, 2013 at 5:06 AM, Rob Godfrey rob.j.godf...@gmail.com
  wrote:
 
   On 23 January 2013 17:36, Phil Harvey p...@philharveyonline.com
 wrote:
   
As part of the Proton JNI work, I would like to remove all calls to
proton-j implementation constructors from client code.  I intend
 that
factories will be used instead [1], thereby abstracting away whether
  the
implementation is pure Java or proton-c-via-JNI.
   
I'd like to check that folks are happy with me making this change,
 and
  to
mention a couple of problems I've had.
   
In this context, client code is anything outside the current
sub-component, where our sub-components are Engine, Codec, Driver,
   Message
and Messenger, plus each of the contrib modules, and of course third
   party
code.
   
To enforce this abstraction, I am planning to make the constructors
 of
   the
affected classes package-private where possible.  I believe that,
   although
third party projects might already be calling these constructors, it
 is
acceptable for us to change its public API in this manner while
 Proton
  is
such a young project.
   
  
   +1 to all of the above
  
   
Please shout if you disagree with any of the above.
   
Now, onto my problem.  I started off with the
   org.apache.qpid.proton.engine.
impl package, and found that  o.a.q.p.hawtdispatch.impl.AmqpTransport
   calls
various methods on ConnectionImpl and TransportImpl, so simply using
 a
Connection and Transport will not work.  I don't know what to do
 about
this, and would welcome people's opinions.
   
  
   So, the simplest change would be to change the factories to use
   covariant return types
  
   e.g. EngingFactoryImpl becomes:
  
   @Override
   public ConnectionImpl createConnection()
   {
   return new ConnectionImpl();
   }
  
   @Override
   public TransportImpl createTransport()
   {
   return new TransportImpl();
   }
  
  
   ... etc
  
   Code that requires the extended functionality offered by the pure Java
   implementation can thus instantiate the desired Factory directly.
  
 
  What's the point of going through the factory in this scenario rather
 than
  directly instantiating the classes as Hiram suggests? Is there some class
  of thing the factory would/could do that the constructor can't/shouldn't?
 
  A second refinement might be to actually separate out the interface
   and implementation within the pure Java implementation so that we have
   a well defined extended Java API.  This interface could then be the
   return type of the factory.
  
 
  Maybe I'm misunderstanding, but what's the point of using an interface
 here
  if you're still locked into the pure Java impl? Are you expecting to swap
  out that impl under some circumstances?
 
  --Rafael
 




 --

 **

 *Hiram Chirino*

 *Engineering | Red Hat, Inc.*

 *hchir...@redhat.com hchir...@redhat.com | fusesource.com | redhat.com*

 *skype: hiramchirino | twitter: @hiramchirinohttp://twitter.com/hiramchirino
 *

 *blog: Hiram Chirino's Bit Mojo http://hiramchirino.com/blog/*

[jira] [Resolved] (PROTON-156) [proton-j] Detach close field is not being set to true.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-156.


Resolution: Fixed
  Assignee: Rob Godfrey

 [proton-j] Detach close field is not being set to true.
 ---

 Key: PROTON-156
 URL: https://issues.apache.org/jira/browse/PROTON-156
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Attachments: PROTON-156.patch




--
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

Re: Changing the Proton build system to accommodate jni bindings

[Rob Godfrey]

On 25 January 2013 18:07, Ken Giusti kgiu...@redhat.com wrote:
 Thank you Phil, for providing that summary.  And, although I don't want to 
 toss around a little gasoline (petrol), I have to ask:


 === System Tests ===

 Returning to another discussion point, note that the proton/tests
 folder
 will contain both Python and Java test suites, each of which can be
 run
 against either proton-c or proton-j. Their division of responsibility
 is
 something that will emerge over time, and does not need to be fully
 resolved right now.



 I'd like to know if the intent is to keep both the Java and Python test 
 suites synchronized.  That is, when I write a new python test, am I expected 
 to provide a similar test in Java?

 If we hold off that decision for later the suites will diverge and getting 
 them re-synced will be painful.

Since all the Python tests will continue to be run against the Java
implementation there will be no need to implement a test in Java if
you write it in Python.

We believe the Python tests will be runnable across more platforms
than the Java (since JVM support is not available on some hardware /
OS combinations), as such no Python test should be migrated to Java
since this would reduce coverage.

For reasons of developer efficiency / tool integration, Java tests
have advantages.  Rather than write unit tests which *only* run
against the Java code, we will be writing system tests that run
against the pure Java and the JNI bindings.  This will give us extra
test coverage of the C implementation (and the JNI binding code) in
addition to testing the Java implementation.

-- Rob


 -K

 - Original Message -
 As promised, here is a proper write-up of how we're planning to
 modify the
 Proton build system.


 === Requirements ===
 I've updated the Proton build system requirements wiki page:
 https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+requirements


 === Proposed solution ===

 The proposed solution changes Proton in two important ways.

 1. proton will built and distributed as a single project.
 This means that the released souce tarball will be created from the
 top
 level, not from the proton-c sub-folder.

 To support this, a CMakelists.txt file will be created at the top
 level.
 Therefore, an existing end user wishing to build proton-c will follow
 the
 usual steps when they receive the tar (e.g. tar xf proton.tar ; mkdir
 proton/build ; cd proton/build ; cmake .. ; make install).


 2. Both proton-c and proton-j will be buildable and testable using
 cmake,
 although proton-j will retain Maven support.

 Expanding our cmake build to include proton-j solves two problems,
 namely:
 (i) Satisfying the JNI binding's dependency on proton-api.jar and
 libqpid-proton.so.
 (ii) Allowing RHEL and Fedora users to build proton-j despite the
 lack of a
 recent Maven version on their platforms.

 The cmake Java build will assume that the developer has already
 downloaded
 dependencies (e.g. bouncycastle.jar for SSL support), and will not
 emulate
 Maven's ability to fetch them from remote repositories. This support
 could
 be added in the future if it is deemed necessary.



 Phil


 On 24 January 2013 21:05, Phil Harvey p...@philharveyonline.com
 wrote:

  In case anyone thinks World War 3 is about to break out, an
  approach
  emerged during the Proton task force meeting today that is probably
  acceptable to all the main protagonists.
 
  A brief summary follows. I've tried to avoid too many value
  judgements in
  the summary, to avoid fanning the embers.
 
  - We'll add a cmake file at the top level of the proton project,
  which
  will be able to build all of the Java and C code in one pass. This
  will be
  useful both for building the JNI bindings without undue
  contortions, and
  for building the entire project in Maven-less environments. The
  Maven pom
  files will remain, for use in more mainstream Java deployments.
 
  - No duplication of the proton-api code.
 
  - The source tarball will in the future be generated from the top
  level,
  rather than from the proton-c folder. This avoids the issues
  previously
  discussed whereby JNI bindings can't be built because proton-api is
  missing from the tarball. The new top level cmake file will mean
  that the
  commands required to build proton-c will be unchanged.
 
  I'll write up some proper notes this evening if I get a chance, and
  will
  update the wiki.
 
  Going back to Rajith's point earlier in this discussion, it is of
  course
  important that decisions like this are debated and agreed in
  public, so
  rest assured this will all be written up and Jira'd properly so
  that
  everyone has the opportunity to comment.
 
  Phil
  On Jan 24, 2013 3:01 PM, Rob Godfrey rob.j.godf...@gmail.com
  wrote:
 
  On 24 January 2013 15:49, Rafael Schloming r...@alum.mit.edu
  wrote:
   On Wed, Jan 23, 2013 at 6:44 PM, Rob Godfrey
   rob.j.godf...@gmail.com
  wrote:
  
   Firstly I think it would be helpful

Re: Reducing the visibility of proton-j constructors

[Rob Godfrey]

On 23 January 2013 17:36, Phil Harvey p...@philharveyonline.com wrote:

 As part of the Proton JNI work, I would like to remove all calls to
 proton-j implementation constructors from client code.  I intend that
 factories will be used instead [1], thereby abstracting away whether the
 implementation is pure Java or proton-c-via-JNI.

 I'd like to check that folks are happy with me making this change, and to
 mention a couple of problems I've had.

 In this context, client code is anything outside the current
 sub-component, where our sub-components are Engine, Codec, Driver, Message
 and Messenger, plus each of the contrib modules, and of course third party
 code.

 To enforce this abstraction, I am planning to make the constructors of the
 affected classes package-private where possible.  I believe that, although
 third party projects might already be calling these constructors, it is
 acceptable for us to change its public API in this manner while Proton is
 such a young project.


+1 to all of the above


 Please shout if you disagree with any of the above.

 Now, onto my problem.  I started off with the org.apache.qpid.proton.engine.
 impl package, and found that  o.a.q.p.hawtdispatch.impl.AmqpTransport calls
 various methods on ConnectionImpl and TransportImpl, so simply using a
 Connection and Transport will not work.  I don't know what to do about
 this, and would welcome people's opinions.


So, the simplest change would be to change the factories to use
covariant return types

e.g. EngingFactoryImpl becomes:

@Override
public ConnectionImpl createConnection()
{
return new ConnectionImpl();
}

@Override
public TransportImpl createTransport()
{
return new TransportImpl();
}


... etc

Code that requires the extended functionality offered by the pure Java
implementation can thus instantiate the desired Factory directly.

A second refinement might be to actually separate out the interface
and implementation within the pure Java implementation so that we have
a well defined extended Java API.  This interface could then be the
return type of the factory.

-- Rob



 Thanks
 Phil

 [1] for example, these work-in-progress classes:
 https://svn.apache.org/repos/asf/qpid/proton/branches/jni-binding/proton-j/proton-api/src/main/java/org/apache/qpid/proton/ProtonFactoryLoader.java
 https://svn.apache.org/repos/asf/qpid/proton/branches/jni-binding/proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/EngineFactory.java
 https://svn.apache.org/repos/asf/qpid/proton/branches/jni-binding/proton-j/proton/src/main/java/org/apache/qpid/proton/engine/impl/EngineFactoryImpl.java
 https://svn.apache.org/repos/asf/qpid/proton/branches/jni-binding/proton-c/bindings/java/jni/src/main/java/org/apache/qpid/proton/engine/jni/JNIEngineFactory.java

Re: Changing the Proton build system to accommodate jni bindings

[Rob Godfrey]

On 24 January 2013 14:43, Rafael Schloming r...@alum.mit.edu wrote:
 On Wed, Jan 23, 2013 at 6:10 PM, Rob Godfrey rob.j.godf...@gmail.comwrote:

 On 23 January 2013 19:09, Rafael Schloming r...@alum.mit.edu wrote:

  I've added another wiki page that documents the proton release steps as
  best I can remember. I'll updated it more during the 0.4 release:
  https://cwiki.apache.org/confluence/display/qpid/Proton+Release+Steps
 
  I think it's important to understand the overall release and testing
  process as it is a significant and perhaps underrepresented factor
 against
  which to measure any proposals. I believe the build system requirements
  documented below are inherently incomplete as they don't recognize the
 fact
  that the C build system is not just a developer productivity tool, it is
  also the installer for our end users. And before anyone says our end
 users
  will just use yum or equivalents, all those packaging tools *also* depend
  on our build system both directly, and because we can't even supply a
  release for packagers to consume without a reasonable amount of direct
  install testing. To a good extent a standard looking C source tarball is
  pretty much the equivalent of a jar or jar + pom file in the Java world,
  it's really the only platform independent means of distribution we have.
 
 
 It would be helpful if you could enumerate requirements which you believe
 to be missing and add the to the existing wiki page.  I don't think anyone
 is suggesting that the make install step should be broken in the source
 tarball, so it's a little unclear to me the problem you are trying to
 highlight above.


 I believe it was suggested at one point that we not have a C source tarball
 but just export the entire tree as a single source tarball. This strictly
 speaking would not break the make install step, however it would have a
 serious impact on our ability to leverage others to test the C impl. Anyone
 downloading this would need to understand a great deal about the dual
 nature of proton and how it is structured just in order to know that they
 can ignore half the tree. Compare that with a standard C source tarball
 where I can hand it off to someone who knows nothing about proton and
 simply tell them to do a make install and then run one test script. Given
 the latter structure to our release artifacts there are *significantly*
 more resources we have access to in order to perform the testing necessary
 to do a quality release.


I'm not sure requiring the ability to read a README file is really
going to have a huge impact on our ability to leverage others. I'm not
sure how widespread CMake use is (it's certainly less familiar to me
than autotools) - certainly I expect people unfamiliar with cmake will
have to read the README anyway.



 I'll take a stab at distilling some requirements out of the above scenario
 and sticking them onto the wiki page, but I actually think the scenario
 itself is more important than the requirements. There's no disagreement
 that it would be nice to have a very standard looking C source tarball with
 minimal dependencies and so forth that can be used in the above manner,
 it's simply the relative priority of the requirement when it conflicts with
 developer convenience that is a source of contention.



  It's also probably worth noting that perhaps the biggest issue with
 system
  tests in Java is not so much imposing maven on proton-c developers, but
 the and nottest against Java code running elsewhere.

  fact that Java may not be available on all the platforms that proton-c
  needs to be tested on. My primary concern here would be iOS. I'm not an
  expert, but my brief googling seems to suggest there would be significant
  issues.
 
 
 So, I think we probably need to consider what sort of tests are required,
 and which languages it is appropriate to write any particular type of test
 in.  For me tests in Java have some advantages over Python tests. Firstly
 they allow interop tests between the two implementations within the same
 process


 Can you elaborate on the benefits of this? It seems to me when it comes to
 interop testing that, to the extent you can get away with it, over the wire
 tests would be preferred. For example you could run proton-c on iOS via
 Java tests running on another system, to say nothing of testing against non
 proton implementations which would necessarily need to be over-the-wire.


The same arguments could be made about our existing tests. However
being able to run in process makes thing much easier to automate - no
need to randomly assign ports, communicate randomly assigned ports to
the other process, etc.


 and secondly they will also be able to be used against any future
 pure JavaScript Proton implementation (something we have planned to do but
 not yet embarked upon).


 This is also true of python tests. In fact the whole point of a python test
 suite is that you can run python, java, and javascript all within

Re: Changing the Proton build system to accommodate jni bindings

[Rob Godfrey]

On 23 January 2013 19:09, Rafael Schloming r...@alum.mit.edu wrote:

 I've added another wiki page that documents the proton release steps as
 best I can remember. I'll updated it more during the 0.4 release:
 https://cwiki.apache.org/confluence/display/qpid/Proton+Release+Steps

 I think it's important to understand the overall release and testing
 process as it is a significant and perhaps underrepresented factor against
 which to measure any proposals. I believe the build system requirements
 documented below are inherently incomplete as they don't recognize the fact
 that the C build system is not just a developer productivity tool, it is
 also the installer for our end users. And before anyone says our end users
 will just use yum or equivalents, all those packaging tools *also* depend
 on our build system both directly, and because we can't even supply a
 release for packagers to consume without a reasonable amount of direct
 install testing. To a good extent a standard looking C source tarball is
 pretty much the equivalent of a jar or jar + pom file in the Java world,
 it's really the only platform independent means of distribution we have.


It would be helpful if you could enumerate requirements which you believe
to be missing and add the to the existing wiki page.  I don't think anyone
is suggesting that the make install step should be broken in the source
tarball, so it's a little unclear to me the problem you are trying to
highlight above.


 It's also probably worth noting that perhaps the biggest issue with system
 tests in Java is not so much imposing maven on proton-c developers, but the
 fact that Java may not be available on all the platforms that proton-c
 needs to be tested on. My primary concern here would be iOS. I'm not an
 expert, but my brief googling seems to suggest there would be significant
 issues.


So, I think we probably need to consider what sort of tests are required,
and which languages it is appropriate to write any particular type of test
in.  For me tests in Java have some advantages over Python tests. Firstly
they allow interop tests between the two implementations within the same
process and secondly they will also be able to be used against any future
pure JavaScript Proton implementation (something we have planned to do but
not yet embarked upon).  A third issue for me is that when we start to
attempt more granular testing of things such as error handling, I will want
to ensure that the user experience is identical between the pure Java and
JNI binding implementations of the Java Proton API... if the tests are
being run through a second translation into the Python API then this is not
easily verifiable.

As a final aside, on the standard development environment many of us have
to work with, the installed version on Python is too old to support the
current Python client (lack of UUID, etc).

Personally I think the more tests we have the better, and it's more
important to encourage people to write tests than to force the use of a
particular language to write them in.  I'd also suggest that we should be
writing at least some tests for each of the idiomatic bindings.

-- Rob

--Rafael

 On Wed, Jan 23, 2013 at 12:45 PM, Phil Harvey p...@philharveyonline.com
 wrote:

  In case anyone has missed it, note that Gordon has added some relevant
  comments directly on the wiki pages:
 
 
 
 https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+requirements
 
 
 https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+proposals
 
  Phil
 
 
  On 23 January 2013 13:01, Keith W keith.w...@gmail.com wrote:
 
What are people's views on the relative priority of these
  requirements?
Are there any I've missed?  I think answering these questions is a
prerequisite for agreeing the technical solution.
  
   With the aim of stimulating discussion regarding our requirements and
   to reach a consensus, I've classified each of the proposed
   requirements into whether I believe each is essential, neutral or
   detrimental to the smooth development of Proton.
  
   (proposed requirement numbers from
  
  
 
 https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+requirements
   )
  
   Essential
  
   3. To change proton-api, all that is required is to edit a Java file.
   - Developer productivity
  
   4. To switch to a particular SVN revision, simple SVN commands are run
   (e.g. svn switch or svn update)
   - Developer productivity
  
   5. proton-c can be built, excluding its JNI binding, without requiring
   non-standard tools*
   6. proton-c can be built, excluding its JNI binding, from a standalone
   checkout of the proton-c directory
   - Developer productivity / tool familiarity
  
   Neutral
  
   1. A tarball source release of proton-c can be built by a user
   without an external dependency on any other part of proton, e.g.
   proton-api.
   2. The aforementioned proton-c tarball release can be produced by
   performing a 

Re: Changing the Proton build system to accommodate jni bindings

[Rob Godfrey]

Firstly I think it would be helpful if you made clear the requirements you
consider to be essential, nice to have,  unimportant and/or detrimental.

On 23 January 2013 20:17, Rafael Schloming r...@alum.mit.edu wrote:

 On Wed, Jan 23, 2013 at 8:01 AM, Keith W keith.w...@gmail.com wrote:

  Essential
 
  3. To change proton-api, all that is required is to edit a Java file.
  - Developer productivity
 

 This seems to be kind of a leading requirement so to speak, or at least
 it's phrased a little bit oddly. That said I would never argue with it for
 most of the Java files, however in the case of the API files I don't see
 how you're ever going to be able to stop after just editing the API.
 Because we have two implementations, we're fundamentally stuck with
 manually syncing the implementations themselves whenever a change to the
 interface occurs. By comparison the highly automatable task of syncing the
 API files themselves seems quite small. I'm imagining most changes would go
 something like this, say we want to add a getter to the Message interface,
 we would need to:


I think it's worth considering two different cases

1) The API change is purely on the Java side... there is no corresponding
change to the C API.  This may be to add some sort of convenience method,
or simply a refactoring.

In this case the developer making the change needs only to work in Java,
there will be two implementations of the interface to change (in two
different source locations) but is all rather trivial.

2) The API change affects both C and Java.

In this case either a single developer has to commit to making the change
in both the C and the Java, or the API change has to have been discussed
before work commences and Java and C developers will need to work
together.  If there is a single developer or developers working very
closely together then I would suggest that the steps would in fact be:

  1. edit the Message interface /  edit the message.h file
  2. write and/or modify a test (and Python binding if necessary)
  3. edit the JNI binding to use the SWIG generated API
  4. edit the C / Pure Java
  5. run the tests against the C / Java
  (6. modify other bindings if necessary)

  repeat steps 4 and 5 until they pass.

In the case where the C and Java developers are separated by time/distance
then the build / tests on one side will be broken until the implementation
catches up.  For the sake of politeness it is probably better to ensure
that at all points the checked in code compiles even if the tests do not
pass.  For cases where the changes to the API are additions then it should
be relatively easy to make the changes in such a way as to simply have any
tests relating to the new API be skipped. For cases where the C leads the
Java, the Java implementation can simply throw
UnsupportedOperationException or some such.  Where the Java leads the C we
can throw said exception from the JNI binding code and leave the .h file
unchanged until the C developer is ready to do the work.

Only for cases where there is modification to existing APIs does it seem
that there may be occaisins where we could not have a consistent build
across components, and I would strongly recommend that any change where the
Java and C are being worked on in such a fashion should take place on a
branch, with a merge to trunk only occurring when all tests are passing
against all implementations.


   1. edit the Message interface
   2. write and/or possibly modify a test
   3. edit the java Message implementation
   4. run the tests against java, if they don't pass go to step 2
   5. now that the java impl passes the tests, run the tests against the C
 impl
   6. if the sync check fails on the C build, run the sync script
   7. edit the message.h file
   8. edit the message.c implementation
   9. edit the adapter layer between the C API and the Java interfaces
   10. run the tests against the C, if they don't pass go to step 8
   11. run the tests against both, just to be sure
   12. check in

 Given the above workflow, it seems like even with a relatively small change
 like adding a getter, the scripted portion of the syncing effort is going
 to be vanishingly small compared to the manual process of syncing the
 implementations. Perhaps I'm just envisioning a different workflow than
 you, or maybe I'm missing some important scenarios. Could you describe what
 workflow(s) you envision and how the sync process would impacting your
 productivity?


I differ strongly in my opinion here. Every time I need to drop out of my
development environment to run some ad-hoc script then there is overhead...
Moreover if we are using svn to do this I presume we would be having to
check in any change before the sync could be made. This means that every
edit to a file now has to be followed by commit and sync (which would
obviously be an insane process).  Those of us behind corporate firewalls
and proxies experience very degraded response times when updating from the

Re: Changing the Proton build system to accommodate jni bindings

[Rob Godfrey]

On 21 January 2013 18:05, Rafael Schloming r...@alum.mit.edu wrote:

 On Mon, Jan 21, 2013 at 9:33 AM, Rob Godfrey rob.j.godf...@gmail.com
 wrote:

  Ummm... it's a dependency... you're familiar with those, yeah?
 
  The same way that the Qpid JMS clients depend on a JMS API jar, for which
  the source is readily available from another source. The JNI binding
 would
  build if the dependency was installed.  The same way I believe the SSL
 code
  in the core of proton-c builds if the dependency for it is installed.
 

 That's not really a proper analogy. Again the JMS interfaces are defined
 outside of qpid. We don't release them, and we depend only on a well
 defined version of them, we don't share a release cycle with them. If the
 JMS API was something that we developed/defined right alongside the impl
 and was part of the same release process, we would certainly not be allowed
 to release without the source.


This releasing without the source is a complete red herring and you know
it.  The source is released in whichever scheme we settle upon.

If you want an example of dependencies within the qpid project, how did the
AMQP 1.0 work on the C++ broker get released for 0.20?  Did all the proton
source get released with the C++ Broker / client?  In the future are you
expecting every part of the Qpid project which depends on proton to include
its full source?  If yes then how is the source tree going to work - is
everything to be a subdirectory of proton-c?

I agree that having the source for the version of the Java API included in
the source release bundle is advantageous. But if the collective decision
is that we have taken a religious position that the source tarballs can
only be svn exports of subdirectories of our source tree, then my
preference would be to use separated dependencies over duplication in the
repository.  Personally I would think that having a more flexible policy on
constructing the release source tarballs would make a lot more sense.

-- Rob


 --Rafael

Re: mailing lists and fragmented communication

[Rob Godfrey]

On 21 January 2013 12:43, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 I'm happy enough with the idea of collapsing proton@ given that Protons
 scope is in some ways wider than when it started out (where the very
 specific protocol library made a good case for a separate list), but I
 don't think that list being separate is the main source of most of the
 confusion with proton. People have asked roughly the same basic questions
 about proton on users@ and proton@ at roughly the same time, which did
 indeed mean certain discussion with answers might have only gone to one of
 the lists at a time, but the key point for me was that they had to ask
 those basic questions on either list in the first place.


+1


 We are talking about improving communication, and for me the main problem
 is often that information isn't being written down or sent to any of the
 lists until someone asks a question requiring it. That question typically
 gets met with a [large] email explaining the answer, but much of the time
 it should be possible for the response to just be a link to somewhere the
 answer is already written down in general, e.g the website, with perhaps
 some context-specific additions. Some website update stats would probably
 entertaining right about now for example.


Completely agreed (and hands up to not personally having updated the
website in ages).


 I think users@ and dev@ should be left as is, and that we potentially just
 adjust how we use them slightly. These lists have existed for several
 years, and its the structure almost every Apache project works away just
 fine with; I don't think we are all that special in this regard. I also
 don't think we should subscribe everyone to a bunch of traffic they didn't
 sign up for. That said, this doesn't mean developers actually need to post
 discussion mails to dev@, the users@ list is always there and I know
 Gordon
 at least often posts only to that if it is a user related discussion, and I
 think that approach works well enough if others were to use it. The dev@
 list can continue at least to hold things like the JIRA traffic (I could
 see ReviewBoard postings going to either list), even if general discussion
 moves to the users@ list.


Personally I'd have JIRAs and ReviewBoards on dev and make sure everything
else was on users.  However I agree with your main point that it's not the
multitude of mailing lists that is necessarily the issue... it's the fact
that information isn't available *anywhere* :-)


 Summarising, I agree we need to be better at communicating, I think a bit
 of mailing list adjustment would be a good thing where proton@ could go
 and
 dev@ should stay in some guise, but that there are other problems with our
 communication that reducing the number of mailing lists potentially does
 little to solve.


Agreed,
Rob


 Robbie


 On 18 January 2013 17:21, Gordon Sim g...@redhat.com wrote:

  I believe that we have too many mailing lists and that we are missing out
  on valuable collaboration and transparency as a result.
 
  Too often in the past topics have been discussed on the dev list without
  reflecting any of the discussion back to the user list, keeping a large
  part of the community in the dark. Now that we have a distinct list for
  proton there is the possibility of yet more fragmentation.
 
  I honestly believe that we would be better off with just one list for
  discussions. I think there will increasingly be issues that cross-cut
  different components or that would benefit from wider participation. Not
  all topics will be of interest to all subscribers, but that is always
 going
  to be the case.
 
  It doesn't seem to me like any of the lists are so high in volume that
  this would cause significant problems. More rigorous use of subject could
  help people filter if needed. (JIRA and commit notices I think do warrant
  their own lists allowing a lot of the 'noise' to be avoided if so
 desired).
 
  Any other thoughts on this? Does anyone have fears of being deluged with
  unwanted emails?
 
  --**--**-
  To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org
 users-unsubscr...@qpid.apache.org
  For additional commands, e-mail: users-h...@qpid.apache.org
 
 

Re: Changing the Proton build system to accommodate jni bindings

[Rob Godfrey]

On 21 January 2013 15:11, Rafael Schloming r...@alum.mit.edu wrote:

 On Mon, Jan 21, 2013 at 7:10 AM, Rob Godfrey rob.j.godf...@gmail.com
 wrote:

  
 
This results in something that is quite awkward for the C build. For
  one
thing I'm not sure an svn export of the proton-c directory would be
considered releasable under this scheme as it would include the java
binding, but not the source code necessary to build it, and apache
  policy
requires releases to include full source code. Regardless it would no
longer be a useful/sensible artifact to end-users since they couldn't
actually build the java binding.
   
  
  
  This seems a slightly odd position to take. The artefact doesn't include
  the entire source to python, ruby, openssl, etc.  If the dependencies for
  these are not present then the relevant parts of the tree are not built.
   The same is true in this proposal with respect to the java binding...
  there is a dependency on the Java API being installed in order to build
 the
  JNI bindings within the C build.
 

 The problem isn't with not including the source code to external
 dependencies (i.e. Java in your analogy), the problem is with the fact that
 all of the Java binding (the API and the JNI implementation of it) is
 developed within the qpid project, and the artifact would not include all
 of it. The apache release policy is quite clear on this front:

 The Apache Software Foundation produces open source software. All releases
 are in the form of the source materials needed to make changes to the
 software being released. In some cases, binary/bytecode packages are also
 produced as a convenience to users that might not have the appropriate
 tools to build a compiled version of the source. In all such cases, the
 binary/bytecode package must have the same version number as the source
 release and may only add binary/bytecode files that are the result of
 compiling that version of the source code release.

 Producing an artifact that has source code for impls, but not source for
 the interfaces would quite clearly constitute an artifact that didn't
 include all the source materials needed to make changes.



Ummm... it's a dependency... you're familiar with those, yeah?

The same way that the Qpid JMS clients depend on a JMS API jar, for which
the source is readily available from another source. The JNI binding would
build if the dependency was installed.  The same way I believe the SSL code
in the core of proton-c builds if the dependency for it is installed.


 I must admit I remain bemused by the idea that trying to maintain two
  copies of the Java API in the source tree makes any kind of sense.
 
  I think we are contorting ourselves and adding potentially huge
  complication to our build/development process in order to try to satisfy
 a
  number of somewhat arbitrary requirements that are being imposed on the
  directory structure.
 

 You're arguing against a straw man here. Nobody has proposed copying the
 API the way you keep describing it. The original solution implemented on
 the JNI branch was to have the API in two places at once via svn externals.


This isn't in two places... it's very clearly in one place in the
repository, with another place linking to it, through a rather inelegant
manner.

Having said that, the externals solution is not a particularly pleasant
solution and was only put in place because of the requirement to be able
to check out from a subdirectory of proton.  Having further considered the
matter, my feeling is that it is better to re-examine the need to be able
to check out just a single subdirectory of the proton tree.


 This however does violate one of the fundamental tenants of source
 control as you put it since it fundamentally loses track of what version
 of the API source goes with what version of the implementation source.



Umm... no it doesn't.  Again... I'm not pushing for svn:externals but if
you insist on the each subdirectory must be provide able to be
independently checked out then I think svn:externals is a better solution
than the copy.  The original svn:externals proposal makes it very clear
that the version of the Java API code that the JNI binding works with must
be the same as that which the Java impl works with.  The externals is to a
sibling directory within the same project.  So long as you consider the
proton project as a whole then it is never unclear as to which version you
should be using.  Only in w orld where the Java and C versions are not
progressed with a common API does this become a problem.  If you do not
believe the two should have a common API then I think we need to have a
wider discussion (since we've been working pretty hard until now to keep
the APIs in sync).


 Branching the API into two places and putting the necessary scripts in
 place to enforce that the C version of that branch is a read only copy of
 the Java version is simply another way to achieve exactly what is currently

Re: inconsistent proton library names?

[Rob Godfrey]

I've not looked at the branch lately (only just back from vacation), but I
would very much hope that there would be nothing preventing having both the
JNI and native-Java libraries in the classpath, and allowing for explicit
creation of the desired implementation of Connection / Messenger / whatever
(which I'd probably suggest be done via a factory rather explicit
construction, but that's just personal taste).  I would hope the Service
Loader would only affect the implementation created by *default* from a
factory

-- Rob




On 4 January 2013 22:54, Phil Harvey p...@philharveyonline.com wrote:

 The in-progress code on the jni branch does not currently allow this,
 although is no technical barrier to doing it. We just haven't yet decided
 on the nicest api for allowing the application to choose the implementation
 it wants.

 The ability to mix implementations within a jvm will certainly be nice when
 writing interoperability tests.

 Phil
 On Jan 4, 2013 9:16 PM, Rafael Schloming r...@alum.mit.edu wrote:

  Does that mean you won't be able to use both the C and Java
 implementation
  simultaneously within a single JVM?
 
  --Rafael
 
  On Fri, Jan 4, 2013 at 4:02 PM, Phil Harvey p...@philharveyonline.com
  wrote:
 
   Ditto for Java.  From the developer's point of view, they'll simply be
   using the Java interfaces in proton-api such as Connection [1].
  
   Our current intention is that the choice of whether to use the pure
 Java
   implementations or the proton-c-via-Swig-via-JNI one will be made
 using a
   factory instantiated by a java.util.ServiceLoader.  The decision will
   therefore depend on your runtime classpath.  Client code will not have
 a
   build time dependency on the Swig/JNI layer.
  
   [1]
  
  
 
 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Connection.java
  
  
   On 4 January 2013 20:40, Darryl L. Pierce dpie...@redhat.com wrote:
  
On Fri, Jan 04, 2013 at 03:32:44PM -0500, Rafael Schloming wrote:
 Given what little I know of loading JNI stuff, that seems to make
  sense
for
 Java.

 FWIW, the python and ruby bindings don't ever actually expose the
  name
   of
 the C extension library since in both cases we have the so-called
 buttercream frosting layer that wraps the raw C extension
 module. I
would
 hope we'd have something similar for perl and Java so that these
  names
 shouldn't ever be visible to users.
   
Per does. It uses qpid::proton namespace for the Message and
 Messenger
classes.
   
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
   
   
  
 

[jira] [Commented] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531400#comment-13531400
 ] 

Rob Godfrey commented on PROTON-186:


Patch applied (with modifications) to add the encode2 method to the java 
implementation.

 Message encode should always return the number of bytes needed to fully 
 encode the message
 --

 Key: PROTON-186
 URL: https://issues.apache.org/jira/browse/PROTON-186
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c, proton-j
Reporter: Hiram Chirino
 Attachments: PROTON-186v2.patch




--
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

[jira] [Assigned] (PROTON-127) Rename the org.apache.qpid.proton.type package for nicer Scala support

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-127:
--

Assignee: Rob Godfrey

 Rename the org.apache.qpid.proton.type package for nicer Scala support
 --

 Key: PROTON-127
 URL: https://issues.apache.org/jira/browse/PROTON-127
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
Priority: Minor

 'type' is a reserved word in Scala. So when using proton from scala, you end 
 up doing imports like:
 import org.apache.qpid.proton.`type`.messaging.Accepted
 Which is kinda ugly.   Would be nice if that package was renamed so something 
 else.  

--
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

[jira] [Resolved] (PROTON-127) Rename the org.apache.qpid.proton.type package for nicer Scala support

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-127.


   Resolution: Fixed
Fix Version/s: 0.3

The type package has been removed.  The public API classes/interfaces are now 
in an amqp package

 Rename the org.apache.qpid.proton.type package for nicer Scala support
 --

 Key: PROTON-127
 URL: https://issues.apache.org/jira/browse/PROTON-127
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
Priority: Minor
 Fix For: 0.3


 'type' is a reserved word in Scala. So when using proton from scala, you end 
 up doing imports like:
 import org.apache.qpid.proton.`type`.messaging.Accepted
 Which is kinda ugly.   Would be nice if that package was renamed so something 
 else.  

--
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

[jira] [Updated] (PROTON-81) Expose send/receive settle modes

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-81:
--

Component/s: (was: proton-j)

 Expose send/receive settle modes
 

 Key: PROTON-81
 URL: https://issues.apache.org/jira/browse/PROTON-81
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Hiram Chirino
Priority: Critical



--
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

[jira] [Commented] (PROTON-81) Expose send/receive settle modes

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507224#comment-13507224
 ] 

Rob Godfrey commented on PROTON-81:
---

This was resolved in commits 1399329,1399330 for proton-j, and was part of the 
0.2 release.

 Expose send/receive settle modes
 

 Key: PROTON-81
 URL: https://issues.apache.org/jira/browse/PROTON-81
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Hiram Chirino
Priority: Critical



--
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

[jira] [Resolved] (PROTON-145) 256K Messages do not get transfered properly with a 64k pump size

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-145.


   Resolution: Fixed
Fix Version/s: 0.3

 256K Messages do not get transfered properly with a 64k pump size
 -

 Key: PROTON-145
 URL: https://issues.apache.org/jira/browse/PROTON-145
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
 Fix For: 0.3

 Attachments: PROTON-145-Fix.patch, PROTON-145-Simplified.patch, 
 PROTON-145-Test.patch




--
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

[jira] [Resolved] (PROTON-173) Message annotations not properly encoded

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-173.


   Resolution: Fixed
Fix Version/s: 0.3
 Assignee: Rob Godfrey

Patch applied

 Message annotations not properly encoded
 

 Key: PROTON-173
 URL: https://issues.apache.org/jira/browse/PROTON-173
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Fix For: 0.3

 Attachments: PROTON-173.patch




--
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

[jira] [Commented] (PROTON-154) link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507406#comment-13507406
 ] 

Rob Godfrey commented on PROTON-154:


I've applied the patch for proton-j as a temporary measure since this is 
causing Hiram issues right now... but this is not a real solution - it will 
just manifest in different use cases being broken. 

 link attach, detach, attach sequence on single session does not result in a 
 new link for the 2nd attach
 ---

 Key: PROTON-154
 URL: https://issues.apache.org/jira/browse/PROTON-154
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
 Attachments: PROTON-154.patch, PROTON-154-test.patch


 Protocol trace:
 tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER, 
 sndSettleMode=0, rcvSettleMode=0, 
 source=Source{address='topic://testJoramTopic', durable=2, 
 expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null, 
 distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null, 
 capabilities=null}, target=Target{address='null', durable=0, 
 expiryPolicy=session-end, timeout=0, dynamic=false, 
 dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
 incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
 offeredCapabilities=null, desiredCapabilities=null, properties=null}
 tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER, 
 sndSettleMode=2, rcvSettleMode=0, 
 source=Source{address='topic://testJoramTopic', durable=2, 
 expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null, 
 distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null, 
 capabilities=null}, target=Target{address='null', durable=0, 
 expiryPolicy=session-end, timeout=0, dynamic=false, 
 dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
 incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null, 
 offeredCapabilities=null, desiredCapabilities=null, properties=null}
 tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048, 
 nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0, 
 linkCredit=100, available=null, drain=false, echo=false, properties=null}
 tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
 tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
 tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER, 
 sndSettleMode=0, rcvSettleMode=0, source=null, 
 target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0, 
 expiryPolicy=session-end, timeout=0, dynamic=false, 
 dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
 incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
 offeredCapabilities=null, desiredCapabilities=null, properties=null}
 no link is produced on the second attach when you call: 
 protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);

--
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

[jira] [Resolved] (PROTON-153) [proton-j] Sender should throw an exception if send is called after the endpoint is locally closed.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-153.


   Resolution: Fixed
Fix Version/s: 0.3

 [proton-j] Sender should throw an exception if send is called after the 
 endpoint is locally closed.
 ---

 Key: PROTON-153
 URL: https://issues.apache.org/jira/browse/PROTON-153
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Fix For: 0.3

 Attachments: PROTON-153.patch




--
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

[jira] [Assigned] (PROTON-153) [proton-j] Sender should throw an exception if send is called after the endpoint is locally closed.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-153:
--

Assignee: Rob Godfrey

 [proton-j] Sender should throw an exception if send is called after the 
 endpoint is locally closed.
 ---

 Key: PROTON-153
 URL: https://issues.apache.org/jira/browse/PROTON-153
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Fix For: 0.3

 Attachments: PROTON-153.patch




--
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

[jira] [Resolved] (PROTON-155) [proton-j] Detach toString() does not include the handle field.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-155.


   Resolution: Fixed
Fix Version/s: 0.3

 [proton-j] Detach toString() does not include the handle field.
 ---

 Key: PROTON-155
 URL: https://issues.apache.org/jira/browse/PROTON-155
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Fix For: 0.3

 Attachments: PROTON-155.patch




--
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

[jira] [Assigned] (PROTON-155) [proton-j] Detach toString() does not include the handle field.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-155:
--

Assignee: Rob Godfrey

 [proton-j] Detach toString() does not include the handle field.
 ---

 Key: PROTON-155
 URL: https://issues.apache.org/jira/browse/PROTON-155
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Fix For: 0.3

 Attachments: PROTON-155.patch




--
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

[jira] [Created] (PROTON-150) [Proton-J] Surface necessary methods in interface to remove need to cast to Impl

[Rob Godfrey (JIRA)]

Rob Godfrey created PROTON-150:
--

 Summary: [Proton-J] Surface necessary methods in interface to 
remove need to cast to Impl
 Key: PROTON-150
 URL: https://issues.apache.org/jira/browse/PROTON-150
 Project: Qpid Proton
  Issue Type: Bug
Reporter: Rob Godfrey
Assignee: Rob Godfrey
 Fix For: 0.3




--
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

[jira] [Resolved] (PROTON-149) Remove if at TransportImpl.java line 866.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-149.


   Resolution: Fixed
Fix Version/s: 0.3

 Remove if at TransportImpl.java line 866.
 -

 Key: PROTON-149
 URL: https://issues.apache.org/jira/browse/PROTON-149
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Fix For: 0.3


 The frameBody should always be encoded so that the subsequent if can get an 
 accurate size of the remaining space in the overflow buffer that can be used 
 to hold a payload.

--
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

[jira] [Assigned] (PROTON-141) [proton-j] 256K Messages do not get transfered properly

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-141:
--

Assignee: Rob Godfrey

 [proton-j] 256K Messages do not get transfered properly
 ---

 Key: PROTON-141
 URL: https://issues.apache.org/jira/browse/PROTON-141
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Attachments: PROTON-141-final.patch




--
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

[jira] [Resolved] (PROTON-141) [proton-j] 256K Messages do not get transfered properly

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-141.


Resolution: Fixed

Committed the fix to TransportImpl and the Python test. Omitted the Java test 
as it seems to test only what the python test does but would only test the java 
impl and not the C impl.

 [proton-j] 256K Messages do not get transfered properly
 ---

 Key: PROTON-141
 URL: https://issues.apache.org/jira/browse/PROTON-141
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Attachments: PROTON-141-final.patch




--
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

[jira] [Resolved] (PROTON-146) Simplified CompositeWritableBuffer impl to avoid help buffer overflow exceptions.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-146.


   Resolution: Fixed
Fix Version/s: 0.3

applied patch

   Simplified CompositeWritableBuffer impl to avoid help buffer overflow 
 exceptions.
 --

 Key: PROTON-146
 URL: https://issues.apache.org/jira/browse/PROTON-146
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Fix For: 0.3

 Attachments: PROTON-146.patch




--
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

[jira] [Assigned] (PROTON-146) Simplified CompositeWritableBuffer impl to avoid help buffer overflow exceptions.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-146:
--

Assignee: Rob Godfrey

   Simplified CompositeWritableBuffer impl to avoid help buffer overflow 
 exceptions.
 --

 Key: PROTON-146
 URL: https://issues.apache.org/jira/browse/PROTON-146
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Fix For: 0.3

 Attachments: PROTON-146.patch




--
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

[jira] [Assigned] (PROTON-143) Trace the frame after the onPayloadTooLarge runnable is executed.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-143:
--

Assignee: Rob Godfrey

 Trace the frame after the onPayloadTooLarge runnable is executed.
 -

 Key: PROTON-143
 URL: https://issues.apache.org/jira/browse/PROTON-143
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Attachments: PROTON-143.patch




--
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

[jira] [Resolved] (PROTON-143) Trace the frame after the onPayloadTooLarge runnable is executed.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-143.


   Resolution: Fixed
Fix Version/s: 0.3

 Trace the frame after the onPayloadTooLarge runnable is executed.
 -

 Key: PROTON-143
 URL: https://issues.apache.org/jira/browse/PROTON-143
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
 Fix For: 0.3

 Attachments: PROTON-143.patch




--
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

[jira] [Commented] (PROTON-145) 256K Messages do not get transfered properly with a 64k pump size

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500431#comment-13500431
 ] 

Rob Godfrey commented on PROTON-145:


Simplified patch applied

 256K Messages do not get transfered properly with a 64k pump size
 -

 Key: PROTON-145
 URL: https://issues.apache.org/jira/browse/PROTON-145
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
 Attachments: PROTON-145-Fix.patch, PROTON-145-Simplified.patch, 
 PROTON-145-Test.patch




--
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

[jira] [Assigned] (PROTON-140) [Proton-j] Add contib, examples directories

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-140:
--

Assignee: Keith Wall

 [Proton-j] Add contib, examples directories
 ---

 Key: PROTON-140
 URL: https://issues.apache.org/jira/browse/PROTON-140
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Rob Godfrey
Assignee: Keith Wall

 Per IRC chat (and prior agreement at the F2F), we should create a contrib 
 directory under proton-j and move the current structure under a proton 
 directory
 (15:42:44) chirino: I think what needs to get done is: mkdir proton-j/proton; 
 mv proton-j/* proton-j/proton; mkdir proton-j/contrib
 (15:45:18) robjgodfrey: rschloming: any issues with the above?
 (15:46:32) rschloming: robjgodfrey: not at all, makes sense to me
 (15:46:57) rschloming: robjgodfrey: I should be able to update the release 
 script to accomodate that.
 (15:47:09) chirino: rschloming: you probably won't need to.
 (15:47:20) chirino: I'll be putting a pom.xml in the proton-j dir again.
 (15:47:36) rschloming: chirino: even better
 (15:48:17) rschloming: robjgodfrey: chirino: would you expect a java examples 
 directory to be parallel to those?
 (15:48:33) rschloming: robjgodfrey: chirino: e.g. proton-j/examples?
 (15:48:35) chirino: yeah that would make sense.

--
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

[jira] [Assigned] (PROTON-138) [proton-j] BufferOverflowException

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-138:
--

Assignee: Philip Harvey

 [proton-j] BufferOverflowException
 --

 Key: PROTON-138
 URL: https://issues.apache.org/jira/browse/PROTON-138
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Philip Harvey

 java.nio.BufferOverflowException
   at java.nio.Buffer.nextPutIndex(Buffer.java:493)
   at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:145)
   at 
 org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.put(WritableBuffer.java:63)
   at 
 org.apache.qpid.proton.codec.CompositeWritableBuffer.putInt(CompositeWritableBuffer.java:105)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:900)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.processClose(TransportImpl.java:847)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.transportOutput(TransportImpl.java:204)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.access$000(TransportImpl.java:42)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl$1.output(TransportImpl.java:106)
   at org.apache.qpid.proton.engine.impl.SaslImpl$1.output(SaslImpl.java:507)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.output(TransportImpl.java:165)

--
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

[jira] [Assigned] (PROTON-130) Sending pre-settled message results in the TransportSession._outgoingWindowSize going to 0, which stops further transfers.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-130:
--

Assignee: Rob Godfrey

 Sending pre-settled message results in the 
 TransportSession._outgoingWindowSize going to 0, which stops further 
 transfers.
 --

 Key: PROTON-130
 URL: https://issues.apache.org/jira/browse/PROTON-130
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey



--
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

[jira] [Assigned] (PROTON-84) Disposition sent in response to pre-settled transfer

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-84:
-

Assignee: Rob Godfrey

 Disposition sent in response to pre-settled transfer
 

 Key: PROTON-84
 URL: https://issues.apache.org/jira/browse/PROTON-84
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey
Priority: Minor
 Fix For: 0.3




--
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

[jira] [Created] (PROTON-132) Unsettled deliveries not being removed from transport session maps

[Rob Godfrey (JIRA)]

Rob Godfrey created PROTON-132:
--

 Summary: Unsettled deliveries not being removed from transport 
session maps
 Key: PROTON-132
 URL: https://issues.apache.org/jira/browse/PROTON-132
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Rob Godfrey
Assignee: Rob Godfrey
 Fix For: 0.3


Unsettled deliveries not being removed from transport session maps

--
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

[jira] [Resolved] (PROTON-132) Unsettled deliveries not being removed from transport session maps

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey resolved PROTON-132.


Resolution: Fixed

 Unsettled deliveries not being removed from transport session maps
 --

 Key: PROTON-132
 URL: https://issues.apache.org/jira/browse/PROTON-132
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Rob Godfrey
Assignee: Rob Godfrey
 Fix For: 0.3


 Unsettled deliveries not being removed from transport session maps

--
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

[jira] [Commented] (PROTON-115) Expose API to access link name.

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490561#comment-13490561
 ] 

Rob Godfrey commented on PROTON-115:


Added getName() to Link in proton-j

 Expose API to access link name.
 ---

 Key: PROTON-115
 URL: https://issues.apache.org/jira/browse/PROTON-115
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino



--
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

[jira] [Updated] (PROTON-115) Expose API to access link name.

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-115:
---

Fix Version/s: 0.3

 Expose API to access link name.
 ---

 Key: PROTON-115
 URL: https://issues.apache.org/jira/browse/PROTON-115
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, proton-j
Reporter: Hiram Chirino
 Fix For: 0.3




--
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

Re: [VOTE] 0.2 RC4

[Rob Godfrey]

[X] Ship it! (Release RC4 as 0.2)

Tested java and reviewed C change.

-- Rob

On 5 November 2012 13:19, Rafael Schloming r...@alum.mit.edu wrote:

 Posted here: http://people.apache.org/~rhs/qpid-proton-0.2rc4/

 [ ] Ship it! (Release RC4 as 0.2)
 [ ] No (We need another RC because...)

 The only difference between RC3 and RC4 for proton-c is a one line change
 in engine.c that ensures that pn_transport_output will not fail to produce
 output under particular conditions despite there being output to produce.
 There was also a public accessor added in proton-j. Both of these are very
 small and sufficiently isolated changes that they shouldn't impact any
 testing that has been done on RC3. I've attached the total diff in case
 anyone wants to check it out. I'm hoping we can still get enough votes to
 do a release tonight so please have a look and give it your +1 if it checks
 out.

 --Rafael

Re: RC5

[Rob Godfrey]

OK - proton-c built OK for me on Ubuntu 12.04 (32-bit) and Centos 6.3
(32 bit)... Tests all worked fine on the Ubuntu machine.  On CentOS I
got the following error:

proton_tests.messenger.MessengerTest.testSendBogus
...
start
  server timed out
proton_tests.messenger.MessengerTest.testSendBogus
...
fail
Error during teardown:  Traceback (most recent call last):
File ./proton-test, line 331, in run
  phase()
File /home/rob/qpid-proton-c-0.1/tests/proton_tests/messenger.py,
line 45, in teardown
  self.client.send()
File /home/rob/qpid-proton-c-0.1/bindings/python/proton.py, line
288, in send
  self._check(pn_messenger_send(self._mng))
File /home/rob/qpid-proton-c-0.1/bindings/python/proton.py, line
149, in _check
  raise exc([%s]: %s % (err, pn_messenger_error(self._mng)))
  Timeout: [-7]: unable to send to address: totally-bogus-address
(getaddrinfo: Name or service not known)

all other tests passed

-- Rob

On 25 October 2012 22:07, Rafael Schloming r...@alum.mit.edu wrote:
 Please have a look. This one includes ken's ssl fix in addition to
 everything that was in RC4:

 http://people.apache.org/~rhs/qpid-proton-0.1rc5/

Re: RC2

[Rob Godfrey]

As an aside, I have built successfully on Ubuntu 10.10 and 12.04.

-- Rob

On 24 October 2012 16:49, Rob Godfrey rob.j.godf...@gmail.com wrote:
 [rob@seelachs ~]$ cmake -version
 cmake version 2.6-patch 4


 On 24 October 2012 16:39, Ken Giusti kgiu...@redhat.com wrote:


 cmake version 2.6-patch 4

 -K

 - Original Message -
 I think this may be related to the cmake version. Can you guys run
 cmake
 -version and tell me what it reports?

 On Wed, Oct 24, 2012 at 10:17 AM, Rob Godfrey
 rob.j.godf...@gmail.comwrote:

  I get the same error on CentOS 6.3:
 
  [rob@seelachs build]$ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
  -- The C compiler identification is GNU
  -- Check for working C compiler: /usr/bin/gcc
  -- Check for working C compiler: /usr/bin/gcc -- works
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Found OpenSSL: /usr/lib/libssl.so
  -- Found PythonLibs: /usr/lib/python2.6/config/libpython2.6.so
  -- Found PythonInterp: /usr/bin/python2.6
  CMake Error at bindings/python/CMakeLists.txt:29 (install):
install DIRECTORY given unknown argument OPTIONAL.
 
 
  -- Could NOT find Doxygen  (missing:  DOXYGEN_EXECUTABLE)
  -- Configuring incomplete, errors occurred!
  [rob@seelachs build]$ more /etc/redhat-release
  CentOS release 6.3 (Final)
 
 
  On 24 October 2012 16:05, Ken Giusti kgiu...@redhat.com wrote:
   cmake fails on clean Centos5 machine:
  
   [kgiusti@centos5 build]$ cmake
  -DCMAKE_INSTALL_PREFIX=/home/kgiusti/proton/insta
   ll ..
   -- The C compiler identification is GNU
   -- Check for working C compiler: /usr/bin/gcc
   -- Check for working C compiler: /usr/bin/gcc -- works
   -- Detecting C compiler ABI info
   -- Detecting C compiler ABI info - done
   -- Found OpenSSL: /usr/lib64/libssl.so
   -- Found PythonLibs: /usr/lib64/python2.4/config/libpython2.4.a
   -- Found PythonInterp: /usr/bin/python2.4
   -- Found Doxygen: /usr/bin/doxygen
   CMake Error at docs/api/CMakeLists.txt:28 (install):
 install DIRECTORY given unknown argument OPTIONAL.
  
  
   -- Configuring incomplete, errors occurred!
   [kgiusti@centos5 build]$
  
  
   -K
  
   - Original Message -
   I've uploaded another release candidate here:
  
 http://people.apache.org/~rhs/qpid-proton-0.1rc2/
  
   The following fixes were made:
  
 1. the install step should now work without the documentation
 2. the README has a note about root privileges
 3. the tarball names/directory match
 4. added some missing type mappings to the python binding
 5. added the maven magic to update the pom version
 6. I believe rob fixed PROTON-85 for the java code
  
   --Rafael
  
 

Re: initial release candidate

[Rob Godfrey]

My (64-bit) Ubuntu 12.04 works fine...

On Ubuntu 10.04 I'm seeing SSL errors... presumably these are related
to the age of the ssl library and the algorithms it supports...

proton_tests.ssl.SslTest.test_client_authentication
.SSL_CTX_use_PrivateKey_file(
/home/rob/qpid-proton-c-0.1/tests/proton_tests/ssl_db/server-private-key.pem
) failed
error:06074079:digital envelope routines:EVP_PBE_CipherInit:unknown
pbe algorithm
error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error
error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error
error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib
error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib
 fail
Error during test:  Traceback (most recent call last):
File ./proton-test, line 331, in run
  phase()
File /home/rob/qpid-proton-c-0.1/tests/proton_tests/ssl.py, line
130, in test_client_authentication
  server-password)
File /home/rob/qpid-proton-c-0.1/bindings/python/proton.py, line
2111, in set_credentials
  password) )
File /home/rob/qpid-proton-c-0.1/bindings/python/proton.py, line
2096, in _check
  raise exc(SSL failure.)
  SSLException: SSL failure.

-- Rob

On 24 October 2012 18:05, Ken Giusti kgiu...@redhat.com wrote:
 Ubuntu 12.04-1 LTS, fully patched and up to date:

 1) had to install the following packages - similar to the README, but ubuntu 
 specific:

 sudo apt-get install cmake swig libssl-dev python-dev ruby ruby-dev 
 python-epydoc uuid-dev

 [note: cmake is version 2.8.7, so I didn't get that OPTIONAL issue]

 2) make and install went well!

 3) example/send.py and recv.py worked - need to try with SSL next..

 4) am seeing a failure in the python-tests:

 proton_tests.codec.DataTest.testDecimal128 
 
  pass
 proton_tests.codec.DataTest.testDecimal32 
 .
  pass
 proton_tests.codec.DataTest.testDecimal64 
 .
  fail
 Error during test:  Traceback (most recent call last):
 File ./proton-test, line 331, in run
   phase()
 File 
 /home/kgiusti/proton-rc/qpid-proton-c-0.1/tests/proton_tests/codec.py, line 
 246, in testDecimal64
   self._test(decimal64, 0, 1, 2, 3, 4, 2**60)
 File 
 /home/kgiusti/proton-rc/qpid-proton-c-0.1/tests/proton_tests/codec.py, line 
 183, in _test
   putter(v)
 File 
 /home/kgiusti/proton-rc/install/lib/python2.7/dist-packages/proton.py, line 
 1134, in put_decimal64
   self._check(pn_data_put_decimal64(self._data, d))
   TypeError: in method 'pn_data_put_decimal64', argument 2 of type 
 'pn_decimal64_t'
 proton_tests.codec.DataTest.testDescribedEmptyArray 
 ...
  pass

 This happens to be on a 32-bit VM - I'll look into it.

 -K

 - Original Message -
 Hi Everyone,

 I've posted an initial release candidate here:

   http://people.apache.org/~rhs/qpid-proton-0.1/

 Please keep in mind there hasn't been a wide variety of install
 testing so
 go ahead and try on as many different OS distro/versions as you can
 find
 and let me know if/when things break.

 --Rafael

Re: RC3

[Rob Godfrey]

I got the following failure on proton-c from this release on 32-bit
Ubuntu 12.04:

proton_tests.codec.DataTest.testDecimal64

fail
Error during test:  Traceback (most recent call last):
File ./proton-test, line 331, in run
  phase()
File /home/rob/qpid-proton-c-0.1/tests/proton_tests/codec.py,
line 246, in testDecimal64
  self._test(decimal64, 0, 1, 2, 3, 4, 2**60)
File /home/rob/qpid-proton-c-0.1/tests/proton_tests/codec.py,
line 183, in _test
  putter(v)
File /home/rob/qpid-proton-c-0.1/bindings/python/proton.py, line
1134, in put_decimal64
  self._check(pn_data_put_decimal64(self._data, d))
  TypeError: in method 'pn_data_put_decimal64', argument 2 of type
'pn_decimal64_t'



On 24 October 2012 21:29, Rafael Schloming r...@alum.mit.edu wrote:
 I've put up an RC3 here:

   http://people.apache.org/~rhs/qpid-proton-0.1rc3/

 The following are the changes from RC2:

   - added README and LICENSE for proton-j
   - updated the proton-c README
   - fixed cmake build to not use the OPTIONAL thing for older versions
   - fixed detection of LIB_SUFFIX (i.e. we won't install into lib64 on 32
 bit systems anymore)

 --Rafael

[jira] [Commented] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13473305#comment-13473305
 ] 

Rob Godfrey commented on PROTON-65:
---

I agree that right now we haven't identified the right place. One of the things 
that I think needs to be urgently addressed is defining the scope of what is 
proton, how we structure to potentially accept intergations of proton, and 
where we place other code that utilises proton but is non-core.

I know some people are supposed to be writing a constitution for Proton at 
the moment... hopefully over the next week or so we can get agreement on this 
and find an agreed home for code such ass this.

 Provide a AMQP 1.0 Message to JMS Message mapping logic/module
 --

 Key: PROTON-65
 URL: https://issues.apache.org/jira/browse/PROTON-65
 Project: Qpid Proton
  Issue Type: New Feature
  Components: proton-j
Reporter: Hiram Chirino
 Attachments: PROTON-65.patch


 Having a easy/consistent way to transform a JMS message to an AMQP message 
 and back would be super handy.  Having that logic live in proton would help 
 make that mapping more standardized as different client and sever 
 implementations can just re-use the logic.

--
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

[jira] [Commented] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472673#comment-13472673
 ] 

Rob Godfrey commented on PROTON-65:
---

I think it's more of a module/scoping question.

I completely agree that we should have a JMS - Message adapter, hosted within 
Apache Qpid.  The question is really about the scope of Proton as a 
sub-component of Qpid I think.  One thing that a lot of us a very keen to 
ensure is that Proton is seen as a whole not as a whole load of independent 
language specific modules (since treating each language independently has 
caused us many issues in the past).


 Provide a AMQP 1.0 Message to JMS Message mapping logic/module
 --

 Key: PROTON-65
 URL: https://issues.apache.org/jira/browse/PROTON-65
 Project: Qpid Proton
  Issue Type: New Feature
  Components: proton-j
Reporter: Hiram Chirino
 Attachments: PROTON-65.patch


 Having a easy/consistent way to transform a JMS message to an AMQP message 
 and back would be super handy.  Having that logic live in proton would help 
 make that mapping more standardized as different client and sever 
 implementations can just re-use the logic.

--
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

[jira] [Updated] (PROTON-62) Proton(-j) does not support attaching to the transaction controller

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-62:
--

Summary: Proton(-j) does not support attaching to the transaction 
controller  (was: ClassCastException when processing an Attach frame)

 Proton(-j) does not support attaching to the transaction controller
 ---

 Key: PROTON-62
 URL: https://issues.apache.org/jira/browse/PROTON-62
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino

 Got at:
 Caused by: java.lang.ClassCastException: 
 org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to 
 org.apache.qpid.proton.type.messaging.Target
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59)
   at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090)
   at 
 org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156)
   at 
 org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120)
   ... 5 more
 and I think the frame being processed was the following (hex):
 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 
 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 
 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 
 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 
 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 
 73 73 6e 40 40 43 

--
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

[jira] [Updated] (PROTON-62) Proton(-j) does not support attaching to the transaction coordinator

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated PROTON-62:
--

Summary: Proton(-j) does not support attaching to the transaction 
coordinator  (was: Proton(-j) does not support attaching to the transaction 
controller)

 Proton(-j) does not support attaching to the transaction coordinator
 

 Key: PROTON-62
 URL: https://issues.apache.org/jira/browse/PROTON-62
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino

 Got at:
 Caused by: java.lang.ClassCastException: 
 org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to 
 org.apache.qpid.proton.type.messaging.Target
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59)
   at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090)
   at 
 org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156)
   at 
 org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120)
   ... 5 more
 and I think the frame being processed was the following (hex):
 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 
 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 
 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 
 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 
 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 
 73 73 6e 40 40 43 

--
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

[jira] [Assigned] (PROTON-55) NullPointerException when a Flow is received /w a null delivery count

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned PROTON-55:
-

Assignee: Rob Godfrey

 NullPointerException when a Flow is received /w a null delivery count
 -

 Key: PROTON-55
 URL: https://issues.apache.org/jira/browse/PROTON-55
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Reporter: Hiram Chirino
Assignee: Rob Godfrey

 Caused by: java.lang.NullPointerException
   at 
 org.apache.qpid.proton.type.UnsignedInteger.add(UnsignedInteger.java:124)
   at 
 org.apache.qpid.proton.engine.impl.TransportSender.handleFlow(TransportSender.java:45)
   at 
 org.apache.qpid.proton.engine.impl.TransportSession.handleFlow(TransportSession.java:287)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleFlow(TransportImpl.java:991)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.handleFlow(TransportImpl.java:59)
   at org.apache.qpid.proton.type.transport.Flow.invoke(Flow.java:318)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1081)
   at 
 org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409)
   at 
 org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156)

--
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