resteasy-users

[Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?

[Heiko W.R. <hr...@re...>]

Hey,

I have a use case where the user is requesting jsonp encoding e.g. via custom media type or a .jsonw ending.

Anyway. I can intercept the call and surround with "jsonp();" successfully, but the returned
content-type needs to be changed to "application/javascript".

I could accept that as incoming type, but then RE is complaining about no matching MessageBodyWriter.

So I am thinking of using ContainerWriteFilter to re-write this, but the calls seem to be

MessageHandler method (@GET foo() {} )  (1)
ContainerWriteFilter   (2)
<message body writer> (3)
WriterInterceptor. (4)
(5)

So when I rewrite the content header in (2) a the mbw in (3) complains about wrong type and
in (4) I can not check if the desired content type is my custom one to request the wrapping or not.

So I would need to run a ContainerWriteFilter at (5) to rewrite the header *after* the interceptor has run.

In RHQ I solved that with a normal servlet filter, but it looks like this does not work here because
of Async processing (and rewriting the filter with an AsyncListener has its own issues )

Thanks
   Heiko

Re: [Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?

[Bill B. <bb...@re...>]

Unfortunately, the JAX-RS TCK expects that the MBW is not matched until 
after the WriterInterceptor is invoked.   We used to match prior to 
invoking the interceptor chain...

So, you have 2 options:

1. In your WriterInterceptor buffer the json marshalling, change the 
content header, flush the buffer.

2. Write a special MBW that delegates to the JSON writer and sets the 
content header before doing this.

Make sense?

On 6/7/2014 1:00 PM, Heiko W.Rupp wrote:
> Hey,
>
> I have a use case where the user is requesting jsonp encoding e.g. via custom media type or a .jsonw ending.
>
> Anyway. I can intercept the call and surround with "jsonp();" successfully, but the returned
> content-type needs to be changed to "application/javascript".
>
> I could accept that as incoming type, but then RE is complaining about no matching MessageBodyWriter.
>
> So I am thinking of using ContainerWriteFilter to re-write this, but the calls seem to be
>
> MessageHandler method (@GET foo() {} )  (1)
> ContainerWriteFilter   (2)
> <message body writer> (3)
> WriterInterceptor. (4)
> (5)
>
> So when I rewrite the content header in (2) a the mbw in (3) complains about wrong type and
> in (4) I can not check if the desired content type is my custom one to request the wrapping or not.
>
> So I would need to run a ContainerWriteFilter at (5) to rewrite the header *after* the interceptor has run.
>
> In RHQ I solved that with a normal servlet filter, but it looks like this does not work here because
> of Async processing (and rewriting the filter with an AsyncListener has its own issues )
>
> Thanks
>     Heiko
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?

[Heiko W.R. <hr...@re...>]

Hey Bill,

thanks for your reply.

Am 07.06.2014 um 22:08 schrieb Bill Burke <bb...@re...>:

> Unfortunately, the JAX-RS TCK expects that the MBW is not matched until 
> after the WriterInterceptor is invoked.   We used to match prior to 

What a c$%@!

> invoking the interceptor chain...

Which makes so much sense

> 
> So, you have 2 options:
> 
> 1. In your WriterInterceptor buffer the json marshalling, change the 
> content header, flush the buffer.

I have this block in aroundWriteTo:

            try {
                context.proceed();
            } finally {
                context.getHeaders().get("Content-Type").clear();
                context.getHeaders().putSingle("Content-Type",APPLICATION_JAVASCRIPT);
            }

But that header change is not recorded in the output.
And when I understand you correctly above, this would be an issue anyway,
because the changed header would influence the MBW matcher which runs after the interceptor.


> 2. Write a special MBW that delegates to the JSON writer and sets the 
> content header before doing this.

Sounds like a plan to investigate.

Thanks
  Heiko

> 
> Make sense?
> 
> On 6/7/2014 1:00 PM, Heiko W.Rupp wrote:
>> Hey,
>> 
>> I have a use case where the user is requesting jsonp encoding e.g. via custom media type or a .jsonw ending.
>> 
>> Anyway. I can intercept the call and surround with "jsonp();" successfully, but the returned
>> content-type needs to be changed to "application/javascript".
>> 
>> I could accept that as incoming type, but then RE is complaining about no matching MessageBodyWriter.
>> 
>> So I am thinking of using ContainerWriteFilter to re-write this, but the calls seem to be
>> 
>> MessageHandler method (@GET foo() {} )  (1)
>> ContainerWriteFilter   (2)
>> <message body writer> (3)
>> WriterInterceptor. (4)
>> (5)
>> 
>> So when I rewrite the content header in (2) a the mbw in (3) complains about wrong type and
>> in (4) I can not check if the desired content type is my custom one to request the wrapping or not.
>> 
>> So I would need to run a ContainerWriteFilter at (5) to rewrite the header *after* the interceptor has run.
>> 
>> In RHQ I solved that with a normal servlet filter, but it looks like this does not work here because
>> of Async processing (and rewriting the filter with an AsyncListener has its own issues )
>> 
>> Thanks
>>    Heiko
>> 
>> 
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, 
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters

Re: [Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?

[Bill B. <bb...@re...>]

On 6/7/2014 5:51 PM, Heiko W.Rupp wrote:
> Hey Bill,
>
> thanks for your reply.
>
> Am 07.06.2014 um 22:08 schrieb Bill Burke <bb...@re...>:
>
>> Unfortunately, the JAX-RS TCK expects that the MBW is not matched until
>> after the WriterInterceptor is invoked.   We used to match prior to
>
> What a c$%@!
>
>> invoking the interceptor chain...
>
> Which makes so much sense
>
>>
>> So, you have 2 options:
>>
>> 1. In your WriterInterceptor buffer the json marshalling, change the
>> content header, flush the buffer.
>
> I have this block in aroundWriteTo:
>
>              try {
>                  context.proceed();
>              } finally {
>                  context.getHeaders().get("Content-Type").clear();
>                  context.getHeaders().putSingle("Content-Type",APPLICATION_JAVASCRIPT);
>              }
>


> But that header change is not recorded in the output.
> And when I understand you correctly above, this would be an issue anyway,
> because the changed header would influence the MBW matcher which runs after the interceptor.
>

Headers get flushed and can't be changed after the entity has been 
written to the stream.

Again, you'll have to buffer the entity and rewrite it to the actual 
stream after you've changed the content-type header.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com