Bug in pattern matching for registration?

#1

Two registrations:

“get.flights…” with wildcard matching

“get.flight” with prefix matching

A call to “get.flights.chicago.boston” matches the “get.flight” registration resulting in that RPC being called

This should not be the case, correct?

I change the second registration to:

“get.flight.” with wildcard matching

Now a call to get.flights.chicago.boston matches the “get.flights…” registration as intended and expected

Shouldn’t prefix matching require a “.” in the RPC call at the point where the prefix ends? Or should “get.flightABCDE” also match “get.flight” with prefix matching?

Thanks,
Steve

0 Likes

#2

Hi Steve,

this is expected behavior. Registrations are matched in a hierarchy: exact, prefix, wildcard. In your example “get.flight” with “prefix” matching takes precedence over any wildcard registration (see http://crossbar.io/docs/Pattern-Based-Registrations/).

Regards,

Alex

···

Am Dienstag, 26. April 2016 00:48:55 UTC+2 schrieb Steve Ditlinger:

Two registrations:

“get.flights…” with wildcard matching

“get.flight” with prefix matching

A call to “get.flights.chicago.boston” matches the “get.flight” registration resulting in that RPC being called

This should not be the case, correct?

I change the second registration to:

“get.flight.” with wildcard matching

Now a call to get.flights.chicago.boston matches the “get.flights…” registration as intended and expected

Shouldn’t prefix matching require a “.” in the RPC call at the point where the prefix ends? Or should “get.flightABCDE” also match “get.flight” with prefix matching?

Thanks,
Steve

0 Likes

#3

Two registrations:

“get.flights…” with wildcard matching

“get.flight” with prefix matching

A call to “get.flights.chicago.boston” matches the “get.flight” registration resulting in that RPC being called

This should not be the case, correct?

I change the second registration to:

“get.flight.” with wildcard matching

Now a call to get.flights.chicago.boston matches the “get.flights…” registration as intended and expected

Shouldn’t prefix matching require a “.” in the RPC call at the point where the prefix ends? Or should “get.flightABCDE” also match “get.flight” with prefix matching?

Matching method hierarchy aside, I must admit that I, like Steve here, thought that the prefix had to cover entire components of the URI for it to be considered a prefix match at all.

Elvis

···

Den 26 apr 2016 12:48 fm skrev “Steve Ditlinger” sditl...@gmail.com:

Thanks,

Steve

You received this message because you are subscribed to the Google Groups “Crossbar” group.

To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+...@googlegroups.com.

To post to this group, send email to cross...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/af2f1a30-78f4-4ffb-ae96-5d8f6e4cd1db%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#4

I guess I was confused by this page http://crossbar.io/docs/Pattern-Based-Registrations/

where it is explained that, with prefix matching, com.myapp.managewill match
com.myapp.manage.add,
com.myapp.manage.store,
com.myapp.manage.retrieve, and
com.myapp.manage.ship

``

Left unsaid is that it will also match com.myapp.manager and com.myapp.manages

``

This makes sense, as it creates a greater distinction between prefix and wildcard matching, i.e.

``

"com.myapp.manage" registration with prefix is different from "com.myapp.manage." registration with wildcard. The page at the link above should be modified to emphasize that point.

···

On Friday, April 29, 2016 at 8:55:57 AM UTC-7, Elvis Stansvik wrote:

Den 26 apr 2016 12:48 fm skrev “Steve Ditlinger” sdit...@gmail.com:

Two registrations:

“get.flights…” with wildcard matching

“get.flight” with prefix matching

A call to “get.flights.chicago.boston” matches the “get.flight” registration resulting in that RPC being called

This should not be the case, correct?

I change the second registration to:

“get.flight.” with wildcard matching

Now a call to get.flights.chicago.boston matches the “get.flights…” registration as intended and expected

Shouldn’t prefix matching require a “.” in the RPC call at the point where the prefix ends? Or should “get.flightABCDE” also match “get.flight” with prefix matching?

Matching method hierarchy aside, I must admit that I, like Steve here, thought that the prefix had to cover entire components of the URI for it to be considered a prefix match at all.

Elvis

Thanks,

Steve

You received this message because you are subscribed to the Google Groups “Crossbar” group.

To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+...@googlegroups.com.

To post to this group, send email to cros...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/af2f1a30-78f4-4ffb-ae96-5d8f6e4cd1db%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

0 Likes