Hi Stephan,
I wondered if this might arise :-)
There is a very simple workaround for your example: include some literal
characters in the same or another path segment of one or both @Path
declarations.
My inclination is to say when one uses regexes be more careful. The
runtime can report ambiguity and suggest how it might be resolved.
Paul.
Stephan Koops wrote:
> Hi,
>
> if we allow regular expressions in @Path, than it seems useful to me to
> allow @Path("{number:[0-9]+}") on one resource method and
> @Path("{varname}") on another, where the second should match all values,
> that are not positive integers. Here it is useful to define, that the
> resource method or sub res locator with the first annotation is to
> prefer for the latter.
>
> Because I have no way in mind to calculate these preferences from the
> reg exp metadata it seems useful to me to define a new attribute in
> @Path to give preferences by hand, or use a new annotation for it, which
> also works if no @Path is given on a non-sub resource method. Another
> possibility for the last is @Path(value="", pref=1), which must be
> defined as non-sub resource method, also if it contains a @Path
> annotation. The type of pref could be a float for example. This allows
> it to move a preference between other preferences, also if the
> difference is only 1.
> This option leave simple things simple and allow complex things.
>
> best regards
> Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109