Don't forget you'll need to have the Accept header set to
"application/json" too, or something that accepts that (which includes */*,
to be fair). Since you've specified both @Produces and @Consumes, either of
them could cause your request to be not matched to this method.
On Mon, Jul 15, 2013 at 9:05 PM, <users-request_at_jersey.java.net> wrote:
> Table of contents:
>
> 1. [Jersey] Routing to a Resource that contains a Date parameter. -
> William Ferguson <william.ferguson_at_xandar.com.au>
> 2. [Jersey] Controlling the content of the "Allow" header - Paul Moore <
> paulkmoore_at_gmail.com>
> 3. [Jersey] Looking for insight into Jersey 2.0 matching decisions -
> William Ferguson <william.ferguson_at_xandar.com.au>
> 4. [Jersey] Re: Looking for insight into Jersey 2.0 matching decisions -
> Paul Moore <paulkmoore_at_gmail.com>
> 5. [Jersey] Re: Looking for insight into Jersey 2.0 matching decisions -
> Paul Moore <paulkmoore_at_gmail.com>
> 6. [Jersey] Re: Looking for insight into Jersey 2.0 matching decisions -
> William Ferguson <william.ferguson_at_xandar.com.au>
> 7. [Jersey] Re: Looking for insight into Jersey 2.0 matching decisions -
> William Ferguson <william.ferguson_at_xandar.com.au>
> 8. [Jersey] Re: Looking for insight into Jersey 2.0 matching decisions -
> Paul Moore <paul.k.moore_at_lineone.net>
> 9. [Jersey] Re: Looking for insight into Jersey 2.0 matching decisions -
> Paul Moore <paulkmoore_at_gmail.com>
>
>
>
> ---------- Forwarded message ----------
> From: William Ferguson <william.ferguson_at_xandar.com.au>
> To: users_at_jersey.java.net
> Cc:
> Date: Mon, 15 Jul 2013 21:09:14 +1000
> Subject: [Jersey] Routing to a Resource that contains a Date parameter.
> I am having trouble getting Jersey to match a resource that contains a
> java.util.Date parameter. As soon as I remove the Date field from the input
> the Resource is found.
>
> I thought at first that it was because my deserialization config (I'm
> using Jackson-2.2.2), but after several attempts, and after defining my own
> serialization/deserialization I realised that the deserialization isn't
> even being called before the Resource fails to match.
>
> So I'm wondering what I need to do to get Jersey to match against a Date
> parameter?
>
> Input:
> /timing/createJsonMeet
> {
> "meetDate": 1370786400000,
> "description": "My new meet thingy 1",
> "meetFileName": "Some meet file"
> }
>
> @POST
> @Path("/createJsonMeet")
> @Consumes(MediaType.APPLICATION_JSON)
> @Produces(MediaType.APPLICATION_JSON)
> public Meet createMeetJson(Meet meet) { // Where Meet is a simple POJO
> that contains a Date field called meetDate
> ...
> }
>
> NB I tried all kinds of date formats for meetDate but have left it at
> millis since epoch as this is what Jackson also serializes to.
>
> Note also that when I constructed and configured an ObjectMapperProvider,
> it's #getContext method was only being called when serializing outputs into
> the Response, never for deserializing the Request.
>
> Jersey-2.0
> Jackson-2.2.20
> Jetty-9.0.4.v20130625
>
> William
>
>
> ---------- Forwarded message ----------
> From: Paul Moore <paulkmoore_at_gmail.com>
> To: users_at_jersey.java.net
> Cc:
> Date: Tue, 16 Jul 2013 00:08:31 +0100
> Subject: [Jersey] Controlling the content of the "Allow" header
> Hi all,
>
> Just a quick question to find out if there's a sensible way to control the
> contents of the "Allow" header with some form of delegate pattern, or
> similar.
>
> My research to date indicates that the JAX-RS 2 spec support for handling
> the Allow header is:
>
>
> - Specifying the Allow header content using the ResponseBuilder (as
> part of normal processing)
> - Providing an @OPTIONS annotated method for direct Http Options
> requests
> - Some reflection based (auto) generation of the supported methods
> during handling of a NotAllowedMethod (405), specifically in
> MethodSelectingRouter::getMethodRouter
>
>
> To provide some context to what I'm trying to do...
>
> I have a collection that is POST accepting for some of the time. When the
> parent object is deemed *complete* no further POSTing of subordinate
> resources is permitted. In this way, an OPTIONS request to the subordinate
> (collection) should change from POST accepting to non-POST accepting e.g.
> "GET, POST, OPTIONS" -> "GET, OPTIONS"
>
> Have I missed something obvious, of am I off on a deep(er) journey into
> the Jersey internals?
>
> Note: I've also looked at Filters as a possible way of achieving this, but
> see no easy path to "get back to" the calling context i.e. a method in the
> resource class.
>
> Thoughts welcomely received
>
> Best regards
>
> Paul
>
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: William Ferguson <william.ferguson_at_xandar.com.au>
> To: users_at_jersey.java.net
> Cc:
> Date: Tue, 16 Jul 2013 09:52:40 +1000
> Subject: [Jersey] Looking for insight into Jersey 2.0 matching decisions
> I'm struggling to determine why Jersey is not matching a JSon POST Request
> against a Resource configured to consume MediaType.APPLICATION_JSON
>
> I have configured my Application with JacksonFeature.class and packages
> for my Resources. And the GET Resources are happily being served. But any
> Requests that consume JSon POJO are not being matched.
>
> @POST
> @Path("/create")
> @Consumes(MediaType.APPLICATION_JSON)
> @Produces(MediaType.APPLICATION_JSON)
> public Meet createMeetJson(Meet meet)
>
> What component is responsible for making the matching decision?
> Is there some way to switch on debug level logging so I can determine why
> the match is not being made?
>
> Jersey looked so promising originally but I'm finding the lack of
> visibility very frustrating.
>
> William
>
>
>
> ---------- Forwarded message ----------
> From: Paul Moore <paulkmoore_at_gmail.com>
> To: users_at_jersey.java.net
> Cc:
> Date: Tue, 16 Jul 2013 00:57:17 +0100
> Subject: [Jersey] Re: Looking for insight into Jersey 2.0 matching
> decisions
> Hi William,
>
> Obvious things first...
>
> Did you set the ContentType header of the HTTP request from the client?
>
> Best
>
> Paul
>
> On 16 July 2013 00:52, William Ferguson <william.ferguson_at_xandar.com.au>wrote:
>
>> I'm struggling to determine why Jersey is not matching a JSon POST
>> Request against a Resource configured to consume
>> MediaType.APPLICATION_JSON
>>
>> I have configured my Application with JacksonFeature.class and packages
>> for my Resources. And the GET Resources are happily being served. But any
>> Requests that consume JSon POJO are not being matched.
>>
>> @POST
>> @Path("/create")
>> @Consumes(MediaType.APPLICATION_JSON)
>> @Produces(MediaType.APPLICATION_JSON)
>> public Meet createMeetJson(Meet meet)
>>
>> What component is responsible for making the matching decision?
>> Is there some way to switch on debug level logging so I can determine why
>> the match is not being made?
>>
>> Jersey looked so promising originally but I'm finding the lack of
>> visibility very frustrating.
>>
>> William
>>
>>
>
>
> ---------- Forwarded message ----------
> From: Paul Moore <paulkmoore_at_gmail.com>
> To: users_at_jersey.java.net
> Cc:
> Date: Tue, 16 Jul 2013 01:32:23 +0100
> Subject: [Jersey] Re: Looking for insight into Jersey 2.0 matching
> decisions
> Sorry, that should be "Content-Type".
>
> Also, with regard to your logging question, Jersey uses the Java platform
> util logging (JUL). The easiest way to configure this depends on your
> environment. On Glassfish, in the admin console, goto Configurations >
> server-config > Logger Settings. Goto the "Log Levels" tab, and change or
> add a Logger Name of "org.glassfish.jersey"with an info level of your
> liking (click Save).
>
> P
>
> On 16 July 2013 00:57, Paul Moore <paulkmoore_at_gmail.com> wrote:
>
>> Hi William,
>>
>> Obvious things first...
>>
>> Did you set the ContentType header of the HTTP request from the client?
>>
>> Best
>>
>> Paul
>>
>>
>> On 16 July 2013 00:52, William Ferguson <william.ferguson_at_xandar.com.au>wrote:
>>
>>> I'm struggling to determine why Jersey is not matching a JSon POST
>>> Request against a Resource configured to consume
>>> MediaType.APPLICATION_JSON
>>>
>>> I have configured my Application with JacksonFeature.class and packages
>>> for my Resources. And the GET Resources are happily being served. But any
>>> Requests that consume JSon POJO are not being matched.
>>>
>>> @POST
>>> @Path("/create")
>>> @Consumes(MediaType.APPLICATION_JSON)
>>> @Produces(MediaType.APPLICATION_JSON)
>>> public Meet createMeetJson(Meet meet)
>>>
>>> What component is responsible for making the matching decision?
>>> Is there some way to switch on debug level logging so I can determine
>>> why the match is not being made?
>>>
>>> Jersey looked so promising originally but I'm finding the lack of
>>> visibility very frustrating.
>>>
>>> William
>>>
>>>
>>
>
>
> ---------- Forwarded message ----------
> From: William Ferguson <william.ferguson_at_xandar.com.au>
> To: users_at_jersey.java.net
> Cc:
> Date: Tue, 16 Jul 2013 10:47:53 +1000
> Subject: [Jersey] Re: Looking for insight into Jersey 2.0 matching
> decisions
> I believe so. I was using POSTman (http://www.getpostman.com/) to test
> via my browsers and configured the Request to be Json. Don't have ability
> to check at the moment.
>
>
> On Tue, Jul 16, 2013 at 9:57 AM, Paul Moore <paulkmoore_at_gmail.com> wrote:
>
>> Hi William,
>>
>> Obvious things first...
>>
>> Did you set the ContentType header of the HTTP request from the client?
>>
>> Best
>>
>> Paul
>>
>>
>> On 16 July 2013 00:52, William Ferguson <william.ferguson_at_xandar.com.au>wrote:
>>
>>> I'm struggling to determine why Jersey is not matching a JSon POST
>>> Request against a Resource configured to consume
>>> MediaType.APPLICATION_JSON
>>>
>>> I have configured my Application with JacksonFeature.class and packages
>>> for my Resources. And the GET Resources are happily being served. But any
>>> Requests that consume JSon POJO are not being matched.
>>>
>>> @POST
>>> @Path("/create")
>>> @Consumes(MediaType.APPLICATION_JSON)
>>> @Produces(MediaType.APPLICATION_JSON)
>>> public Meet createMeetJson(Meet meet)
>>>
>>> What component is responsible for making the matching decision?
>>> Is there some way to switch on debug level logging so I can determine
>>> why the match is not being made?
>>>
>>> Jersey looked so promising originally but I'm finding the lack of
>>> visibility very frustrating.
>>>
>>> William
>>>
>>>
>>
>
>
> ---------- Forwarded message ----------
> From: William Ferguson <william.ferguson_at_xandar.com.au>
> To: users_at_jersey.java.net
> Cc:
> Date: Tue, 16 Jul 2013 10:51:37 +1000
> Subject: [Jersey] Re: Looking for insight into Jersey 2.0 matching
> decisions
> I'm running inside Jetty which has it's own logging that is redirected to
> stdout by default.
> Shouldn't JUL also default to stdout? I'm not seeing anything from Jersey.
> I don';t think I've had to configure JUL in the last 10 years.
>
>
> On Tue, Jul 16, 2013 at 10:32 AM, Paul Moore <paulkmoore_at_gmail.com> wrote:
>
>> Sorry, that should be "Content-Type".
>>
>> Also, with regard to your logging question, Jersey uses the Java platform
>> util logging (JUL). The easiest way to configure this depends on your
>> environment. On Glassfish, in the admin console, goto Configurations >
>> server-config > Logger Settings. Goto the "Log Levels" tab, and change or
>> add a Logger Name of "org.glassfish.jersey"with an info level of your
>> liking (click Save).
>>
>> P
>>
>>
>> On 16 July 2013 00:57, Paul Moore <paulkmoore_at_gmail.com> wrote:
>>
>>> Hi William,
>>>
>>> Obvious things first...
>>>
>>> Did you set the ContentType header of the HTTP request from the client?
>>>
>>> Best
>>>
>>> Paul
>>>
>>>
>>> On 16 July 2013 00:52, William Ferguson <william.ferguson_at_xandar.com.au>wrote:
>>>
>>>> I'm struggling to determine why Jersey is not matching a JSon POST
>>>> Request against a Resource configured to consume
>>>> MediaType.APPLICATION_JSON
>>>>
>>>> I have configured my Application with JacksonFeature.class and
>>>> packages for my Resources. And the GET Resources are happily being served.
>>>> But any Requests that consume JSon POJO are not being matched.
>>>>
>>>> @POST
>>>> @Path("/create")
>>>> @Consumes(MediaType.APPLICATION_JSON)
>>>> @Produces(MediaType.APPLICATION_JSON)
>>>> public Meet createMeetJson(Meet meet)
>>>>
>>>> What component is responsible for making the matching decision?
>>>> Is there some way to switch on debug level logging so I can determine
>>>> why the match is not being made?
>>>>
>>>> Jersey looked so promising originally but I'm finding the lack of
>>>> visibility very frustrating.
>>>>
>>>> William
>>>>
>>>>
>>>
>>
>
>
> ---------- Forwarded message ----------
> From: Paul Moore <paul.k.moore_at_lineone.net>
> To: users_at_jersey.java.net
> Cc:
> Date: Tue, 16 Jul 2013 02:01:43 +0100
> Subject: [Jersey] Re: Looking for insight into Jersey 2.0 matching
> decisions
> Check out the "Preview" in POSTman. I think you'll need to set the
> "Content-Type" header. Have not really used POSTman though so no idea if
> it's doing other stuff under the covers - I suspect not though...
>
> On 16 July 2013 01:47, William Ferguson <william.ferguson_at_xandar.com.au>wrote:
>
>> I believe so. I was using POSTman (http://www.getpostman.com/) to test
>> via my browsers and configured the Request to be Json. Don't have ability
>> to check at the moment.
>>
>>
>> On Tue, Jul 16, 2013 at 9:57 AM, Paul Moore <paulkmoore_at_gmail.com> wrote:
>>
>>> Hi William,
>>>
>>> Obvious things first...
>>>
>>> Did you set the ContentType header of the HTTP request from the client?
>>>
>>> Best
>>>
>>> Paul
>>>
>>>
>>> On 16 July 2013 00:52, William Ferguson <william.ferguson_at_xandar.com.au>wrote:
>>>
>>>> I'm struggling to determine why Jersey is not matching a JSon POST
>>>> Request against a Resource configured to consume
>>>> MediaType.APPLICATION_JSON
>>>>
>>>> I have configured my Application with JacksonFeature.class and
>>>> packages for my Resources. And the GET Resources are happily being served.
>>>> But any Requests that consume JSon POJO are not being matched.
>>>>
>>>> @POST
>>>> @Path("/create")
>>>> @Consumes(MediaType.APPLICATION_JSON)
>>>> @Produces(MediaType.APPLICATION_JSON)
>>>> public Meet createMeetJson(Meet meet)
>>>>
>>>> What component is responsible for making the matching decision?
>>>> Is there some way to switch on debug level logging so I can determine
>>>> why the match is not being made?
>>>>
>>>> Jersey looked so promising originally but I'm finding the lack of
>>>> visibility very frustrating.
>>>>
>>>> William
>>>>
>>>>
>>>
>>
>
>
> ---------- Forwarded message ----------
> From: Paul Moore <paulkmoore_at_gmail.com>
> To: users_at_jersey.java.net
> Cc:
> Date: Tue, 16 Jul 2013 02:15:20 +0100
> Subject: [Jersey] Re: Looking for insight into Jersey 2.0 matching
> decisions
> You could add a vote for this: https://java.net/jira/browse/JERSEY-1275 ;)
>
> On 16 July 2013 01:51, William Ferguson <william.ferguson_at_xandar.com.au>wrote:
>
>> I'm running inside Jetty which has it's own logging that is redirected to
>> stdout by default.
>> Shouldn't JUL also default to stdout? I'm not seeing anything from
>> Jersey. I don';t think I've had to configure JUL in the last 10 years.
>>
>>
>> On Tue, Jul 16, 2013 at 10:32 AM, Paul Moore <paulkmoore_at_gmail.com>wrote:
>>
>>> Sorry, that should be "Content-Type".
>>>
>>> Also, with regard to your logging question, Jersey uses the Java
>>> platform util logging (JUL). The easiest way to configure this depends on
>>> your environment. On Glassfish, in the admin console, goto Configurations
>>> > server-config > Logger Settings. Goto the "Log Levels" tab, and change
>>> or add a Logger Name of "org.glassfish.jersey"with an info level of your
>>> liking (click Save).
>>>
>>> P
>>>
>>>
>>> On 16 July 2013 00:57, Paul Moore <paulkmoore_at_gmail.com> wrote:
>>>
>>>> Hi William,
>>>>
>>>> Obvious things first...
>>>>
>>>> Did you set the ContentType header of the HTTP request from the client?
>>>>
>>>> Best
>>>>
>>>> Paul
>>>>
>>>>
>>>> On 16 July 2013 00:52, William Ferguson <william.ferguson_at_xandar.com.au
>>>> > wrote:
>>>>
>>>>> I'm struggling to determine why Jersey is not matching a JSon POST
>>>>> Request against a Resource configured to consume
>>>>> MediaType.APPLICATION_JSON
>>>>>
>>>>> I have configured my Application with JacksonFeature.class and
>>>>> packages for my Resources. And the GET Resources are happily being served.
>>>>> But any Requests that consume JSon POJO are not being matched.
>>>>>
>>>>> @POST
>>>>> @Path("/create")
>>>>> @Consumes(MediaType.APPLICATION_JSON)
>>>>> @Produces(MediaType.APPLICATION_JSON)
>>>>> public Meet createMeetJson(Meet meet)
>>>>>
>>>>> What component is responsible for making the matching decision?
>>>>> Is there some way to switch on debug level logging so I can determine
>>>>> why the match is not being made?
>>>>>
>>>>> Jersey looked so promising originally but I'm finding the lack of
>>>>> visibility very frustrating.
>>>>>
>>>>> William
>>>>>
>>>>>
>>>>
>>>
>>
>
> End of digest for list users_at_jersey.java.net - Tue, 16 Jul 2013
>
>
--
Simon Roberts
Certified Professional Photographer
http://dancingcloudphotography.com
(303) 249 3613