You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Marc Giger <gi...@gmx.ch> on 2009/02/10 11:36:35 UTC
camel-cxf Soap-Fault not returned as 500 http error code
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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
CAMEL 1.6.0 and 2.0.0: when ?
Posted by "S. Ali Tokmen" <sa...@bull.net>.
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-cxf Soap-Fault not returned as 500 http error code
Posted by Willem Jiang <wi...@gmail.com>.
Hi Marc
Since there are lots of bug fixing and improvements, we change the
release version of camel 1.x branch from 1.5.1 to 1.6.
Hadrian is working on the release of camel 1.6 this week. If everything
is fine , you can download the kit next week.
Before that , you can try the CAMEL-2.0-SNAPSHOT here[1]
[1]http://people.apache.org/repo/m2-snapshot-repository/org/apache/camel/apache-camel/
Willem
Marc Giger wrote:
> Hi Willem,
>
> On Wed, 11 Feb 2009 23:27:10 +0800
> Willem Jiang <wi...@gmail.com> wrote:
>
>> 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.
>
> Thank you. I will try it out.
> Do you have an idea when camel 1.6 will be released?
> Will there be a 1.5.1 release as announced on
> http://camel.apache.org/download.html ?
>
> Greets
>
> Marc
>
>
>> 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-cxf Soap-Fault not returned as 500 http error code
Posted by Marc Giger <gi...@gmx.ch>.
Hi Willem,
On Wed, 11 Feb 2009 23:27:10 +0800
Willem Jiang <wi...@gmail.com> wrote:
> 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.
Thank you. I will try it out.
Do you have an idea when camel 1.6 will be released?
Will there be a 1.5.1 release as announced on
http://camel.apache.org/download.html ?
Greets
Marc
>
> 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-cxf Soap-Fault not returned as 500 http error code
Posted by Willem Jiang <wi...@gmail.com>.
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-cxf Soap-Fault not returned as 500 http error code
Posted by Willem Jiang <wi...@gmail.com>.
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
>
>
>
>