On Jul 10, 2009, at 8:22 AM, Christopher Schmidt wrote:
> Hi Paul, we are using also a Servlet as a client.
OK, i thought so.
> The servers logging is configured like this:
>
> <init-param>
> <param-
> name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
> <param-
> value>com.sun.jersey.api.container.filter.LoggingFilter</param-value>
> </init-param>
>
Can you also add:
<init-param>
<param-
name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
<param-
value>com.sun.jersey.api.container.filter.LoggingFilter</param-value>
</init-param>
So that the responses get logged?
> Can I do something like this for your mentioned client filter as well?
>
Yes.
Client c = ...
c.addFilter(
new com.sun.jersey.api.client.filter.LoggingFilter());
Hopefully that should give us additional information to close in on
where the problem is located.
Paul.
> Regards Christopher
>
>
> Am 09.07.09 13:18 schrieb "Paul Sandoz" unter <Paul.Sandoz_at_Sun.COM>:
>
>> Hi Christopher,
>>
>> Given that this happens about 0.01 % of the time i am wondering if
>> there is a subtle race condition in the Tomcat server when setting
>> response headers. All Jersey does is pass it's headers over to the
>> servlet response.
>>
>> Do you have also logging of the "Out-bound response sent" from the
>> server to the client? it would be useful to know if the content-
>> type was set correctly by Jersey.
>>
>> You can also ad logging to the client side as well:
>>
>> https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/jersey/com/sun/jersey/api/client/filter/LoggingFilter.html
>>
>> Maybe some tomcat-level logging of response headers would also be
>> useful?
>>
>> Paul.
>>
>> On Jul 9, 2009, at 9:40 AM, Christopher Schmidt wrote:
>>
>>> Hello, sometimes when I access the following resource method
>>> (TargetEnh is a subclassed JAXB object):
>>>
>>> @GET @Produces("application/xml") @Path("target/object/
>>> {tId}/") @RequiresMorphSession public Target
>>> getTarget(@PathParam("tId") String tId) { ... return
>>> new TargetEnh(oi, getUser()); }
>>>
>>> With the following client code:
>>>
>>> return getTargetResource().path("target/object/" +
>>> targetId).header("Authorization",
>>> user
>>> .userCredentials
>>> ()).accept
>>> ( MediaType.APPLICATION_XML).get(Target.class);
>>>
>>> I get sometimes the following exception.
>>>
>>> 115131 * In-bound request received
>>> 115131 > GET http://as2-srv-ts:8080/OspWS/V1/Target/target/object/
>>> 953111100000169
>>> 115131 > authorization: Basic b3NyOmNvcw==
>>> 115131 > connection: keep-alive
>>> 115131 > cache-control: no-cache
>>> 115131 > host: as2-srv-ts:8080
>>> 115131 > user-agent: Java/1.6.0_07
>>> 115131 > pragma: no-cache
>>> 115131 > accept: application/xml
>>> 115131 >
>>> ERROR [Thread-156] .eads.web.rrs.DataManager <http://web.rrs.DataManager
>>> > Unable to update Track
>>> com.eads.ospws.client.service.OspWSServiceException: Failure to
>>> process the HTTP request or HTTP response
>>> in Class:
>>> com.eads.ospws.client.service.BorderEventClientService
>>> in Method: getTarget
>>> at
>>> com
>>> .eads
>>> .ospws
>>> .client
>>> .service
>>> .BorderEventClientService
>>> .getTarget_aroundBody19$advice(BorderEventClientService.java:25)
>>> at
>>> com
>>> .eads
>>> .ospws
>>> .client
>>> .service
>>> .BorderEventClientService.getTarget(BorderEventClientService.java:1)
>>> at com.eads.web.rrs.WebObjectFactory.updateLocation <http://web.rrs.WebObjectFactory.updateLocation
>>> > (WebObjectFactory.java:84)
>>> at com.eads.web.rrs.DataManager.updateTrack <http://web.rrs.DataManager.updateTrack
>>> > (DataManager.java:865)
>>> at com.eads.web.rrs.DataManager.fireNotification <http://web.rrs.DataManager.fireNotification
>>> > (DataManager.java:784)
>>> at com.eads.web.rrs.notification.NotificationQueue.run <http://web.rrs.notification.NotificationQueue.run
>>> > (NotificationQueue.java:74)
>>> Caused by: com.sun.jersey.api.client.ClientHandlerException: A
>>> message body reader for Java type, class
>>> com.eads.ospws.resource.jaxb.Target, and MIME media type,
>>> application/octet-stream, was not found
>>> at
>>> com
>>> .sun
>>> .jersey.api.client.ClientResponse.getEntity(ClientResponse.java:255)
>>> at
>>> com
>>> .sun
>>> .jersey.api.client.ClientResponse.getEntity(ClientResponse.java:220)
>>> at
>>> com.sun.jersey.api.client.WebResource.handle(WebResource.java:561)
>>> at com.sun.jersey.api.client.WebResource.access
>>> $300(WebResource.java:69)
>>> at com.sun.jersey.api.client.WebResource
>>> $Builder.get(WebResource.java:451)
>>> at
>>> com
>>> .eads
>>> .ospws
>>> .client
>>> .service
>>> .BorderEventClientService
>>> .getTarget_aroundBody18(BorderEventClientService.java:194)
>>> at
>>> com
>>> .eads
>>> .ospws
>>> .client
>>> .service
>>> .BorderEventClientService
>>> .getTarget_aroundBody19$advice(BorderEventClientService.java:23)
>>> ... 5 more
>>>
>>>
>>> It seams to me that the response header does not contain a
>>> “content-type” field.
>>> This only happens about 3-10 times per day calling this GET
>>> method about 2 times per second.
>>>
>>> (using Tomcat 6, Jersey 1.0.3 on a linux 64bit system)
>>>
>>> Any suggestions?
>>>
>>> Best regards
>>>
>>
>>