>
> On Tue, 8 Dec 2020 at 22:21, Michael Walser <
[hidden email]> wrote:
> >
> > Hello,
> >
> > I'm attempting to use Qpid JMS to connect to an AMQP 1.0 server (namely
> > Azure Event Hubs). To be able to start consuming messages at a certain
> > offset I have to set a message filter.
> >
> > The filters reads like this:
> > amqp.annotation.x-opt-offset > '100'
> >
> > When setting the filter using
> > session.createConsumer(
> > destination,
> > "amqp.annotation.x-opt-offset > '100'"
> > )
> > an InvalidSelectorException gets thrown.
> >
> > This is due to the Qpid library checking [1] the filter against a
> > grammar defined in SelectorParserImpl.jj [2].
> >
> > It appears like there is no way around this validation.
>
> Not at present. This is verifying the JMS selector syntax, giving
> behaviours needed/verified by JMS, with e.g. the above selector
> example being invalid/unexpected in a couple ways in JMS terms and
> thus causing an exception as seen.
>
> That said, Qpid JMS and at least the Qpid brokers have long supported
> (along with ActiveMQ Artemis more recently) an escape of "quoting" the
> contents of the 'property name' variable for bypassing some of the
> restrictions and allowing some of these additional behaviours, e.g. a
> quoted variable in a selector string:
> "\"my.quoted-var\"='some-value'"
>
> That likely won't help if the server doesn't support it however, I
> dont know whether it does in this case.
>
> > I spent the better part of this afternoon trying to find a syntax that
> > is accepted by both Qpid and the Azure Event Hub.
> >
> > Other people facing the same problem are resorting to modifying the Qpid
> > source code [3].
> >
> >
> > I think it would be enormously helpful if Qpid JMS would support setting
> > a custom JMS_SELECTOR_SYMBOL and provide an option to disable the
> > selector validation.
>
> I think adding the option to disable the selector validation is
> reasonable, given we do provide option for disabling related property
> name validations. Adding one for changing the protocol filter map key,
> not so much though.
>
> It simply shouldn't be necessary to change the map key since using a
> particular map key is not part of the filters semantic, the server
> shouldnt especially care what is used, and so I dont think it should
> be encouraged or warrants adding+maintaining an option for this.
> Especially with the filter behaviour originating here and having been
> around as long as it has now been. The key in use has been so since
> the protocol filter in question was originally created and used here
> at Qpid in an earlier [prototype] AMQP 1.0 JMS client over 8 years
> ago. I also believe at least Azure ServiceBus should already work with
> the filter map key the client currently uses, given Microsoft actually
> now uses Qpid JMS in their JMS offering.
>
> The client code changes mentioned use the filters symbolic descriptor
> as the map key, which isn't actually the intent of the value but
> rather that it can be used as part of the filter construction, which
> the change does then also go on to do, instead of the equivalent
> numeric descriptor code that the existing client impl is already
> using. I would be interested to know if either of those was actually
> necessary (as it certainly shouldn't be), i.e it was tried otherwise
> or just immediately done like shown because it was mentioned on the
> referenced page.
>
> Disabling the client-side validation to allow an 'invalid' (for JMS)
> selector string through should be the only meaningful client change
> 'needed' (assuming the mentioned quoting-escape isn't already viable
> at the server, in which case no change would really be required).
> Anything else really represents an issue with the servers behaviour
> (i.e requiring a particular filter key, or not supporting using the
> filters numeric descriptor) that can/should be rectified there.
>
>
filter. You can see how you get on with that:
Locked
