So,
I removed the "header-modifying code" from the MessageBodyWriter
implementation, and rewrote the client code that makes the request to
add the headers (skipping Content-Length). That seems to do the trick...
would still prefer to be able to do this in the MessageBodyWriter
implementation however.
Maarten
On 2016-05-19 10:58, Maarten Boekhold wrote:
> Hmmm,
>
> So I'm getting:
>
> May 19, 2016 10:53:12 AM
> org.glassfish.jersey.message.internal.HeaderUtils checkHeaderChanges
> WARNING: There are some request headers that have not been sent by
> connector [org.glassfish.jersey.apache.connector.ApacheConnector].
> Probably you added those headers in WriterInterceptor or
> MessageBodyWriter. That feature is not supported by the connector.
> Please, do not modify headers in WriterInterceptor or
> MessageBodyWriter or use default HttpUrlConnector instead.
> Unsent header changes: [Content-Length, Accept, Content-Type]
>
> And by using a LoggingFilter I can indeed see that these headers are
> not being sent (except for Content-Type).
>
> Is there any way to get around this limitation? Any other way to
> add/modify headers in a MessageBodyWriter?
>
> Maarten
>
> On 2016-05-19 09:51, Maarten Boekhold wrote:
>> Hi,
>>
>> The Jersey documentation contains the following warning:
>>
>> Be aware of using other than default |Connector| implementation.
>> There is an issue handling HTTP headers in |WriterInterceptor| or
>> |MessageBodyWriter<T>|. If you need to change header fields do
>> not use nor |ApacheConnectorProvider| nor
>> |GrizzlyConnectorProvider| neither |JettyConnectorProvider|.
>>
>> Is this really true? I have a Jersey client program that uses a
>> custom MessageBodyWriter that does:
>> while (headers.hasNext()) {
>> final MimeHeader hdr = headers.next();
>> httpHeaders.add(hdr.getName(), hdr.getValue());
>> }
>> Currently I'm using the default HttpUrlConnector, however we're
>> having some conflicts with authentication in the system (other parts
>> of the application also relying on HttpURLConnector), so I'd like to
>> switch to using the ApacheConnector instead. But if this warning
>> still applies, that would be a deal-breaker.
>>
>> Regards,
>>
>> Maarten
>