On Sat, May 9, 2009 at 5:05 AM, William Tam <email.w...@gmail.com> wrote:
> That sounds fine to me.
+1
We had a initial discussion on whether to use a single name for common
types such as Content-Type for CXF, Restlet, Http, etc.
I guess it makes sense to do that. There are might other similar keys
such as: Content-Length and other http headers.
>
> - William
>
> On Fri, May 8, 2009 at 9:49 PM, Willem Jiang <willem.ji...@gmail.com> wrote:
>> Hi William,
>>
>> How about we store these Content-Type with the same key: "CamelConentType"?
>>
>> In this way we don't need to write a long check list for looking up the
>> Content-Type in the Camel message header.
>>
>> Any thought?
>>
>>
>> Willem
>>
>> William Tam wrote:
>>> Hi Willem,
>>>
>>> I think you meant CxfHeaderHelper rather than CamelTransport. I saw
>>> your checkin. Changing the header name from "content.type" to
>>> "CamelContentType" is fine, although it is not consistent with
>>> DefaultCxfBinding where it just uses header name "Content-Type".
>>> Also, should it be "CamelCxfContentType"? BTW, there is a
>>> CamelHttpContentType in HTTP component, and one
>>> (CamelRestletMediaType) for Restlet component. They are have same
>>> semantics.
>>>
>>> Cheers,
>>> William
>>>
>>> On Fri, May 8, 2009 at 10:36 AM, William Tam <email.w...@gmail.com> wrote:
>>>> I couldn't find where CamelTransport is referencing
>>>> CamelTransportContants.CONTENT_TYPE. Even if it is referenced, I
>>>> don't understand why we can have to use the constant of value
>>>> "content.type".
>>>>
>>>> On Fri, May 8, 2009 at 3:56 AM, Willem Jiang <willem.ji...@gmail.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I just found the CamelTransportContants.CONTENT_TYPE is used by the
>>>>> CamelTransport.
>>>>> The integration test of CustomerServicesTest shows the user case.
>>>>>
>>>>> Since there is no protocol header defined in Camel-xxx component, camel
>>>>> transport need to copy the content-type between the CXF message and
>>>>> Camel message back and forth.
>>>>>
>>>>> Since the DefaultCxfBinding will not be used in CamelTranpsort, I just
>>>>> revert the change of the CXFHeaderHelper.
>>>>>
>>>>> Willem
>>>>>
>>>>>
>>>>>
>>>>> William Tam wrote:
>>>>>> On Wed, May 6, 2009 at 11:55 PM, Claus Ibsen <claus.ib...@gmail.com>
>>>>>> wrote:
>>>>>>> On Thu, May 7, 2009 at 5:02 AM, William Tam <email.w...@gmail.com>
>>>>>>> wrote:
>>>>>>>> On Wed, May 6, 2009 at 9:57 PM, Willem Jiang <willem.ji...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Hi William,
>>>>>>>>>
>>>>>>>>> Since the JMS can't accept the header which's name has the '-'
>>>>>>>>> character, we introduce the CamelTransportContants.CONTENT_TYPE for
>>>>>>>>> it.
>>>>>>>> I thought JMS could not handle dots in header names (that's why we
>>>>>>>> went from org.apache.camel convention to CamelHeaderName "case"
>>>>>>>> convention). My memory may be wrong.
>>>>>>> Hi
>>>>>>>
>>>>>>> In Camel 2.0 we have added to the JMS component so it will be able to
>>>>>>> transfer Content-Type with the hyphen, as its a common header.
>>>>>>> If you use Camel on both sides then it will automatic revert it back
>>>>>>> to normal again. It replaces - with a _HYPHEN_ constant. So its
>>>>>>> transfered as Content_HYPHEN_Type.
>>>>>> In 2.0, does that mean it is OK to have hyphen in header? If so, we
>>>>>> could clean up CamelTransportContants.CONTENT_TYPE?
>>>>>>
>>>>>>>>> After checking the on wire message between the client and CXF
>>>>>>>>> consumer,
>>>>>>>>> I found there are two lines of "content-type" in the http header.
>>>>>>>>> One is "content-type", the other is "Content-Type".
>>>>>>>> The comment in code is kinda off.
>>>>>>>>
>>>>>>>>> So I added the filter of "content-type", and keep using "content.type"
>>>>>>>>> in the Camel message.
>>>>>>>>>
>>>>>>>>> Willem
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> William Tam wrote:
>>>>>>>>>> Hi Willem,
>>>>>>>>>>
>>>>>>>>>> I don't think adding "content-type" to the filters is necessary.
>>>>>>>>>> 1. The header is "Content-Type" not "content-type", so the change
>>>>>>>>>> does not really affect anything.
>>>>>>>>>> 2. Putting that aside. If we add filters for "Content-Type", it
>>>>>>>>>> stops
>>>>>>>>>> the propagating from Camel header to/from CXF header, which we don't
>>>>>>>>>> want.
>>>>>>>>>>
>>>>>>>>>> We probably should clean up the use of
>>>>>>>>>> CamelTransportContants.CONTENT_TYPE (value = content.type) and just
>>>>>>>>>> use Message.CONTENT_TYPE (value = Content-Type).
>>>>>>>>>>
>>>>>>>>>> In DefaultCxfBinding.java, I don't see why we need to invent a header
>>>>>>>>>> constant (CamelTransportContants.CONTENT_TYPE) only used by camel-cxf
>>>>>>>>>> and have to map it back and forth.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That is, we can eliminate CamelTransportContants.CONTENT_TYPE and use
>>>>>>>>>> Message.CONTENT_TYPE consistently in:
>>>>>>>>>>
>>>>>>>>>> // propagate content type
>>>>>>>>>> String key = Message.CONTENT_TYPE;
>>>>>>>>>> Object value = cxfMessage.get(key);
>>>>>>>>>> if (value != null &&
>>>>>>>>>> !headerFilterStrategy.applyFilterToExternalHeaders(key, value,
>>>>>>>>>> exchange)) {
>>>>>>>>>> camelHeaders.put(CamelTransportConstants.CONTENT_TYPE,
>>>>>>>>>> value);
>>>>>>>>>> if (LOG.isTraceEnabled()) {
>>>>>>>>>> LOG.trace("Populate header from CXF header=" + key +
>>>>>>>>>> "
>>>>>>>>>> value=" + value);
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>> // put content type in exchange
>>>>>>>>>> if
>>>>>>>>>> (CamelTransportConstants.CONTENT_TYPE.equals(entry.getKey())) {
>>>>>>>>>> cxfExchange.put(Message.CONTENT_TYPE,
>>>>>>>>>> entry.getValue());
>>>>>>>>>> continue;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>> ==============================================================================
>>>>>>>>>>> ---
>>>>>>>>>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfHeaderFilterStrategy.java
>>>>>>>>>>> (original)
>>>>>>>>>>> +++
>>>>>>>>>>> camel/trunk/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfHeaderFilterStrategy.java
>>>>>>>>>>> Wed May 6 04:56:14 2009
>>>>>>>>>>> @@ -63,6 +63,11 @@
>>>>>>>>>>> getOutFilter().add(Message.PROTOCOL_HEADERS);
>>>>>>>>>>> getInFilter().add(Message.PROTOCOL_HEADERS);
>>>>>>>>>>>
>>>>>>>>>>> + // Since the DefaultCxfBinding deal with the content-type
>>>>>>>>>>> separately.
>>>>>>>>>>> + // We need to filter this header
>>>>>>>>>>> + getOutFilter().add("content-type");
>>>>>>>>>>> + getInFilter().add("content-type");
>>>>>>>>>>> +
>>>>>>>>>>> // initialize message header filter map with default SOAP
>>>>>>>>>>> filter
>>>>>>>>>>> messageHeaderFiltersMap = new HashMap<String,
>>>>>>>>>>> MessageHeaderFilter>();
>>>>>>>>>>> addToMessageHeaderFilterMap(new SoapMessageHeaderFilter());
>>>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> Apache Camel Committer
>>>>>>>
>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>> Apache Camel Reference Card:
>>>>>>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>>>>>> Interview with me:
>>>>>>> http://architects.dzone.com/articles/interview-claus-ibsen-about?mz=7893-progress
>>>>>>>
>>>>>
>>>
>>
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Interview with me:
http://architects.dzone.com/articles/interview-claus-ibsen-about?mz=7893-progress
