MassTransit 8 upgrade: usage of message encryption - masstransit

Upgrading from MassTransit 7.3 to 8 encountered the following problem:
In version 7.3.1.0 the MassTransit package has means to serialize messages with encryption:
void UseEncryption(this IBusFactoryConfigurator configurator, ISecureKeyProvider keyProvider)
However in 8.0.7 this functionality has been moved to the package MassTransit.Newtonsoft.
Since starting from version 8 MassTransit uses by default System.Text.Json we would like to use that serializer. But I haven't found a way to use message encryption other than using "MassTransit.Newtonsoft". Is message encryption in "MassTransit.Newtonsoft" is supposed to be used only with "Newtonsoft" serialization? Is there any way to use message encryption with the default System.Text.Json serialization?
We are using Azure Service Bus as a broker.

The encryption layer for MassTransit v8 serialization has not be written yet. The only available option is the legacy Newtonsoft one you were already using.

Related

Does the Azure ServiceBus JMS library support managed identities?

I am using the library com.azure.spring:azure-spring-boot-starter-servicebus-jms:3.14.0 and I am trying to avoid the usage of a connection string by using a managed identity, but I wasn't able to find anything related on the internet. I also examined the library and I haven't seen any support for TokenCredential what Microsoft usually supports.
So the question is whether it is currently supported by the library or not?
In short, no.
The JMS API itself has no support for a "managed identity" or any kind of TokenCredetial object.
The JMS client implementation used here is Qpid JMS and it also has no support for a "managed identity" or any kind of TokenCredetial object.

Use quorum queues with pre 3.0.0 String Cloud Stream

We are using Spring Cloud Steam with RabbitMQ binder.
I'm currently in the Process of setting up a RabbitMQ Cluster and want to use quorum queues. The options to set the queue type must be sent with the creation of the queue. In version 3.0.0 of Spring Cloud Stream, the option is added, but we are on an old version of String Boot and String Cloud Stream and don't want to update, because our live release will be in the next few weeks.
I've looked up the PR link. but the options are all private and I don't see any listeners or interceptors.
Is there any way to inject additional arguments into the queue creation call?
I would recommend upgrading to a newer version.
The only option with older versions is to provision and bind the queue manually and disable automatic provisioning of the queues as discussed in the binder reference.
If you have an existing exchange/queue that you wish to use, you can completely disable automatic provisioning as follows, assuming the exchange is named myExchange and the queue is named myQueue:
spring.cloud.stream.binding.<binding name>.destination=myExhange
spring.cloud.stream.binding.<binding name>.group=myQueue
spring.cloud.stream.rabbit.bindings.<binding name>.consumer.bindQueue=false
spring.cloud.stream.rabbit.bindings.<binding name>.consumer.declareExchange=false
spring.cloud.stream.rabbit.bindings.<binding name>.consumer.queueNameGroupOnly=true

Can JMS Messaging be performed on quarkus using Apache camel routes?

Sorry for a naive question , just starting off with quarkus here. Since i read that quarkus already supports camel , is it possible to create a JMS route to send a message to a JMS queue ?
I also have some legacy services which use Database bean map handlers (apache commons db). If i include them as a part of quarkus ,can these still be deployed on GraalVM ?
The list of the component currently fully supported by camel-quarkus is listed here: https://github.com/apache/camel-quarkus/tree/master/extensions
Other components not listed here are working out of the box in JVM mode but some work may be required ot make them working as native image

Will ActiveMQ be supported in Spring XD as transport in future?

We are using ActiveMQ as our standard messaging platform. XD already supports ActiveMQ as JMS source. Messaging platform as transport helps handle the sink failures by putting the payload in the ERROR queue named after the transport. If it were Redis, the payload goes into a LIST. Queue is better way to process the failed messages using a batch job. Wondering if ActiveMQ will be supported as a transport in future.
I created https://jira.spring.io/browse/XD-1928 and put it on the roadmap for a 1.1 M1 release which will be later in the year. Rabbit as the broker supports the same error handling semantics you mention.
https://github.com/spring-projects/spring-xd/wiki/XD-Distributed-Runtime#error-handling-message-delivery-failures
has more info on error handling for both Redis and Rabbit.
Rabbit is the preferred message bus to use ATM, we also support redis since it is a way to validate the messagebus abstraction and it is already 'there' since we use it to store analytics.
Thanks for the feedback.
Cheers,
Mark

Does Apache ActiveMQ support Google protobuf as a transport protocol?

I'm developing a messaging system and I used JBoss Netty + Google protobuf for the POC. protobuf was chosen for its swiftness of serialization/deserialization, relatively low traffic cost and availability in several languages.
Still, when it comes to production under heavy load a self-coded server application can never be as good as well-established and tested frameworks.
The problem is, I can't find such a framework that would allow me using protobuf as a transport protocol. Apache ActiveMQ and ActiveBlaze are the closest things I could find but the documentation is nearly absent.
I stumbled upon something that is ActiveMQ protobuf implementation but there is no reminding of it in official ActiveMQ documentation (its not among the supported protocols).
So my question is whether AMQ supports protobuf and if it does how it can be integrated?
No, ActiveMQ uses its own OpenWire protocol or the Stomp protocol. The protobuf bits are used for the underlying KahaDB Message store not the wire level portion. You can store your protobuf data in a BytesMessage and transmit it that way to allow you to marshal and unmarshal the data on either end.

Resources