Hi Dan,
After looking into this for a while, actually it looks simple to fix
the behavior of this PROTOCOL_HEADERS map. In addition, it seems that
there will be similar problems with other headers if we do not change
the map's behavior. So, I am in favor of fixing this problem at this
map and not at SOAPActionInInterceptor. I will update the JIRA ticket
accordingly.
Thanks.
Regards, aki

On Fri, Feb 25, 2011 at 10:14 PM, Aki Yoshida <[email protected]> wrote:
> Hi Dan,
> I was creating a bug ticket some hours ago but JIRA was not responding
> and could just submit it earlier
> CXF-3367.
>
> I thought also why the PROTOCOL_HEADERS were not storing headers using
> e.g., the lowercased key names. But if we change the keys now into the
> lower or upper case, we will probably have to change many classes that
> are expecting the current names.
>
> I was not sure if this change would then feasible in 2.3.x. We would
> probably need to introduce a custom map that uses the lowercase key
> name mapped to a header name value-list pair intead of the current
> simple map because people expect the behavior to remain the same
> (i.e.., a lookup works fine with the current constants as long as the
> original headers names match the constants and for the outbound case,
> the header names are serialized in the given inserted case and not
> suddenly turned into lower or uppercase).
>
> So, I thought we would rather change SOAPActionInInterceptor so that
> it looks for the soap action header by itereating through the list.
>
> regards, aki
>
> On Fri, Feb 25, 2011 at 8:52 PM, Daniel Kulp <[email protected]> wrote:
>>
>> What App server or servlet engine are you using?   I've seen this type of
>> thing with various servlet engines.   Some of them mangle the case of the
>> headers pretty bad.
>>
>> The "real" bug is that the PROTOCOL_HEADERS map should use a case insensitive
>> key set.   That's what i would log as the bug.
>>
>> Dan
>>
>>
>> On Thursday 24 February 2011 2:42:49 PM chakras wrote:
>>> I have a CXF web service running that prints out a WSDL. Taking this WSDL
>>> and running it through CXF version of wsdl2java generates me the stub,
>>>
>>> wsdl2java -verbose -p mypackage.base -sn Myservice -client %1
>>>
>>> When I invoke it, I always get a SOAP fault in my interceptor. My
>>> interceptor is SecurityInterceptor given below,
>>>
>>> read [ReadHeadersInterceptor, SecurityInterceptor, SoapActionInInterceptor,
>>> StartBodyInterceptor]
>>>
>>> On investigating further I find that the 'SOAPAction', is passed as
>>> Soapaction - so when I do this
>>> (reqHeaders.get(SoapBindingConstants.SOAP_ACTION);) -  I don't get any
>>> Action defined. The work around for now that I could do is this,
>>>
>>>         // Fall back on parsing headers (we get Soapaction instead of
>>> SOAPAction also)
>>>         if (action.length() == 0) {
>>>             Map<String, List<String>> reqHeaders =
>>> CastUtils.cast((Map)message.get(Message.PROTOCOL_HEADERS));
>>>             for (Map.Entry<String, List<String>> entry :
>>> reqHeaders.entrySet()) {
>>>
>>>                 String key = entry.getKey();
>>>                 List value = entry.getValue();
>>>                 if (SoapBindingConstants.SOAP_ACTION.equalsIgnoreCase(key))
>>> {
>>>                     if (value != null && value.size() > 0)
>>>                         action.append(value.get(0).toString());
>>>                 }
>>>             }
>>>         }
>>>
>>> Is this how it is supposed to work?
>>
>> --
>> Daniel Kulp
>> [email protected]
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
>

Reply via email to