jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: Target: two new properties

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 08 Sep 2011 14:09:00 +0200

On 09/08/2011 11:24 AM, Sergey Beryozkin wrote:
> Comments inline,
>
> On 07/09/11 14:22, Marek Potociar wrote:
>>
>> So, can you please share the examples you have in mind?
>>
>
> Well, I've been thinking about cases where at a certain point in the application path a decision is made, based on say
> the GET response or certain HTTP error status, that the alternative route having the same origin as this current route
> has to be tried.
> In this particular case we can get an origin passed along all the time - possible. However if we generalize the problem
> a bit and say we want
> a method like go(Target) do roam around and revert back to the prev segment, or may be to the origin, or may be two
> segments back, all in order to retry, then we'd probably have to code to pass a stack of Targets along.
> Also allows for an alternative impl of the iterations...
>

The first use case does not apply to target's base URI, since anything in the response is resolved using the URI of the
request. The target's base uri gets never considered.

Second use case realy does sound academic and most likely can be 100% covered by existing API with a slight change in
the approach to the implementation.

> np if the above sounds a bit academical or non-practical. I'm not sure, there's no 'glue' between various Targets,
> probably simplifies things at the impl level.
>
>> What do you mean when you say "property"? Static method?
>>
>
> Meant that Target class would have getter and setter for a baseTarget property

Ok, I understand now.

>
>> So, just to make sure we are on the same page, what would be the value of "uri" in the following example?
>>
>> URI uri = client.target("http://service").path("1").path("2).path("3").prevTarget().prevTarget().getUri();
>>
>> My point is that the code above demonstrates the need to use a stack to implement prevTarget() properly. And the problem
>> I see is that you need to use this stack even in the 99.9% Target use cases where the method is not needed. Not to
>> mention that the stack can grow pretty much indefinitely.
>>
>
> In the above we have t1, t2, t3 and t4 targets, where t1 corresponds to client.target("http://service"), etc.
>
> Here is the links, the way I see them:
>
> t4 -> t3 (prev)
> t4 -> t1 (base)
>
> t3 -> t2 (prev)
> t3 -> t1 (base)
>
> t2 -> t1 (prev)
> t2 -> t1 (base)
>
> t1 -> null
> t1 -> null
>
> Looks like a linked list to me...

Reverse linked list with appending to the end (or linked list with insertion at the beginning) = stack :)

In any case, the problem with keeping the (most often unnecessary) creation history data all the time remains.

Marek
>
>>>
>>> I'm concerned I'm seeing the immutability showing its other side here...It allows for doing the explicit dynamic
>>> configuration of Targets in the code - which IMHO does not belong to the application layer at all - but presents a
>>> challenge to introducing properties
>>> which IMHO could be explored at runtime dynamically...
>>
>> I am not sure I follow the above. Can you please be more specific?
>>
> I was referring to the possible difficulty associated with adding those props (possible leaks ?, etc) which is a
> side-effect of having the immutability in place...Immutability does have it pluses, and for me that would probably be
> sharing a single Target across multiple threads (not sure yet what would happen there in case of template vars being
> used in the Target path)...
>
> Anyway, I'm kind of easy now on having this properties added or letting the developers deal with them if needed
> Sergey
>
>> Marek
>>
>>>
>>>> Anyway, if you still feel strongly about this proposal, please open a new Jira issue to track this RFE too.
>>>>
>>> Lets see if it's worth it...
>>> Sergey
>>>
>>>> Marek
>>>>
>>>>> This makes Target a more 'capable' and allows for tracing all the intermediate Targets. To some extent this can be
>>>>> compared to UriInfo.getMatchedURIs property...
>>>>>
>>>>> Rules:
>>>>>
>>>>> All Targets created from absolute URIs must return null;
>>>>> Those created from Target.path(relativePath); return the previous Target.
>>>>>
>>>>> Examples:
>>>>>
>>>>> Target t = client.target("http://service");
>>>>> assertNull(t.getPrevTarget());
>>>>>
>>>>> Target t2 = t.path("2");
>>>>> assertSame(t, t2.getPrevTarget());
>>>>>
>>>>> assertSame(t2, t2.path("3").getPrevTarget());
>>>>>
>>>>>
>>>>> Comments ?
>>>>> Sergey
>>>>>
>>>>> [1]
>>>>> http://java.net/projects/jax-rs-spec/sources/git/content/src/jax-rs-api/src/main/java/javax/ws/rs/client/Target.java?rev=bdee7808db117198b8e611551a12a099bcf6b103
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Cheers, Sergey
>>>
>>>
>
>