camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <>
Subject Re: About a bug of the camel-mongodb component...
Date Tue, 15 Apr 2014 10:25:58 GMT
Hello Babak,

Thanks for pointing this out!

Just some background... The ReadPreference class in the MongoDB Java API
has changed substantially between the driver versions:

* The initial contribution of camel-mongodb was done against driver version
2.7.3 [1].
* Currently we are on driver version 2.12.0 in Camel 2.14-SNAPSHOT [2].

The logic to resolve the Read Preference by reflection makes sense with
driver version 2.7.3, but not with 2.12.0.

I do remember testing this logic manually when I first contributed the
component. But clearly I missed making a unit test, which would have helped
us detect this non-backwards compatible change.

+1 to your adjustment proposal.



*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist | | twitter: @raulvk

On Tue, Apr 15, 2014 at 10:33 AM, Babak Vahdat

> Hi
> There was a flaw by MongoDbEndpoint#setReadPreference() I tried to fix last
> week. See also the documentation about the readPreference option:
> In the meanwhile I've noticed that this option doesn't work *at all* anyway
> because:
> - For example if you try to use
> "readPreference=com.mongodb.ReadPreference$PrimaryReadPreference” the
> reflection hack will not work (with the current logic) as the static member
> class PrimaryReadPreference is private anyway (one would end up with
> IllegalAccessException etc.)
> - One can't for example make use of the value
> "com.mongodb.ReadPreference$TaggedReadPreference" (as the documentation
> says) because this preference has no default constructor!
> We also don't have any test case in the code base about this option.
> As this option doesn't work anyway, my suggestion is to change the possible
> values for this option to the ones com.mongodb.ReadPreference#valueOf()
> allows. I've raised a JIRA including a proposed fix for this:
> I also think an option value like "readPreference=primaryPreferred" would
> read much easier than
> "readPreference=com.mongodb.TaggableReadPreference$PrimaryPreferredReadPreference"
> etc.
> The price we would pay for this would be non-backward compatibility with
> the
> current behaviour but as the current implementation doesn't work anyway, I
> guess this's not an issue at all.
> Thoughts?
> Babak
> --
> View this message in context:
> Sent from the Camel Development mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message