There wasnt, but I have set up a nightly deploy job and run it, so it should be in the snapshots repo now.
On Tue, 27 Feb 2024 at 09:18, Arnaud Cogoluègnes <[email protected]> wrote: > > Great! Thanks for the follow-up. I built the project locally and the link > pairing works now. > > Are snapshots published somewhere? I can't find them on the Apache Maven > snapshot repository [1]. > > Thanks. > > [1] https://repository.apache.org/content/groups/snapshots/org/apache/qpid/ > > > > On Mon, Feb 26, 2024 at 8:53 PM Timothy Bish <[email protected]> wrote: > > > On 2/26/24 12:00, Arnaud Cogoluègnes wrote: > > > Thanks for the reply. > > > > > > My understanding is that it does not matter much, right? Would it be OK > > to > > > change this line [1] and pass in the address variable instead of the > > > senderId? > > > > > > I tried locally: it does not break the test suite and fixes the link > > > pairing issue. > > > > > > This is trivial, I can submit a PR. > > > > I have resolved this in the following issue as it makes sense they > > sender and receiver should at least be consistent > > > > https://issues.apache.org/jira/browse/PROTON-2796 > > > > > > > Thanks. > > > > > > [1] > > > > > https://github.com/apache/qpid-protonj2/blob/b5ac05d77ce697d0290643709bb2f5d718a1a673/protonj2-client/src/main/java/org/apache/qpid/protonj2/client/impl/ClientSenderBuilder.java#L120 > > > > > > On Mon, Feb 26, 2024 at 5:52 PM Robbie Gemmell <[email protected] > > > > > > wrote: > > > > > >> I would guess just because it was inspired by earlier code that did > > >> much the same long before the link-pair extension ever existed, and it > > >> just hasnt been used by anyone wanting to do link pairing (which isnt > > >> that widely used; referenced by some other extension specs that..). > > >> > > >> The protocol spec won't cover this as it is essentially an arbitrary > > >> choice in its eyes and indeed for most use cases (unless, say, you try > > >> to do link-pairs). What it definitely does say is that you dont need > > >> to populate the field at all for the typical 'simple client end' > > >> terminus of a link (from memory there is also a c&p error in there > > >> when it covers this, in terms of its references to source/target). > > >> > > >> I expect the existing options don't let you set the 'local' > > >> source/target address since the other side is usually the important > > >> one and set implicitly most of the time, and also more so just as the > > >> options classes are used in common for sender/receiver creation and so > > >> allowing that would mean one of them can easily clash with other > > >> configuration and perhaps need additional validation added, e.g > > >> clashing with whats set implicitly, or e.g with a request for dynamic > > >> that forbids setting it. > > >> > > >> On Mon, 26 Feb 2024 at 14:58, Arnaud Cogoluègnes < > > [email protected]> > > >> wrote: > > >>> Hi. > > >>> > > >>> Any reason for using the senderId instead of the address for the source > > >>> address of a sender (e.g. [1])? > > >>> > > >>> This does not align with what's done for receivers where the address is > > >>> used for both the source and target address and I don't see anything > > >>> specific in the spec that justifies this choice. > > >>> > > >>> The source address then ends up being something > > >>> like ID:bbd3c071-efd4-4ee4-be3d-870ee90b7d7e:2:1:1:1. > > >>> > > >>> This makes it impossible to implement Link Pairing [2], as the 2 > > >> following > > >>> conditions cannot be met: > > >>> * The source address for L1 is identical to the target address for > > L2 > > >>> * The source address for L2 is identical to the target address for > > L1 > > >>> > > >>> Would it be possible to set the target/source addresses from the client > > >> API? > > >>> Thanks. > > >>> > > >>> [1] > > >>> > > >> > > https://github.com/apache/qpid-protonj2/blob/b5ac05d77ce697d0290643709bb2f5d718a1a673/protonj2-client/src/main/java/org/apache/qpid/protonj2/client/impl/ClientSenderBuilder.java#L120 > > >>> [2] https://docs.oasis-open.org/amqp/linkpair/v1.0/linkpair-v1.0.html > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> > > > > -- > > Tim Bish > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
