incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CLEREZZA-570) triaxrs/RootResourceExecutorImpl could (should) do better pattern matching on methods
Date Mon, 20 Jun 2011 15:20:47 GMT

    [ https://issues.apache.org/jira/browse/CLEREZZA-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052008#comment-13052008
] 

Reto Bachmann-Gmür commented on CLEREZZA-570:
---------------------------------------------

in JSR 311 I read: "A request is matched to the corresponding resource method or sub-resource
method by comparing the nor-
malized request URI (see section 3.7.1), the media type of any request entity, and the requested
response
entity format to the metadata annotations on the resource classes and their methods."

As I understand JSR 311 there is no guarantee of a deterministic method selection. I suggest
to discuss this on the jsr 311 mailing list and see if the standard should be extended.

> triaxrs/RootResourceExecutorImpl could (should) do better pattern matching on methods
> -------------------------------------------------------------------------------------
>
>                 Key: CLEREZZA-570
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-570
>             Project: Clerezza
>          Issue Type: New Feature
>            Reporter: Henry Story
>              Labels: jaxrs
>
> I am developing a class for a resource that could take or not take certain parameters.
> @GET def infoPage() : Response = { .. }
> @GET def authenticate(@QueryParam("authreqissuer") relyingPartySrvc: URL ): Response
= { ... }
> @GET def authenticate(@QueryParam("authreqissuer") relyingPartySrvc: URL , @QueryParam("pause")
pause: Boolean): Response = { ... }
> So I assumed naively - but that may say something about general newbie expectations -
that the methods that would match most parameters would be selected.
> It turns out that it is the first method that is called in RootResourceExecutorImpl 
>    final MethodAndConsumedAndProducibleTypes firstAcceptable = acceptableMethods.first();
> This leads to inconsistent and random behavior, as different functions are called for
different request of the same URI request.
> So a GET request on https://localhost:8443/srvc/webidp can call all of the above functions.
It then furthermore throws exceptions when it does not have the data for a method.
> As I saw these errors thrown I refactored my code a few times, and finally discovered
this was a problem in the triaxrs code.
> One could make a list of (attribute annotation pairs) and find out which methods had
the most of the attribtes available in the URI.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message