Re: Diverting messages to non existing destination

Yes, that is what I am testing now. In the divert, before routing the message copy, a new RoutingContextImpl is created for it. To this new RoutingContextImpl, the original transaction is picked up from the original context, but currently not the ServerSession. So I am basically trying this in

Re: Diverting messages to non existing destination

can't you use the RoutingContext for anything like that? I thought we had already had some stuff on it. On Wed, Mar 20, 2024 at 9:41 AM Domenico Francesco Bruscino wrote: > > I think we should always reuse the server session of the original context > because it will be used to execute security

Re: Diverting messages to non existing destination

I think we should always reuse the server session of the original context because it will be used to execute security checks before creating addresses and queues. On Wed, 20 Mar 2024 at 09:35, Anton Roskvist wrote: > Thanks for your feedback, and yes, I also agree that adding a boolean to > the

Re: Diverting messages to non existing destination

Thanks for your feedback, and yes, I also agree that adding a boolean to the divert-configis a good approach. There is one other thing about the implementation I'm thinking about though... after the divert sends the message copy over to postOffice it passes 2 additional auto-create-checks

Re: Diverting messages to non existing destination

@Clebert Suconic I mean that I like your proposal to have the property in the divert On Tue, 19 Mar 2024 at 18:14, Clebert Suconic wrote: > @dom Anton had added an address setting. > > Perhaps we could have the property in the divert instead ? > > On Tue, Mar 19, 2024 at 4:01 AM Domenico

Re: Diverting messages to non existing destination

@dom Anton had added an address setting. Perhaps we could have the property in the divert instead ? On Tue, Mar 19, 2024 at 4:01 AM Domenico Francesco Bruscino < bruscin...@gmail.com> wrote: > +1 for the new divert setting proposed by Clebert > > On Mon, 18 Mar 2024 at 18:15, Clebert Suconic >

Re: Diverting messages to non existing destination

+1 for the new divert setting proposed by Clebert On Mon, 18 Mar 2024 at 18:15, Clebert Suconic wrote: > I think we should do 1. > at that point we look for the address-settings on auto-create, if > auto-create is on, we should then create it. > > > However, to unlock the situation for those

Re: Diverting messages to non existing destination

I think we should do 1. at that point we look for the address-settings on auto-create, if auto-create is on, we should then create it. However, to unlock the situation for those who may disagree.. Can't we add a Setting to the Divert itself. we could have a boolean on the Divert deployment on

Re: Diverting messages to non existing destination

Hi, Sorry, I was not clear with my phrasing there. While trying out a solution where a diverts transformer changes message destination, I discovered this was an issue (for my use-case). So the change itself really is about handling the case where a "computed" destination is missing (as well

Re: Diverting messages to non existing destination

Hi Anton, a divert could use a transformer to change a message destination. What are you using in your feature to change a message destination? Regards, Domenico On Mon, 18 Mar 2024 at 10:31, Roskvist Anton wrote: > Hi all, > > I'm working on a feature for Artemis where the use-case is the

Diverting messages to non existing destination

Hi all, I'm working on a feature for Artemis where the use-case is the ability to compute or alter a messages destination through a divert. In doing so there is a possibility that the new destination might not exist on the broker. There is some debate around how to handle this. The current