Hi folks,
Really following on from what I wrote about the default matching
algorithm and how it handles a mixture of URIs and URI-templates in an
application, it has raised an issue that I can't yet think of a solution
for.
We have a scheme for allowing endpoints to override the URI matching
algorithm. The
public boolean matchesURI(String path, URI requestUri, Map<String,
String> templateExpansion)
method on the ServerEndpointConfig.Configurator. Unfortunately, I can't
think of a way to make this work correctly in all situations without
some changes and/or further specification. Here's why:-
We know that the default match (i.e. if no configurators are provided)
gives us an unambiguous answer as to which endpoint matches an incoming
URI, even in case like this:-
EndpointA: /hello
EndpointB: /{greeting}
where two endpoint paths potentially match on the incoming URI /hello
(see previous email on that).
But as soon as one or more endpoints provide a configurator which
overrides matchesURI, then the implementation has to answer a few
questions:-
1) Which configurator do I call first ?
2) What if more than one configurator declares a match ?
3) What if the default match algorithm also yields a match on an
endpoint. Is that more or less important ?
There isn't enough information in the application (as currently
specified) to answer any of these questions, so the answers are going to
be implementation dependent. i.e. your application might have different
endpoints being called per incoming URI depending on which
implementation you are running on.
The options I can think of to fix this are:-
1) Remove matchesUri from the ServerEndpointConfig.Configurator (rather
draconian, but it would remove all the ambiguity)
2) Define a deployment order on the endpoints (all deployment methods
change from Set to List) and define a how the match precedence works in
relation to the endpoint ordering, e.g.
call the developer provided endpoint configurators first in deployment
order, first configurator to give a match wins. if no match:-
use the default algorithm to determine the best match.
(I'm not sure this works yet, I'd be grateful if someone could check it
would in parallel with me)
Can anyone think of a better option then these that does not require
creating new APIs or functions ?
Thanks,
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation