On Nov 16, 2012, at 11:11 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>
> On Nov 16, 2012, at 4:46 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
>>
>> On Nov 16, 2012, at 10:40 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>>
>>> Jan,
>>>
>>> My gut reaction is that we should not absolutize URIs on the server, it can lead to all sorts of problems (clustering environments, etc.).
>>
>> Yes. That was what I came to, too (in my However(!) sentence)
>
> I see.
>
>>
>>> We should instead have the notion of a base URI on the client, and have the client API do the work, just like a browser.
>>
>> That is the problem. The existing base URI 'determining' algorithm will lead to anything, but never to the JAX-RS application path.
>
> I didn't mean we'd do this automatically. We should ask the "human" developer for help :)
>
>> I am now thinking that there is 'concept' missing - I'll think about it and see if I get an idea of it, at least.
>
> Sounds good.
What about putting an alternative Link/Uri -fromResourceXX() base URI in ApplicationConfig?
@javax.ws.rs.ApplicationPath("resources")
@javax.ws.rs.BaseUri("
http://service.ex.org/erp-system/api")
public class ApplicationConfig extends javax.ws.rs.core.Application {
}
Not ideal, but maybe it triggers other thoughts.
On a second thought: maybe the runtime can set an internal base URI by inspecting the request URI of the first HTTP request that hits the system?
Nah ... anything else?
Jan
>
> -- Santiago
>
>>
>>>
>>> If there isn't one, could you file a JIRA for this? Thanks.
>>>
>>> -- Santiago
>>>
>>> On Nov 14, 2012, at 5:29 AM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>>
>>>> Links that are constructed by using Link.fromResource or Link.fromResourceMethod come with a relative URI.
>>>>
>>>> This URI is always relative to the JAX-RS application context.
>>>>
>>>> If I am not completely out of my mind, these links are never useful as-is, because they are always relative in a way that doesn't fit any current resolution context.
>>>>
>>>> At leat not without applying rewrite rules in front of the container.
>>>>
>>>> E.g. suppose my app is living at
>>>>
>>>> http://example.org/myWarName/
>>>>
>>>> and my resources at
>>>>
>>>> http://example.org/myWarName/resources
>>>>
>>>> Now if I have
>>>>
>>>> @Path("orders/service")
>>>> class OrderResource { ... }
>>>>
>>>> @Path("customers/accounts/{id}")
>>>> class CustomerResource { ... }
>>>>
>>>>
>>>> and I do a GET on 'my' account:
>>>>
>>>> GET http://example.org/myWarName/resources/customers/accounts/42
>>>>
>>>> What might come back is a response with a Link to the order service:
>>>>
>>>> 200 Ok
>>>> Link: <orders/service>;rel=...
>>>>
>>>> ....
>>>>
>>>>
>>>> This link would never resolve to:
>>>>
>>>>
>>>> http://example.org/myWarName/resources/orders/service
>>>>
>>>> but, (hope I get this right) to
>>>>
>>>> orders/service
>>>>
>>>> http://example.org/myWarName/resources/customers/accounts/orders/service
>>>>
>>>>
>>>> Bottom line seems to be: the runtime should prepend the base URI and produce absolute links.
>>>>
>>>> However(!) given that it is very unusual to have the actual base-URI as the publicly visible base URI (there is usually quite a bunch of mangling going on) producing an absolute URI does cut it either - in fact it would be worse.
>>>>
>>>> Maybe we need to rethink the UriBuilder.fromXXX behavior to that regard, too.
>>>>
>>>>
>>>> Any ideas?
>>>>
>>>>
>>>> Jan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>