Understood Bill but in this case I have a WebTarget instance to play with.
While I can create a new one with .path() I cannot with .uri(). For me
it's just a bit of an odd abstraction and separation of concerns between
UriBuilder and WebTarget. There's a little builder-ness and state-ness to
WebTarget. A little feature envy between them. It might have been better
off with a WebTargetBuilder that would produce immutable targets.
On Fri, Dec 13, 2013 at 9:13 PM, Bill O'Neil <oneil5045_at_gmail.com> wrote:
> The WebTarget works in the same way as a UriBuilder so its not very hard
> to use or if you look at the documentation you can also target a URI
>
> /**
>
> * Build a new web resource target.
>
> *
>
> * @param uri web resource URI. Must not be {_at_code null}.
>
> * @return web resource target bound to the provided URI.
>
> * @throws NullPointerException in case the supplied argument is
> {_at_code null}.
>
> */
>
> public WebTarget target(URI uri);
>
>
> On Sat, Dec 14, 2013 at 12:04 AM, Robert DiFalco <robert.difalco_at_gmail.com
> > wrote:
>
>> Ah okay. Wish there was still the uri() method in addition to the string
>> path. In this case the string was properly created from a UriBuilder with
>> query params properly specified.
>>
>> Sent from my iPhone
>>
>> On Dec 13, 2013, at 8:53 PM, "Bill O'Neil" <oneil5045_at_gmail.com> wrote:
>>
>> A ? is not legal in the path. It is being correctly url escaped to
>>
>> /footest%3Ffoo=notnull
>>
>> Path and Query params need to be escaped differently.
>>
>>
>> On Fri, Dec 13, 2013 at 11:51 PM, Robert DiFalco <
>> robert.difalco_at_gmail.com> wrote:
>>
>>> That's the difference. If you put the query paran in the path string per
>>> my example you should see it fail. Is that not considered legal?
>>>
>>> Sent from my iPhone
>>>
>>> On Dec 13, 2013, at 8:46 PM, "Bill O'Neil" <oneil5045_at_gmail.com> wrote:
>>>
>>> ClientBuilder.newClient().target("http://localhost:8080/footest"
>>> ).queryParam("foo", "notnull").request().post(null);
>>>
>>>
>>> works fine
>>>
>>>
>>> On Fri, Dec 13, 2013 at 11:44 PM, Robert DiFalco <
>>> robert.difalco_at_gmail.com> wrote:
>>>
>>>> Right because I think the issue is the client API.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Dec 13, 2013, at 8:33 PM, "Bill O'Neil" <oneil5045_at_gmail.com> wrote:
>>>>
>>>> I have no issues with this.
>>>>
>>>> Jersey 2.4.1
>>>>
>>>> @Path( "/footest" )
>>>> @POST
>>>> public void iDoNotKnowHowToDebug(
>>>> @QueryParam( "foo") String foo,
>>>> @Context UriInfo uriInfo ) throws Exception {
>>>> System.out.println( "foo=" + foo );
>>>> }
>>>>
>>>> curl -X POST "localhost:8080/footest?foo=notnull"
>>>>
>>>> output: foo=notnull
>>>>
>>>>
>>>> On Fri, Dec 13, 2013 at 11:18 PM, Robert DiFalco <
>>>> robert.difalco_at_gmail.com> wrote:
>>>>
>>>>> I'm back with more questions found while upgrading from 1.9 to 2.4.1.
>>>>> I don't know if this is a client or a server issue.
>>>>>
>>>>> But if I perform a POST with no PathParam but with a QueryParam then
>>>>> the QueryParam will be overwritten with null. For example:
>>>>>
>>>>> @Path( "/footest" )
>>>>> @POST
>>>>> public void badlyDesignedPostOperation(
>>>>> @QueryParam( "foo") String foo,
>>>>> @Context UriInfo uriInfo ) throws Exception {
>>>>> System.out.println( "foo=" + foo );
>>>>> }
>>>>>
>>>>>
>>>>> Now the test code:
>>>>>
>>>>> resource().path( "/footest?foo=notnull" ).method( "POST" );
>>>>>
>>>>> Instead of "notnull" the output will be null because null with
>>>>> overwrite the QueryParameter. I'm guess POST was implemented to always
>>>>> think a parameter was being sent so it ends up overwriting the query
>>>>> parameter as a path parameter.
>>>>>
>>>>> Is this expected?
>>>>>
>>>>>
>>>>
>>>
>>
>