On 12/21/2014 1:10 PM, Markus KARG wrote:
>>> About the missing metadata can you please elaborate what you think is
>>> missing hence imposes a need to "guess"?
>> The container has to guess how to resolve B in your example because you
>> have not provided the resource class and method name that contains the
>> @Path that resolves B.
>
> Maybe I miss something, but I think it should be fairly straightforward to
> implement "lookupLink" given an instance of class "B" at runtime using a
> dumb brute force algorithm:
>
> * Iterate over all resources
> * For each resource iterate over all resource methods
> * If resource method's return type is "B", add it to candidates list.
> * After that, iterate over all candidates
> * If candidate is "@GET" then return this one as the final result.
> * If no candidate is "@GET" then return the first one as the final result.
> * If there are no candidates, then this application has a programming error,
> because the application vendor wants to link "B" but has no resource method
> for it.
>
This brute force algorithm only works for simple JAX-RS applications.
There may be multiple methods that return type "B". Each of these
resource methods may have one or more path, query, and matrix parameters
that the others don't have.
> As JAX-RS implementations already know the absolute URI for each resource
> (otherwise they couldn't route a request to a resource method), the
> algorithm's last step would be to use that URI and build a link from it.
>
There is not a one to one relationship between resource and
representation.
>>> Looking at your MBW example again, I don't see why you need a specific
>>> method for Link lookup. Can't you just use UriBuilder?
>
> Scenario: I am a third-party MBW vendor for document schema "FOO". I do not
> know who will ever use my MBW. There is some application vendor who picks my
> MBW because he has to add support for schema "FOO" to his existing
> application. He doesn't know how my MBW works internally (whether he uses
> JAXB, JSONB, or no such API at all). How should my MBW ever be technically
> able to find out the URI where "@GET" provides "B", in a pure JAX-RS
> solution, without any vendor-specific APIs, and how should my MBW know where
> in the model it shall replace object references by URIs? If you post a code
> example for that, I will agree with you. If not, you know the answer why a
> UriBuilder cannot be "just" used.
>
Again the problem is that it is impossible for a link lookup method to
know exactly what resource to match to. Also, I just don't see this
"separation" you keep talking about. This fictional MBW you are talking
about would only ever work if JAX-RS resource class implementers
followed a strict (and limited) implentation. Too brittle IMO.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com