You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by James Carman <ja...@carmanconsulting.com> on 2013/10/09 07:23:23 UTC
[hazelcast] Instance Consumer...
While mocking the HazelcastInstance objects in the test cases, I ran
into an interesting problem. The HazelcastInstanceConsumerTest was
@Ignored, stating that it messed up subsequent tests. Now that I'm
not using "live" HazelcastInstances, there is no reason to @Ignore
them anymore. However, when trying to get the tests to pass, I
noticed a strange irregularity. The route used to test the consumer
relied upon a header being set. The header was being set on the "out"
message, but the route was looking for it on the "in" message. Since
everything was ignored, we never ran into this before. I changed the
code to write "in" message headers instead and the test started
working. This *is* a regression and we can change it back (or perhaps
write the headers to the "out" message also) if need be, but I believe
the intent was to have the headers on the in message. How likely do
we think it is that folks are relying upon the "bug" functionality?
James
Re: [hazelcast] Instance Consumer...
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1
Regards
JB
On 10/10/2013 02:41 PM, Christian Müller wrote:
> I also consider this as an bug. I propose to fix it in the way you
> mentioned and add a remark to the section "Changes that may affect end
> users" in [1].
>
> [1] http://camel.apache.org/camel-2130-release.html
>
> Best,
>
> Christian
> -----------------
>
> Software Integration Specialist
>
> Apache Member
> V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
> Apache Incubator PMC Member
>
> https://www.linkedin.com/pub/christian-mueller/11/551/642
>
>
> On Wed, Oct 9, 2013 at 7:23 AM, James Carman <ja...@carmanconsulting.com>wrote:
>
>> While mocking the HazelcastInstance objects in the test cases, I ran
>> into an interesting problem. The HazelcastInstanceConsumerTest was
>> @Ignored, stating that it messed up subsequent tests. Now that I'm
>> not using "live" HazelcastInstances, there is no reason to @Ignore
>> them anymore. However, when trying to get the tests to pass, I
>> noticed a strange irregularity. The route used to test the consumer
>> relied upon a header being set. The header was being set on the "out"
>> message, but the route was looking for it on the "in" message. Since
>> everything was ignored, we never ran into this before. I changed the
>> code to write "in" message headers instead and the test started
>> working. This *is* a regression and we can change it back (or perhaps
>> write the headers to the "out" message also) if need be, but I believe
>> the intent was to have the headers on the in message. How likely do
>> we think it is that folks are relying upon the "bug" functionality?
>>
>> James
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [hazelcast] Instance Consumer...
Posted by Christian Müller <ch...@gmail.com>.
I also consider this as an bug. I propose to fix it in the way you
mentioned and add a remark to the section "Changes that may affect end
users" in [1].
[1] http://camel.apache.org/camel-2130-release.html
Best,
Christian
-----------------
Software Integration Specialist
Apache Member
V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apache Incubator PMC Member
https://www.linkedin.com/pub/christian-mueller/11/551/642
On Wed, Oct 9, 2013 at 7:23 AM, James Carman <ja...@carmanconsulting.com>wrote:
> While mocking the HazelcastInstance objects in the test cases, I ran
> into an interesting problem. The HazelcastInstanceConsumerTest was
> @Ignored, stating that it messed up subsequent tests. Now that I'm
> not using "live" HazelcastInstances, there is no reason to @Ignore
> them anymore. However, when trying to get the tests to pass, I
> noticed a strange irregularity. The route used to test the consumer
> relied upon a header being set. The header was being set on the "out"
> message, but the route was looking for it on the "in" message. Since
> everything was ignored, we never ran into this before. I changed the
> code to write "in" message headers instead and the test started
> working. This *is* a regression and we can change it back (or perhaps
> write the headers to the "out" message also) if need be, but I believe
> the intent was to have the headers on the in message. How likely do
> we think it is that folks are relying upon the "bug" functionality?
>
> James
>