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
>>>
>>>
>>
>