On Jul 3, 2008, at 9:47 AM, Paul Sandoz wrote:
> 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.
>
We could consider one level of prioritization without adding an
explicit priority attribute: sort paths with explicit regexs ahead of
those using the default. With the workaround Paul mentioned I think
this would be sufficient.
Marc.
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.