AMQP 1.0 transport about sdk-java HOT 8 CLOSED

I prefer the 1 as first pass, we can always generalize with the option 2 later

from sdk-java.

@slinkydeveloper I want to work on this issue. can I give it a go?

from sdk-java.

Sure, go ahead. Which amqp client are you planning to use? Do you want to use apache qpid jproton?

from sdk-java.

I am planning to use the vertx-proton library to integrate amqp 1.0 with vertx. This library is a wrapper around qpid proton-j

<dependency>
    <groupId>io.vertx</groupId>
    <artifactId>vertx-proton</artifactId>
    <version>${vertx.version}</version>
</dependency>

I see that different components in the project uses a different vertx version. Is there a reason for this?

How about defining a maven property for the vertx version (i.e vertx.version) in the parent POM and have all modules use the version defined in the parent? This way, the new amqp module will not have to redefine its own vertx version

from sdk-java.

IMO we should integrate directly with jproton more than the vertx wrapper, because it might be useful for folks that needs amqp but doesn't want to use vertx.

I see that different components in the project uses a different vertx version. Is there a reason for this?

Which components? It's fine if the vertx we use in jaxrs integration tests doesn't match the one in vert.x integration module

from sdk-java.

IMO we should integrate directly with jproton more than the vertx wrapper, because it might be useful for folks that needs amqp but doesn't want to use vertx

ok 👍

Which components?

http/vertx uses 4.0.0.Beta1 while http/restful-ws uses 3.9.0

from sdk-java.

http/vertx uses 4.0.0.Beta1 while http/restful-ws uses 3.9.0

No issue then

from sdk-java.

@slinkydeveloper If i understand correctly, the amqp protocol binding spec does not mandate the AMQP section to store CE extensions.

CloudEvents extensions that define their own attributes MAY define a secondary mapping to AMQP properties for those attributes, also in different message sections, especially if specific attributes or their names need to align with AMQP features or with other specifications that have explicit AMQP header bindings

So the mapping can go either to the properties section of the message or to a different section chosen by the user. I am thinking of implementing this as follows:

1. Map all extensions to the application-properties section of the message. In this case, all attributes and extensions maps to the same section of the message. I think this is what the sdk-go impl. is doing
2. provide a callback that allows the user to consume all extensions. This will enable the user to determine which section of the message to store the extensions.

WDYT?

from sdk-java.