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 <tabish...@gmail.com> 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 <robbie.gemm...@gmail.com
> >
> > 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 <
> acogolueg...@gmail.com>
> >> 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: users-unsubscr...@qpid.apache.org
> >> For additional commands, e-mail: users-h...@qpid.apache.org
> >>
> >>
>
> --
> Tim Bish
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Reply via email to