Return-Path: 
 <users-return-13515-apmail-cxf-users-archive=cxf.apache.org@cxf.apache.org>
Delivered-To: apmail-cxf-users-archive@www.apache.org
Received: (qmail 88400 invoked from network); 17 Feb 2009 09:57:20 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 17 Feb 2009 09:57:20 -0000
Received: (qmail 12610 invoked by uid 500); 17 Feb 2009 09:57:14 -0000
Delivered-To: apmail-cxf-users-archive@cxf.apache.org
Received: (qmail 12574 invoked by uid 500); 17 Feb 2009 09:57:14 -0000
Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@cxf.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@cxf.apache.org>
List-Post: <mailto:users@cxf.apache.org>
List-Id: <users.cxf.apache.org>
Reply-To: users@cxf.apache.org
Delivered-To: mailing list users@cxf.apache.org
Received: (qmail 12563 invoked by uid 99); 17 Feb 2009 09:57:14 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Feb 2009 01:57:14 -0800
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=SPF_NEUTRAL,WHOIS_MYPRIVREG
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [70.42.72.23] (HELO mail.solegy.com) (70.42.72.23)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Feb 2009 09:57:04 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.solegy.com (Postfix) with ESMTP id 25750210002B
	for <users@cxf.apache.org>; Tue, 17 Feb 2009 09:56:43 +0000 (GMT)
Received: from mail.solegy.com ([127.0.0.1])
	by localhost (mail.solegy.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Cj4eoKcciq5I for <users@cxf.apache.org>;
	Tue, 17 Feb 2009 09:56:43 +0000 (GMT)
Received: from [192.168.0.112] (unknown [222.127.215.98])
	by mail.solegy.com (Postfix) with ESMTP id 5BFAA2100025
	for <users@cxf.apache.org>; Tue, 17 Feb 2009 09:56:42 +0000 (GMT)
Message-ID: <499A89D8.8020200@solegysystems.com>
Date: Tue, 17 Feb 2009 09:56:40 +0000
From: Gabo Manuel <kmanuel@solegysystems.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: [OutInterceptor][HttpHeader] Adding Authorization-Info entry
 to http header
References: <4913D2A8.2080104@solegysystems.com>
 <01f601c940f6$a9ad7720$e002050a@IONAGLOBAL.COM>
 <4917F8C2.3000200@solegysystems.com>
 <008e01c94331$76f07b60$e002050a@IONAGLOBAL.COM>
In-Reply-To: <008e01c94331$76f07b60$e002050a@IONAGLOBAL.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Hi Sergey,

 > so I'll try to write one and see what happens.

Sorry for the late reply. I tried this again with the recent snapshot 
and the headers are still lost unless I abort the interceptor chain.

The implementation I have extends AbstractPhaseInterceptor<Message>. 
Phase is at Phase.POST_PROTOCOL. Code to set the header is as follows:

        Map<String, List<String>> responseHeaders = (Map<String, 
List<String>>)message.get(Message.PROTOCOL_HEADERS);
       
        if (responseHeaders == null) {
            responseHeaders = new HashMap<String, List<String>>();
            message.put(Message.PROTOCOL_HEADERS, responseHeaders);
        }
       
        responseHeaders.put("header1", Arrays.asList(new 
String[]{"headerValue"}));
        logger.debug("out message headers: " + responseHeaders);

then I do something similar to what was done here:

http://www.nabble.com/-OutInterceptor--HttpHeader--Adding-Authorization-Info-entry-to-http-header-td20375003.html

On the other hand, I was able to successfully retain the headers using a 
ResponseHandler implementation with the following statement:

        MultivaluedMap<String, Object> map = response.getMetadata();
        map.add("header1", "headerValue");
        //I think it is worth noting in the docs it is this easy to 
modify the headers :D

So I guess I will be using the the ResponseHandler from now on. At least 
for header post-processing.

One thing though, with messages the expected value for headers is a 
List<String>, while with Response it is just String. Would it be 
possible to adjust one so they would expect the same object?

Again, my thanks.

Gabo

Sergey Beryozkin wrote:
> 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
>