Re: [Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?
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 bbu...@redhat.com: 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 -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?
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 Resteasy-users@lists.sourceforge.net 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 Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Running ContainerWriteFilter *after* WriterInterceptor?
Hey Bill, thanks for your reply. Am 07.06.2014 um 22:08 schrieb Bill Burke bbu...@redhat.com: 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 Resteasy-users@lists.sourceforge.net 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 Resteasy-users@lists.sourceforge.net 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 -- 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 Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users