You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "S. Ali Tokmen" <sa...@bull.net> on 2009/02/11 17:51:19 UTC
CAMEL 1.6.0 and 2.0.0: when ?
Hello
And... When are these versions are to be expected?
Cheers
S. Ali Tokmen
savas-ali.tokmen@bull.net
Office: +33 4 76 29 76 19
GSM: +33 66 43 00 555
Bull, Architect of an Open World TM
http://www.bull.com
Willem Jiang a écrit :
> Hi Marc,
>
> I did a quick fix for the CAMEL-1330 on camel 1.x branch and it will be
> be a part of the coming up camel 1.6.
> Since we refactored the camel-cxf module in camel trunk, so the trunk
> code is ok for the CAMEL-1330.
>
> Willem
>
> Willem Jiang wrote:
>
>> Hi Marc,
>>
>> I just fill a JIRA[1] for it, and will look into it tomorrow.
>>
>> [1]https://issues.apache.org/activemq/browse/CAMEL-1330
>>
>> Willem
>>
>> On Tue, Feb 10, 2009 at 6:36 PM, Marc Giger <gi...@gmx.ch> wrote:
>>
>> Hi,
>>
>> I have (again) the problem that a soap-fault is not returned as 500
>> code.
>>
>> This worked fine with camel-cxf 1.3 but not with camel-cxf 1.5. The
>> reason
>> seems to be that the cxf response-context is not (correctly?)
>> propagated back.
>>
>> In 1.3 we had the following code to propagate the responseContext
>> back to the caller:
>>
>> CxfProducer line 252:
>>
>> 248: Object result = cxfClient.dispatch(params, context, ex);
>> 249: ex.setOutMessage(response);
>> 250: invokingContext.setResponseContent(response, result);
>> 251: // copy the response context to the response
>> 252: response.putAll(responseContext);
>> 253: cxfBinding.storeCxfResponse(exchange, response);
>>
>> This has changed in 1.5 to
>>
>> Object result = cxfClient.dispatch(params, context, ex);
>> ex.setOutMessage(response);
>> invokingContext.setResponseContent(response, result);
>> // copy the response context to the response
>> CxfBinding.storeCXfResponseContext(response, responseContext);
>> CxfBinding.storeCxfResponse(endpoint.getHeaderFilterStrategy(),
>> exchange, response);
>>
>> Which stores the responseContext itself as a new property in the
>> message.
>>
>> Later in the chain, AbstractHttpDestination searches a RESPONSE_CODE
>> in the message:
>>
>> Integer i = (Integer)outMessage.get(Message.RESPONSE_CODE);
>> if (i != null) {
>> int status = i.intValue();
>> if (HttpURLConnection.HTTP_INTERNAL_ERROR == i) {
>> Map<Object, Object> pHeaders =
>>
>> CastUtils.cast((Map)outMessage.get(Message.PROTOCOL_HEADERS));
>> if (null != pHeaders &&
>> pHeaders.containsKey(PROTOCOL_HEADERS_CONTENT_TYPE)) {
>> pHeaders.remove(PROTOCOL_HEADERS_CONTENT_TYPE);
>> }
>> }
>> response.setStatus(status);
>> } else {
>> response.setStatus(HttpURLConnection.HTTP_OK);
>> }
>>
>> which it doesn't find because the RESPONSE_CODE is stored in the
>> ResponseContext which is again a HashMap.
>> In this case the access to the RESPONSE_CODE would be:
>>
>> ((HashMap)outMessage.get("ResonseContext")).get(Message.RESPONSE_CODE)
>>
>> which can't be the correct solution of course.
>>
>> So, what do I have to do to get my 500 back?:-)
>>
>> Thanks & Greets
>>
>> Marc
>>
>>
>>
>>
>>
>
>
>
>
>
Re: CAMEL 1.6.0 and 2.0.0: when ?
Posted by Hadrian Zbarcea <hz...@gmail.com>.
We are in the final stage Camel 1.6.0. The distro is already built
and if it passes the community vote it will be released this weekend.
Camel 2.0 is under active development, and one of the goals is to try
as best as we can to provide a stable api that is not likely to change
soon (and a stable implementation as well). You can expect this
process to take another few months. We think we are not too far from
our goal though and one of the options considered is to issue a
milestone release (2.0.0-M1), but no decision has been made yet.
Regards,
Hadrian
On Feb 11, 2009, at 11:51 AM, S. Ali Tokmen wrote:
> Hello
>
> And... When are these versions are to be expected?
>
> Cheers
>
> S. Ali Tokmen
> savas-ali.tokmen@bull.net
>
> Office: +33 4 76 29 76 19
> GSM: +33 66 43 00 555
>
> Bull, Architect of an Open World TM
> http://www.bull.com
>
>
>
> Willem Jiang a écrit :
>> Hi Marc,
>>
>> I did a quick fix for the CAMEL-1330 on camel 1.x branch and it
>> will be
>> be a part of the coming up camel 1.6.
>> Since we refactored the camel-cxf module in camel trunk, so the trunk
>> code is ok for the CAMEL-1330.
>>
>> Willem
>>
>> Willem Jiang wrote:
>>
>>> Hi Marc,
>>>
>>> I just fill a JIRA[1] for it, and will look into it tomorrow.
>>>
>>> [1]https://issues.apache.org/activemq/browse/CAMEL-1330
>>>
>>> Willem
>>>
>>> On Tue, Feb 10, 2009 at 6:36 PM, Marc Giger <gi...@gmx.ch>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I have (again) the problem that a soap-fault is not returned as
>>> 500
>>> code.
>>>
>>> This worked fine with camel-cxf 1.3 but not with camel-cxf 1.5.
>>> The
>>> reason
>>> seems to be that the cxf response-context is not (correctly?)
>>> propagated back.
>>>
>>> In 1.3 we had the following code to propagate the responseContext
>>> back to the caller:
>>>
>>> CxfProducer line 252:
>>>
>>> 248: Object result = cxfClient.dispatch(params, context, ex);
>>> 249: ex.setOutMessage(response);
>>> 250: invokingContext.setResponseContent(response, result);
>>> 251: // copy the response context to the response
>>> 252: response.putAll(responseContext);
>>> 253: cxfBinding.storeCxfResponse(exchange, response);
>>>
>>> This has changed in 1.5 to
>>>
>>> Object result = cxfClient.dispatch(params, context, ex);
>>> ex.setOutMessage(response);
>>> invokingContext.setResponseContent(response, result);
>>> // copy the response context to the response
>>> CxfBinding.storeCXfResponseContext(response, responseContext);
>>> CxfBinding.storeCxfResponse(endpoint.getHeaderFilterStrategy(),
>>> exchange, response);
>>>
>>> Which stores the responseContext itself as a new property in the
>>> message.
>>>
>>> Later in the chain, AbstractHttpDestination searches a
>>> RESPONSE_CODE
>>> in the message:
>>>
>>> Integer i = (Integer)outMessage.get(Message.RESPONSE_CODE);
>>> if (i != null) {
>>> int status = i.intValue();
>>> if (HttpURLConnection.HTTP_INTERNAL_ERROR == i) {
>>> Map<Object, Object> pHeaders =
>>>
>>> CastUtils.cast((Map)outMessage.get(Message.PROTOCOL_HEADERS));
>>> if (null != pHeaders &&
>>> pHeaders.containsKey(PROTOCOL_HEADERS_CONTENT_TYPE)) {
>>>
>>> pHeaders.remove(PROTOCOL_HEADERS_CONTENT_TYPE);
>>> }
>>> }
>>> response.setStatus(status);
>>> } else {
>>> response.setStatus(HttpURLConnection.HTTP_OK);
>>> }
>>>
>>> which it doesn't find because the RESPONSE_CODE is stored in the
>>> ResponseContext which is again a HashMap.
>>> In this case the access to the RESPONSE_CODE would be:
>>>
>>>
>>> ((HashMap
>>> )outMessage.get("ResonseContext")).get(Message.RESPONSE_CODE)
>>>
>>> which can't be the correct solution of course.
>>>
>>> So, what do I have to do to get my 500 back?:-)
>>>
>>> Thanks & Greets
>>>
>>> Marc
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>