Hi Gabo
Hi Sergey,
Is there a resource that shows how the filter is integrated with the rest of the application? I mean, where do I state that I want
this filter used, i.e. how would the spring configuration file look like?
I've updated the documentation a bit to show how filters can be configured from
Spring. As they're considered
as JAXRS providres by CXF JAXRS runtime, they're registered the same way as other JAXRS providers (message body readers/writers,
exception mappers. context handlers, etc)
As of now, what I did is to set the phase at POST_PROTOCOL and force the chain to abort and flush whatever it already currently
has. I'm thinking that skipping the USER_ and POST_ STREAM is not a good idea, no? Does the trick tho.
I guess what I don't understand is whether your POST_PROTOCOL CXF interceptor invoked before JAXRSOutInterceptor or after. My
understanding is that it has to be invoked after, so I don't get why the headers are lost if a message is not aborted and preserved
if it is. Perhaps AbstractHttpDestination swallows custom headers ? but we do have tests confirming it's not...I don't have tests at
the moment involving JAXRS and CXF interceptors, so I'll try to write one and see what happens.
Cheers, Sergey
Gabo
Sergey Beryozkin wrote:
Hi Gabo,
Sorry, missed your message this morning.
If you put your CXF interceptor at POST_PROTOCOL level then it should work.
Can you debug it and see what happens ?
JAXRSOutInterceptor sits at the MARSHALL phase and POST_PROTOCOL should be
handled after it.
Now that you mentioned it I reckon there's a bug in JAXRSOutInterceptor in that if you add headers from a cxf out interceptor
after the invocation has returned but before JAXRSOutInterceptor is invoked then such headers might be lost/overriden - but I
need to verify if it's the case.
Implementing ResponseHandler filter is another option, but doing it at
POST_PROTOCOL with CXF out interceptor should work too...
Cheers, Sergey
